Version imprimable
Bonjour,
J ai besoin de sizer un serveur SQL 2005 qui aura environ un 100 utilisateurs en parallele et plus de 170000 applications qui tourneront dessus.
Que me conseillez vous?
Je suis parti pour l'instant sur un win 2003 x64 ,SQL 2005 x64,CPU quad core,8GB de memoire
Mais est ce bien suffisant???que faut il prendre en compte lors d un dimensionnement de ce genre?
Bonjour,
Etes-vous sûr de ce chiffre ?Citation:
170000 applications
@++ ;)
oui et c un peu le probleme cependant c 170K par jour et c un pic
Bonsoir,
ca ne serait pas plutot 170000 transactions ?
Pour commencer cependant :
Si vous avez 100 utilisateurs simultanés et en sachant qu'une connexion utilisateur fait a peu pres 500 Kb vous pouvez deja réservez 100 * 500 Kb donc à peu près 50 MB
On considère a peu près 1 processeur + 1 carte réseau par paquet de 500 à 1000 utilisateurs. Donc un mono processeur suffit amplement. Cependant vu les cout des bi pro....
Quand à 170 000 transactions par jour cela ne fait que 120 transactions par minute, soit 2 transactions par seconde ce qui est fort peu à condition que la base soit bien modélisée (respect des formes normales) et bien indexée.
SQL Server est capable d'encaisser jusqu'à 2 500 000 transactions par minute, soit 41 667 transactions par seconde (benchmark tpc C).
A +
Bonjour,
Je me permets de rebondir sur ce post pour ne pas polluer.
Existe-t-il une espèce de formule pour calculer les besoin en terme de ressources serveur (processeur, ram) ?
Nous avons un client qui a une base d'une dizaine de Go, avec ~30 utilisateurs qui font des modifications en permanence, et ils commencent à avoir des plantages plutôt bizarres.
Par contre aucun problème de même type avec d'autres clients qui ont des bases/nb d'utilisateurs concurrents moins importants.
Merci d'avance.
Tout dépend du modèle de données.
L'impact d'un mauvais model est si fort qu'avec peu d'utilisateurs et un volume insignifiant (quelques Go) on peut planter les perf d'un SGBDR. Redimensionner le serveur n'y changera rien, ce sera une éternelle fuite en avant.
Je viens de terminer un audit ou malgré un quadri pro; 3 Go de RAM, moins de 10 Go de data, les temps de réponse sont de 30 seconde en moyenne par écran : remède : toute redévelopper !
Lisez les articles que j'ai écrit sur l'optimisation :
http://sqlpro.developpez.com/optimisation/
puis lisez ceci : les 10 commandements du développeur :
http://blog.developpez.com/sqlpro?ti...s_sur_ms_sql_s
A +
[QUOTE=SQLpro;3870828]Tout dépend du modèle de données.
L'impact d'un mauvais model est si fort qu'avec peu d'utilisateurs et un volume insignifiant (quelques Go) on peut planter les perf d'un SGBDR. Redimensionner le serveur n'y changera rien, ce sera une éternelle fuite en [/url]
J'ajoute qu'il faut aussi noter l'écriture du code de votre programme
Un grand principe consiste à :
si l'on veut éviter d'étrangler son serveur et libérer le pool de connection à temps.Citation:
Se connecter Tard mais ce déconnecter tôt
Le tableau présenter dans l'article du SQL Magazine est clair là dessus.