Reprise du message précédent :
Par expérience je peux te dire que mod_gzip fait plus chier qu'autre chose sur les serveurs... mais bon.
Edit : et si sa machine tien deja pas la charge, je sais pas si c'est la peine d'amplifier le problème
 
Moi je lui conseil de changer d'hébergeur .. et suivant son budget de s'orienter vers des solutions managés ou du haut de gamme.
Genre un BiXeon ou Athl64 avec énormement de ram pour le MySQL + un Xeon ou P4 pour le Web....le tout avec du disque SCSI
(et moi je pense que le tout peut meme ce regrouper sur un unique bixeon ... il faudrai avoir d'autres informations)
 
TurckMMCache => oui mais bon ca fera pas des masses si il a un gros problème de surcharge
 
nero27 si tu veux laisse moi ton tel en PV et je te conseillerai un peu...
nero.. vérifie déjà que certains paramettres comme le KeepAlive .. et essai de le desactiver mais aussi que ton my.cnf soit bien config.
C'est beau de parler de prog etc.. mais souvant le soucis est bien logiciel : un mysql avec un fichier config mal adapté peut vite s'emballer. Idem pour apache. Tu as aussi des correctifs/patchs sur les noyaux des machines : pour par exemple restraindre les attentes I/O (bug constaté sur des kernels 2.4 par exemple) et l'utilisation CPU du même coup.
Beaucoups trop de personnes pensent que gérer un dédié ce fait en un claquement de doight.. mais tout ça demande des compétances !
 
 
Sinon des solutions avec load balancer existent chez ev1servers.net par exemple mais c'est aux US et cher...
Si ton ami à genre 1000euro de budget et plus... il peut trouver une bonne solution je pense mais si il ne sais pas gérer un serveur laisse tomber le dédié classique car les problèmes vont s'amplifier avec le temp.
Que ce soit pour les hébergeurs mutualisés, les gens qui prennent des dédiés etc.. le boulo de pro doit être confier aux professionnels, c'est mon avis. L'hébergement est un vrai métier qui est d'ailleur parfois difficile et on ne peut pas s'improviser technicien.
 
Si ca ce trouve son serveur ce mange des attaques via http à longueur de journée et il le sait même pas !
Flood sur Apache > utilisation massive du CPU/Mémoire par exemple.. et si il y connait rien il ne vera meme pas.
Idem pour des attaques autres...

Je parlais pas de mod_gzip mais de la gestion gzip intégrée à PHP (1 ligne à changer dans le php.ini)
Ce qu'il va perdre en CPU il va le gagner ailleurs sans pb
 
Il peut essayer en tout cas.
Idem pour un opcode cache (genre TurckMMCache).
 
Je pense que son archi peut tenir la charge sans problème si il y a les bon outils coté serveur et que l'appli est optimisée (surtout au niveau des requetes SQL).
 
Mais c'est sur que si y a pas d'index dans la base (ou d'autre erreur genre l'utilisation du OR dans les requetes), ils va en falloir des serveurs
 
PS : pour info je participe à un jeu en ligne qui a les mêmes problématiques et qui tourne avec 1 frontal et 1 serveur MySQL.

Tu préconises quoi à la place du OR dans les requêtes ?
 
Sinon, pour les réglages serveurs, je vais lui en parler

Faut mettre des UNION (le problème se pose si tu fais un or sur 2 champs différents)
http://dev.mysql.com/doc/mysql/en/ [...] -keys.html
 
Une page pas trop mal : http://www.chevrel.org/fr/optimiser/phpmysql/
 
C'est toi le développeur du site dont tu parles ?
 
Dans les trucs à éviter : les LIKE, les requetes dans des boucles au lieu d'utiliser des jointures...

Je n'ai aucun probleme avec ma base de données, j'ai fait un système de répartition de charge, les nouveaux membres sont inscrits automatiquement sur le serveur le moins chargé.
 
Un de mes serveurs de BD est environ capable de gérer 50 000 membres en de dépassant pas les 100% de charge et cela, je pense, parce que j'ai des grosses tables d'historique (une table à 14 000 000, une autre à 10 000 000, une autre à 4 500 000, cela pour 70 000 membres sur mon seveur BD le plus utilisé).
 
Mon probleme se situe sur l'unique serveur web, bien que je lui ai stocké les images sur un autre pour alléger. Voici sa charge : http://ns2978.ovh.net/mrtg/
 
J'ai essayé hier d'augmenter le Apache Max client de 150 à 300 pour voir mais je crois que ça rame encore plus.    
 
En résumé : comment concrètement utiliser plusieurs serveurs web qui se partageraient les requêtes ?

Salut
 
T'as pas essayé la compression gzip et un opcode cache comme je l'ai suggéré ?

gzip va permetre de réduire la taille de mes pages, or je ne sature pas en bande passante mais en CPU, ça va empirer le problème ! Je suis déja à 100% d'utilisation CPU ! Ca aurait été interressant si je saturais en bande passante.
 
TurckMMCache c'est quoi ?

un systeme de cache qui emepeche d'avoir a generer 50x la meme page sans que le contenu dynamique ait change

Le gzip n'est pas seulement intéressant pour la taille des pages, ça fait baisser le temps de génération (chez moi j'ai des pages qui sont passées de 2sec à 100ms juste en l'activant).
 
En effet, si tu as une page un  peu lourde à envoyer au client et que ton code affiche les infos au fur et à mesure, le script va "attendre" le client avant de continuer. Si tu gzip, il génrères tout coté serveur PUIS envoit au client. Donc tu y gagnes quasiment tout le temps avec le gzip.
 
Teste avec ceci au début de tes pages : ob_start('ob_gzhandler')
 
TurckMMCache c'est un opcode cache : http://developpeur.journaldunet.co [...] ser4.shtml

prenez des serveurs avec des disques NON IDE ca aidera deja a decharger vos CPU. (Sata ou scsi)

Il me semble (dit moi si je me trompe) que c'est surtout valable pour le serveur DB.

Ok, je vais essayer gzip et TurckMMCache.
 
Je pense que ça va me faire gagner un peu mais qu'il faudra tout de même que je passe par un second serveur web en parallèle, alors j'attends toujours plus d'infos si vous avez de bonnes connaissances dans le domaine.  

regarde aussi la config de ton httpd.conf, en jouant avec les 4 valeurs de config ya déjà moyen de gagner pas mal.
(essaie en desactivant le keepalive, dans certains cas ça peut aider)
 
truckmmcache ou encore zendoptimizer vont te decharger le cpu un bon coup (en gros ils vont eviter la réinterprétation des pages php les plus demandées)
 
sinon, pour faire du load balancing rapide,si tout est dans les bases sql et qu'il n'y a rien qui est ecrit en local, tu peux mettre plusieurs addresses A dans le dns
www  A ip1
www  A ip2
www  A ip3
c'est du dns round robin, plus simple que du clustering et si tout repose sur les bases sql, ça doit marcher sans problème.

ptêt qu ils pourront te conseiller
 
 
http://www.nainwak.org/

 
faudrait qu'il explique un peu comment ca tourne pour tirer des conclusions. Mais effectivement, je penche aussi pour la même réponse que toi...
Peut etre qu'en déplaçant certains traitements sur des applis en C ou peut etre en des scripts en PERL, je sais pas, ca pourrait réduire la charge.  
 
En fait d'aprés les graphes,on dirait quand meme que Apache a du mal... Pourquoi a t il du mal      
 
Je connais pas vraiment le monde des jeux sur le net, donc je peux pas trop t'aider a ce niveau la.

Pour vous donner une idée:
-chaque joueur clique sur un lien toutes les 1 à 5s
-300 à 650 joueurs simultanés
-chaque clic correspond à un ou plusieurs accès à la base

Dans ce cas je pense qu'il faudrait peut être revoir le code et surtout les requêtes SQL

c'est clair que quand j'ai decouvert les union, mon nobre de requete a ete divise par 15-20

Mais c'est apache qui sature et pas MySQL, donc je ne pense pas que ça vienne des requêtes.

Et tu penses pas que c'est indissociable ?

Comment ça ?

Si tes requêtes SQL rament => temps de génération important coté serveur web => Apache rame

Je penche aussi pour un problème d'optimisation des requêtes.

Nette améioration des perfs avec l'installation de TurckMMCache
 
C'est encore jouable avec 520 connectés alors qu'avant on obtenait ce résultat jusqu'à 350 connectés.

Je dis pas que des betises
 
Maintenant un audit du code, des requetes et de la structure des tables (index notamment) et vous pourrez monter +

ca doit pouvoir se voir avec l'utilisation cpu
dans mon cas c'est clairement php qui mange tout le cpu

peu etre que tu trouveras des prestataires plus apte a te suivre dans le developpement de ton site que ovh tout de meme

Idem ça rame vraiment alors qu'il y a peu de personnes connectées (200).
Quelles sont les caractéristiques des 5 serveurs utilisés (disque, cpu,ram).
Quel est le traffic total consommé ? (je sais que ce n'est pas celà le problème mais celà permet quand même de s'y retrouver).

En fait, le nombre de connectés n'est plus calculé le temps que je fasse des tests pour une nouvelle fonction du site.
Donc si tu t'es connecté vers 16h30, il y avait environ 500/600 connectés. En plus, je faisais tourner un script sur le serveur
 
Sinon, c'est un P4 3.0GHz, 1Go de RAM, 160Go SATA pour le serveur apache.

A mon avis pour une archi de ce type ça peut être intéressant de faire un audit auprès d'une boîte qui maitrise le sujet. Vu le site et vu les serveurs, il y a moyen de faire probablement quelques chose de bien sans racheter du matos.
 
Mieux que Tuck MMCache, son successeur eAccelerator qui reprend le dev de Turck MMCache qui n'est plus maintenu. Cependant comme TOUS les accelerateurs PHP gratuits, ça bugge dans certaines conditions.
 
Tu sais où se situe la saturation ? ( CPU, I/O disk , RAM, ... )

en tout cas ce topic est tres interessant

Ca sature au niveau CPU.

Au risque de dire une connerie, je me demande si, à l'image d'un noyau linux, on ne peut pas soigner la compilation d'apache pour enlever les modules intiles, le rendre plus léger et rapide.

Comme je le pensais, la saturation ne venait en rien du SQL (mes requetes sont sur optimisées   ) mais bien du serveur web.
 
Un ami m'a indiqué comment utiliser plusieurs serveurs web de façon simple :
 
il suffit de modifier le fichier named.conf et de rajouter les IP des serveurs pour www.
 
exemple :
 
                IN      NS      ns.ovh.net.
                IN      MX      10 mail.monchval.com.
                IN      A       213.186.61.56
www             IN      A       213.186.61.56
www             IN      A       213.186.61.220
mail            IN      A       213.186.61.56
smtp            IN      A       213.186.61.56
 

Bien sûr, c'est ce qui a été dit dans le topic d'ailleurs, ne pas faire un cluster mais faire plusieurs frontaux webs en round robin DNS, ou en loadbalancing si tu as plus de moyens.

en effet c ce que j'ai mis dans ma réponse en première page...

Bah oui c'est dommage de faire un topic pour ne pas prêter attention aux réponses et sortir la solution d'un ami qui reprend ce qui a été dit dans le topic bien avant
 
On est là pour aider, faut en profiter. Sinon moi je te disais que je te fais un devis pour te monter un cluster Linux et te l'héberger avec infogérance, y'avait pas de problème, tu payais plus cher pour cette solution mais tu avais ton cluster

C'est quoi au juste la différence entre le load balancing et le cluster ?
(Excusez mon ignorance )

...

les DNS en round robin peut ne pas regler ton probleme. Du fait que tu n'envoi pas forcement sur le serveur qui sera le moins chargé.
Pour faire cela, c'est encore autre chose " load balacing " dont on a un peu parlé.

 
Un cluster c'est avoir un même système qui regroupe les ressources de plusieurs machines physiques, un load balancing classique c'est avoir plusieurs systèmes sur autant de serveurs qui délivrent la même chose ( en gros des clones )