Bonjour,
 
nous disposons actuellement d'une centaine de sites hébergés chez nous.
Actuellement nous avons un serveur WEB (IIS, qui gère les 100 sites) hors d'âge, et un serveur SQL flambant neuf.
Nous constatons que l'accès à nos sites est de plus en plus lent, et chaque requête dans la DB met de plus en plus de temps, ce, malgré le récent changement de notre serveur SQL.
N'étant pas admin system, j'aurais aimé savoir certaines choses :
 
- pour une centaine de sites, quelle est la meilleure architecture à adopter ? Un seul serveur WEB suffit pour heberger ces sites ? Le fait que le serveur WEB et le serveur SQL soient différents a t il une incidence sur la rapidité d'accès aux pages ? (les 2 serveurs sont reliés entre eux par du 10 Mbits ... eh oui ...).
- Est-ce judicieux de partager l'hebergement de ces sites sur 2 serveurs WEB ?
- Quel est le meilleur moyen d'optimiser les temps d'accès aux bases de données (config SQL serveur, etc etc ...)
 
Je suis bien conscient que ces questions sont quelques peu naives, mais bon, je suis analyste programmeur de formation, et l'admin reseau n'est pas mon point fort
 
Merci d'avance pour vos réponses !

A mon avis faudrait d'habord auditer le traffic...Et décrire un peu plus précisement la topologie du réseau.
Après tu pourras choisir des solutions pour un upgrade des perfs.
 

Mmmmmmh ...
Concernant la topologie du reseau ... Qu'entends tu par la ?
Nous avons simplement deux serveurs ... Le serveur WEB heberge les sites, tandis que le SQL gère la DB.
Les sites sont en ASP. Les deux serveurs sont en Windows 2000 server.
Au niveau de la fréquentation, ça va du site de particulier, au site plus important de journaux quotidiens ...
 

La topologie du réseau c'est la description de l'ensemble du réseau avec tout les equipements qui en suivent.
Y'a bien un switch manageable ? un firewall ? çà te permetterais d'analyser le traffic et de pouvoir voir si il y'a des goulots d'ettranglements.
On peut aussi voir si il ya surcharge des serveurs en auditant directment dessus.

Salut
 

Quelles sont les configs en gros et le Windows utilisé dessus ?

La charge CPU est plus importante sur le SQL malgré ça ? Peut être un problème d'index SQL ou de disque  pas assez performant ( simple IDE ou SATA ou SCSI ou RAID ? )
 

A la base la solution généralement sympathique et simple est d'avoir un SQL puissant et N webs en fonction des ressources nécessaires. Seulement si c'est le SQL qui charge, éventuellement il serait intéressant de séparer entre 2 machines pour situer quel(s) site(s) bouffe autant si la machine est puissante. 10 MBps entre les 2 serveurs c'est vraiment pas terrible par contre, 100 MBps serait bien mieux surement. Tu peux voir l'occupation de ce lien via le monitoring des ressources ?
 

Là encore il faut situer d'abord où se trouve le problème à la base, si c'est l'accès au SQL, c'est pas forcément ça qui va aider. Dans tous les cas remplacer une machine préhistorique par une nouvelle puissante est plus intéressant que de mettre l'ancienne et la nouvelle ensemble ( question de déséquilibre )
 

Outre le lien, après ce n'est pas temps d'accès mais surement le traitement qui joue, c'est à dire le temps pour traiter une requête. Si tu fais une requête qui doit parcourir toute une énorme table sans arrêt parce qu'il n'y a pas d'index ou ce genre de choses, c'est problématique forcément
 
 

Chacun son métier c'est normal, bon courage en tout cas. Eventuellement un audit de la plateforme serait intéressant avant que tu ne décides un changement, afin de mieux cibler le point de ralentissement

Alors  
 
Tout d'abord merci pour ces réponses claires et précises
 
Concernant le nouveau serveur SQL, le problème ne peut venir du hardware. 2 Go de RAM, CPU Xenon 3Ghtz, et un raid scsi. C'est un serveur ultra performant, donc aucun soucis de ce coté là.
 
Par contre, peut être existe-til en effet un problème d'indexation des tables ... Concretement, si j'ajoute une indexation pour chaques DB, quelles seront les conséquences négatives ?
 
Le problème pourrait peut-être provenir du débit alloué à notre bande passante ... Je vais me renseigner ... Mais en tout cas, la situation devient très problématique ... (problème de timeout sur des grosses requêtes, lenteur excessive, etc etc ...)
 
Merci d'avance

 
A savoir que le raid 5, ca pue pour faire du SQL (prendre du raid 0, 1 ou 10)
 

 
Toutes les modifications sont plus longues (nécéssité de maintenir l'index a jour). Mais sur 90% des applications, c'est un gain énorme, qui permet par exemple de retrouver une entrée dans une table gigantesque en quelques microseconde
 

 
Pour ce qui est du lien 10 Mbits entre les 2 serveurs, ce n'est pas un probleme. Il est tres rare d'acceder a de grosse quantités de données en SQL, et il ne faut pas oublier que 10 Mbits, cela fait quand meme facilement 1 Millions de caracteres par seconde.
Par contre, il est vrai aussi qu'une carte reseau 100 Mbits coute moin de 10 Euros, donc c'est un peu con de s'en priver
 
Pour savoir si c'est le serveur SQL qui rame, je ne connais pas bien ceux disponible sous windows, mais il y a sans doute moyen de prendre connaissance de la longueur moyenne des requetes, de celles qui sont les plus longues, etc etc etc.

Krystal_ :  
 
Concernant le RAID 5, dire que ça pue est abusé, c'est moins performant qu'un RAID 10 par exemple mais généralement plus intéressant en terme de rapport perfs+place/disques.
 
Les perfs restent très intéressantes donc et hormis le mode dégradé qui rame, ça reste un choix très sympa pour une config 4 ou 6 disques.
 
 
Pour le 10 Mbps, ça dépend, le forum où tu post actuellement est pas loin d'avoir ce débit entre le web et le SQL ( et ce n'est pas du mauvais code, c'est juste beaucoup de données à afficher venant de la bdd ), chez un autre client à grande échelle il a fallu upgrader le lien vers du Gigabit, donc bon tout dépend de l'utilisation et de l'échelle...
 
A mon avis là il manque clairement des index sur certains champs pour alléger le truc.

 
Les perfs en *lecture* reste tres interressante, mais pour tout ce qui est écriture, c'est une sainte catastrophe (dans l'absolue, ca va moin vite qu'un disque tout seul). Hors un serveur SQL est justement une machine qui fait pas mal d'ecriture. Je m'explique :
 
En raid 5, quand on ecrit un fichier de 192k sur, par exemple, 4 disques, avec un stripesize de 64k (re-par-exemple), voila ce qu'il se passe : les premiers 64 k sont mis sur un premier disque, de 64 a 128k, c'est sur le deuxieme, et de 128 a 192, c'est sur le 3eme. Ensuite, la parité est mise sur le 4eme (bon, c'est pas toujours cet ordre, mais la théorie est la). Pour calculer la parité, facile, il suffit de XORer l'ensemble des 3 strippes qui a été ecrit. Ca va super vite (les processeurs actuels le font a quelques centaines de Mo/s). Jusque la, toujours pas de probleme, ca va assez vite ... Il faut quand meme noter que dans l'histoire, pour ecrire un seul fichier, on a fait seeker nos 4 disques durs, donc meme si en debit continue, cela tiens le debit théorique de 3 disques, en pratique, cela fait qu'on ne peut pas faire plus de 200 ecritures differentes par seconde (vu que le seek d'un disque moyen est de 5 ms) sur l'ensemble du raid (mais ca, c'est pareil sur un raid 0).
 
Maintenant, si notre fichier de 192k est, par exemple, une base sql, et que l'on vient de modifier un champs, qui on va dire est au 100eme Ko du fichier, que ce passe-t-il ? Sur un disque normal, facile, le secteur qui contient le champs (de 4k) est relu, modifier, et reecrit. Sur un raid 0 (ou 10), idem. Mais sur un raid 5 ? Et bien sur un raid 5, on fait pareil, sauf qu'on a le droit de relire l'integralité des 192 ko pour recalculer la parité juste derriere. Donc refaire seeker l'ensemble de nos disques juste pour une petite écriture.
 
Bien entendu, tant que le fichier original est toujours dans le buffer cache (dans le cas d'un raid soft) ou dans le cache de la carte raid (dans le cas d'un raid hard), cela va vite, mais en pratique, si on met du raid 5, c'est pour avoir de la place, et il y a donc peu de chance pour que toutes nos bases tiennent en cache
 
A noter aussi qu'avec tout les systemes de fichier journalisé, l'impact est double, car toute ecriture est toujours doublé dans le log du fs (et vi ... meme si c'est juste 10 octets ).  
 
Petite parenthese sur le mode dégradé : en fait, celui ci rame juste parce que la complexité de la lecture d'un bloc devient la meme que celle de l'ecriture d'un block (ie, il faut lire tout les blocks d'a coté pour pouvoir recalculer ce qui manque ... comme deja dit, le recalcul est super rapide, ce n'est donc pas un probleme, seul le fait de faire seeker tout les disques en est un). En ecriture, a priory, les perfs doivent rester les meme.
 
Re-petite-parenthese completement a part sur le "pourquoi que le raid 0 va toujours plus vite que le raid 5 alors que justement sur le raid 5 la parité est répartie sur les disques pour que tout les disques puissent etre utilisé en lecture" : appelez moi "read ahead" . Tout les disques mettent des données en cache lorsque l'on demande une lecture d'un secteur, ce qui est tout a fait normal, puisqu'un rapide calcul nous montre que meme pour un disque seekant en moyenne a 5 ms, il ne peut le faire que 200 fois par secondes. Donc le temps d'un seek est égal a, sur un disque debitant 40 Mo/s, environ 200 ko. Donc toute lecture inferieur a 200 ko n'est pas rentable, puisque le temps de seek deviendrait alors plus long que le temps de lecture, c'est pourquoi souvent les disques lisent systematiquement 256 ko, quelque soit la taille de ce qu'on a demandé a lire. Bien souvent, c'est un choix judicieu, mais dans le cas du raid, il se trouve que cela fait que votre disque lit systematiquement le bloc de parité en lisant le bloc précédent celui ci ... donc vous vous retrouvez, en debit brut, avec les perfs de n-1 disques a la place d'avoir les perfs de n disque ... A noter quand meme que lorsqu'il y a beaucoup d'io simultané, vous beneficiez quand meme d'un disque supplémentaire pouvant aller chercher des infos, ca vaut donc le coup par rapport a un raid 4.
 

 
active le gzip ... héhé
 
Non, pour un forum tel que celui ci, cela ne m'étonne pas [trop], surtout quand on voit la taille des posts des abrutits comme moi
N'empeche que j'aimerais bien savoir quel est la part de burst et la part d'utilisation reele dans tout cela
 
Enfin cela n'empeche pas que pour la majorité des gens, 10 Mbits ne seront *jamais* la cause de ramage intempestif, d'ou ma remarque. (si t'as des graphs j'veux bien )

Concernant les écritures MySQL, il faut peut être penser aux caches et synchros disques, une écriture SQL est bien moins lourde qu'une lecture ( un SELECT balaye le disque là où un INSERT demande moins de boulot )
 
Pour les graphs je sais pas si Marc serait d'accord pour que je les montre, dans le doute je ne le ferai pas ( pour les 10 Mbps, c'est du SQL pur là, je parle pas de la BP sortante du forum web )

 
Houlala. Alors la, pas du tout
 
Concernant le cache, en effet, il y en a, mais ca ne change pas le fait qu'au final pour ecrire une quantité X de data, il faut relire Y data a coté. On y peut rien. Dans l'absolu (enfin dans un monde parfait), il faut que toute la base tienne dans la ram (en gros). Mais si cela doit absolument etre le cas, alors il ne sert a rien de gagner de la place en utilisant du raid5 plutot que du raid 10, vu que clairement personne n'a ne serait-ce que 36 Go de ram dans sa machine
 
Concernant la complexité, justement, tout le probleme des B-Tree, c'est de permettre une lecture (donc, un select) accelérée, a *condition* que ce B-Tree soit correctement balancé, et pour cela, il y a tout un tas de calcul a faire lors des inserts, il faut parfois rebalancé l'arbre, etc etc, ce qui est assez lourd. Encore une fois, oui, les écritures peuvent etre caché, mais cela n'empeche pas que lorsqu'il faut les écrirent, ca va bien plus vite sur du raid 10
 
Bref, finissons ce troll qui risque de durer bien longtemps sinon, mais crois moi, le raid 5 pour une bdd, c'est *mal*.

Krystal : Je pense que tu n'as jamais vraiment mesuré concrétement en utilisation site web la répartition de charge sur un MySQL correctement configuré entre les 2 systèmes là. Ca reste mon humble avis mais j'aimerais savoir sur quoi tu bases ton avis, les références qui te font dire ça.
 
Personnellement je pense avoir suffisamment comparé les différents systèmes sur N disques pour penser que pour un site web de type classique l'impact est loin d'être celui que tu prétends.

Pour être sûr : On parle bien de RAID Hardware SCSI là ?

 
En fait, l'administration systeme, c'est un peu mon metier, j'ai passé bien du temps a tester les differentes vitesse d'écriture, que ce soit avec mysql ou autre chose (flux videos multiple, nfs, etc etc), sur differente machine, avec differente carte et different disque, pour differente utilisation ...
 
Dans tout les cas, le raid 5 va moin vite en écriture. Et de beaucoups. Toujours. Genre 2 ou 3 fois, en fonction du nombre de disque.
 

 
Qu'il soit hardware ou software ne change pas grand chose, en fait.
 
Il se trouve meme que la plupart du temps, le raid software va bien plus vite que le raid hardware.
 
Le seul reel avantage du raid hard est quand la carte SCSI a vraiment beaucoup de cache, et que ce cache est batterie backuped. Et encore
 
Dans tout les cas, cela ne change pas la complexité des écritures dans le cas d'un raid 5, et donc de leur mauvaise performance par rapport a un raid 10.
 
 
 
Enfin vu l'animausité qui commence a transparaitre de tout ca, j'imagine que tu mets toujours du raid 5 et donc que mon dialogue t'ennuie pas mal, dans tout les cas, il doit commencer a devenir ininterressant pour la plupart des gens, aussi je t'invite a continuer en PV

Bah je pense que j'ai suffisamment d'expérience et que c'est mon métier depuis assez longtemps pour en discuter, sinon je ne me serais pas permis
 
Tu estimes à quelle ratio la différence et sur combien de disque par curiosité ?

 
Plus il y a de disques, et pire le ratio est.
 
Pour schématiser, ce n'est pas dur : le raid 5, en ecriture, va "a peu pret" a la vitesse d'un seul disque.
 
En théorie, le raid 10, s'il contient n disque, va n/2 fois plus vite.
 
Bien entendu, je ne parle pas des debits bruts lors de transfert linéaire la (meme si en pratique il ressemble tout de meme un peu a ca, avec un peu moin de malus pour le raid 5 qui tire plus partie de son cache), mais pour plein de petite ecriture/modification a droite a gauche sur un pool de data assez important.

Encore une fois j'aimerais avoir plutôt tes chiffres que des grandes théories qui ne prennent pas en compte tous ce qui est en jeu ( notamment les accès disques )

Heuuu dans ce que j'ai decris, il y a le temps des acces disques qui est pris en compte.
 
Dans tout les cas, les chiffres, tu les as : raid 5 == vitesse d'un seul disque (en ecriture), raid 10 == vitesse n/2.
 
Ces resultats cohérents au niveau logique apparaisse dans les tests pratiques.