Nombre de requêtes par secondes - Page 1

Ma question est simple, en ne prenant pas en compte les paramètres réseau, combien puis je espérer de requêtes par seconde sous sql server sur un serveur dédié moyen de gamme (genre C2D 2Ghz, raid1 7200tpm, 2Go de ram)? Est ce que 10000 req/s c'est réaliste?

Il est impossible de répondre à ta question ... ca va dependre de la requete, des index, de la taille des données, etc.

Bref un meme serveur pourra accepter bien + que 10 000 req/s .... ou s'effondrer a 10 req/s

Je m'attendais à cette réponse Bah j'ai plus qu'à tester de toutes façons ^^
Sinon une autre question, c'est limité par quoi en général niveau matériel? Perso je pencherais pour le disque dur, je pense qu'un quadricoeur s'essouffle bien moins vite qu'un pauvre disque dur à 7200tpm.

RAM & disque ou disque & RAM ^^

Ok, au pire je met à jour mon serveur avec ça : http://www.tweaktown.com/reviews/1683/1/exclusive_look_at_fusion_io_iodrive_pcie_solid_state/index.html ^^

Oui, teste deja en l'état, tu verras deja si ca sature ou non .... mais 10 000 req c'est assez enorme, le serveur MySQL où yN est installé (mutualisé) n'en effectue que 35 /s en moyenne ^^

après, le nb de req /sec peut vraiment tomber pour une même base, juste en remplissant à fond une table si un index est mal placé. De même, si pleins de requêtes sont demandées en même temps (acces concurentiel) , dont des insert qui engendrent des locks tables, ca peut faire tomber carrément le serveur (j'ai eu le coup avec 150 accès concurrentiels sur une table de 150000 enregistrement avec un index mal placé)

Oui, de toutes façons, j''aurais pas besoin de 10000 req/s tout de suite.... M'enfin c'est bon de savoir si je peux me permettre de rajouter des fonctionnalités à mon appli ou pas

10000 requêtes/s c'est assez énorme pour un seul serveur. C'est en réponse à du trafic réseau ? Ou ce sont des requêtes qui se déroulent dans un script linéaire ? Parce que si tu as une seule machine avec un seul accès réseau, sans répartition de charge, tu vas de toutes façons avoir un goulot d'étranglement réseau (à part si tu travailles dans un réseau purement giga, avec des clients au giga, et énormément de clients).
Enfin, il y a un sacré bout de paramètres à prendre en compte, quoi.

C'est du trafic réseau donc je vais essayer de ne jamais atteindre les 10000 req/s

Bah surtout si le réseau ne suit pas, tu n'y arriveras jamais, les clients attendrons ^^

yAro (./6) :
Oui, teste deja en l'état, tu verras deja si ca sature ou non .... mais 10 000 req c'est assez enorme, le serveur MySQL où yN est installé (mutualisé) n'en effectue que 35 /s en moyenne ^^

Ah tiens, je m'attendais à plus, vu tout ce que contient une page en information ^^


Question con, tu as dit il y a un an que yN tenait grosso-modo dans 800Mo (la bdd, pas le site). Pourquoi ne pas tout foutre en RAM alors ? Un serveur ne peut pas faire ça ? J'aurais à coder un système dédié pour un serveur dédié pour un site dédié sur une machine dédiée, c'est au maximum ce que j'esssairais de faire en tout cas ^^

Parce qu'en cas de coupure (ça peut arriver, même si...), il n'y a aucune pérennité des données ?

Je pensais à travailler avec la copie en RAM, sachant que les modifications apportées à la BDD se font par une modification en RAM répercutée immédiatement sur le disque. C'est peut-être pas possible ? Je connais absolument pas la structure que peut avoir une BDD en mémoire...

Je ne sais pas ce qu'en dit yAro, mais de mon point de vue, il y a beaucoup trop d'écritures sur un forum pour que ça soit viable. Pour un site avec un nombre limité d'écritures, aucun souci, mais là, je ne pense pas que ça soit rentable.

Folco (./12) :
Ah tiens, je m'attendais à plus, vu tout ce que contient une page en information ^^

Ouais surtout que je ne suis pas seul sur le serveur (mutualisé je rappelle ^^). Sinon par page je dois être a 6/7 req max pour tout construire.



Pour la BDD en ram ... étant sur du mutualisé donc je peux pas faire ce que je veux. Ensuite MySQL ne gererait pas une BDD aussi grosse en tables mémoire qui de plus ne sont pas perenes.

Et pour finir j'en aurais pas l'utilité, yN est assez rapide comme ca ^^

yAro (./16) :
Et pour finir j'en aurais pas l'utilité, yN est assez rapide comme ca ^^

Là je suis bien d'accord

sql server donc windows... pour être sur que le serveur gère ça comme il faut, pense à prendre une version "datacenter" de l'os, ou alors va jouer dans la bdreg pour augmenter le nombre de sockets allouables...

et tes requêtes elles ressemblent à quoi ? c'est plutôt homogène ou hétérogène ? si c'est du traitement un algo ne peut pas remplacer des opérations data ? Si c'est du traffic réseau on peut supposer que les opérations seront atomiques et limitées en nombre, une utilisation judicieuse du cache peut tout a fait te permettre un gain sensible et si ça suffit pas (et que les données sont volatiles) tu peux envisager des tables "memory"

vince (./18) :
sql server donc windows... pour être sur que le serveur gère ça comme il faut, pense à prendre une version "datacenter" de l'os

ça sera la version entreprise, après, y'a ptet moyen de la régler

vince (./18) :
et tes requêtes elles ressemblent à quoi ? c'est plutôt homogène ou hétérogène ? si c'est du traitement un algo ne peut pas remplacer des opérations data ?

Les requêtes devraient être similaires entre elles, par contre c'est surtout du traffic réseau; mais je posais surtout ma question pour avoir un ordre de grandeur

des insert qui engendrent des locks tables

Il existe encore des bases de données qui font ça ?

Bah à part SQLite non