Sizing "Incroyable" d'un serveur SQL Server 2005

Bonjour à tous,

Dans le cadre du développement d'une application web, nous sommes amenés à gérer +- 5.000 connexions max en simultané (en moyenne 2.000) sur notre serveur SQL. Selon les préconisations d'un sous-traitant ayant développé un module du site internet, il nous recommande d'avoir un serveur SQL avec la configuration suivante :

- 2 x Quad-Core
- 20 (Vingt Go) Go de RAM.
- 2 x Carte LAN Gigabit.

Tout cela me parait sur-évalué pour une application web sachant qu'il ne s'agit que du sizing du serveur SQL (j'ai peur de voir celle du serveur web). selon le sous-traitant les préconisations sont faite avec un outils "SoftGrid". Est ce possible qu'un tel nombre de connexions à une BDD SQL 2005 nécessite autant de ressources matérielle ? J'ai déjà vu un post, que je ne retrouve plus, sur le nombre de connexions simultanées gérées par SQL server 2005 et je pense que pour quelques centaines (voir milliers) de connexions par seconde SQL Server 2005 demande moins de ressources !!!

Merci pour vos éclaircissements.

Bonsoir,

C'est diffile à savoir quand on ne sait pas ce que ces connexions font, j'imagine qu'il doit y avoir beaucoup de lectures et peu d'écritures.

J'ai retrouvé ce lien qui est peut être utile au niveau consommation mémoire, c'est pour SQL Serveur 2005.

C'est vrai aussi que le mémoire et la puissance CPU ne sont pas très chères.

Quid du sous système disque ?

@+

Comme le dit agemis31 e pour compléter ses propos, il est vrai que sans savoir ce que fera application web cela peut paraître difficile à estimer.

- Nombre d'utilisateur et activité transactionnelle de l'application pour déterminer la quantité de CPU, la mémoire et la configuration de vos disques ...

- Estimation des données de votre application sur une période assez longue pour l'espace disque nécessaire ...

Autant de choses qu'il vous faudra savoir si vous voulez vraiment dimensionner vous même

++

Il n'y a à priori rien d'anormal là dedans. Pour ce qui est du nombre de connexion je préconise depuis 10 ans 1CPU et une carte réseau par paquet de 500 à 1000 utilisateurs simultané. Avec un prévision de 5000, le dimensionnement des cartes réseau et des CPU n'est donc pas hors norme, le CPU est un peu large, mais j'espère que les cartes réseau sont dual... Après tout dépend du volume des transactions.

Pour ce qui est de la RAM, tout dépend du calcul de la fenêtre de données que l'on doit estimer en fonction des requêtes et de la qualité du modèle et du style de développement.

Pour ce qui est du sous système disque il faut au moins 3 agrégats physiques, l'un contenant les données, l'autre le journal de transaction et le 3e la base tempdb. Plus c'est mieux, par exemple un 4e agrégat physique permettra de séparer données brutes et index, mais encore une fois tout dépend de la volumétrie et du nombre de transactions par minute.

Quand au serveur Web il a besoin de 5 à 10 fois moins de ressources. il ne fait que lire quelques fichiers (toujours les mêmes) et interpréter un peu de code. Pas d'écriture de données ni de gestion de transactions. Donc rassurez-vous un serveur bas de gamme fera parfaitement l'affaire !
Donc ne paniquez pas !!!

Lisez les articles que j'ai écrit sur l'optimisation de SQL Server. En particulier l'article 2
http://sqlpro.developpez.com/optimisation/

A +

Merci à tous pour vos contributions, je reviens vers vous pour plus d'éléments, certainement, au courant de la journée. au fait ce qui me fait peur c'est que la nouvelle appli est une migration d'une ancienne application d'ASP/SQL 2000 vers ASP .NET 3.5/SQL 2005 et le serveur BDD actuel tourne sur une machine avec 2 proc intel xeon double core, 2Go de RAM 2 HDD de 70 Go montés en raid 1 et une seule carte réseau (je ne suis pas trop sur) et la base actuelle (en sql 2000) fait 11 Go avec des tables qui n'ont presque pas d'index ni de clefs étrangères voir même des clefs primaires en varchar ( :sm: ) aussi avec des requêtes non optimisées et directement dans les pages asp!!! et malgré tout ça ça fonctionne plus ou moins bien. La nouvelle base est mieux conçu avec des index (et pas trop ni pour n'importe quel colonne) des procédures stockées avec un appli 3-tiers, donc ce qui donne de meilleurs performances (logiquement). le fait qu'ils nous demandent une telle config me fait vraiment peur!!!

Tout dépends de la montée en charge prévue. Un serveur de SGBDR doit être capable d'assumer la charge sur un minimum de 3 à 5 ans. Or on ne change pas de serveur en cours de route quand une BD fait quelques centaines de GO....

A +

Bonjour à tous,

Désolé pour ce retour tardif.

En fait certains paramètres ont été revus à la baisse, notamment le nombre de connexions simultanées : On aura +- 5.000 utilisateurs actifs dans la base de données mais il n'y aura, à priori, que 300 connexions actives max en simultanées. Du coup la taille de la mémoire préconisée est passé à 4-8 Go.

il reste à tester cette plateforme dans un vrai environnement de pré production.

Merci encore pour vos contributions.

Verbal34.