Reprise du message précédent :
Le ratio de prizee.com est de 250 par serveur, c'est une chose sûre (nous connaissons les créateurs).
Nous avons pris en compte environ le même ratio. Nous n'avons pas 10 serveurs web, mais 5 serveurs MySQL pour 6 serveurs Web (soit une capacité de 1500 visiteurs).
Au début du topic, le traffic était de 300 connectés simultanés à cause d'une saturation du seul serveur Web. Suite aux améliorations, la fréquentation est passée directement à plus de 1000 connectés simultanés en pointe. Seulement, nous prévoyons un peu plus, car le site était de nouveau saturé, ce coup-ci, par le serveur MySQL commun, que nous venons de passer en Xeon+SCSI Raid1.
 
Autre chose : la programmation d'un forum est complètement différente d'un tel site. Un forum n'a aucun script en cron par exemple, alors que nous en avons 6/7 (ventes aux enchères, mise à jour de comptes, etc...).
 
Sinon, nous avons fait la demande de cluster chez ovh il y a deux semaines et nous devrions l'avoir cette semaine.

en toute honneteté je pense que tant que vous n'aurez personne de competant en infogérance dans votre staff ou en sous traitant vous perdrez de l'argent betement.

Là dessus, c'est sûr qu'un vrai admin ne serait peut-être pas inutile. Vous pensez qu'on peut en trouver qui travaillent en Freelance ?

Je fais partie de l'équipe de dev de Mountyhall et on est loin d'avoir votre architecture pour 12000 joueurs actifs (65000 inscrits mais ça compte pas ).
 
On a 1 serveur Web et 1 serveur MySQL et je pense qu'on a les mêmes problématiques que vous

ce qu'il te faudrait c'est un hebergeur competant en infogérance autant pour avoir une vision globale de ton infra que pour gerer les machines.
maintenant tu as plusieurs société qui peuvent proposer cela, selon ton budget, tes besoin etc etc.

Ce n'est pas moi qui gère le site (je ne suis que le programmeur), mais je vais en parler

12 000 joueurs actifs ou simultanés ?
Car le site a tourné 1 an et demi et jusqu'à plus de 70 000 joueurs actifs sur un serveur web + un bdd.
Si tu demandes à tous les créateurs de site de jeu en ligne, ils ont tous rencontré le même problème : l'affluence soudaine et brutale qui sature tout

 
Tiens ça me dit quelque chose, joce m'en a déjà parlé de Mountyhall

 
Oui, c'est clair, par contre ce serait peut être intéressant dans un premier temps de faire un audit de la plateforme avant de se lancer dans des dépenses récurrentes je pense.

Qu'entends-tu par simultané (l'éternelle question sur les applis web) ? Car HTTP est un protocole déconnecté. Sur ce forum (à moins que ça ait changé) par exemple on compte les utilisateurs sur 5 minutes.
 

Oui on est dans la même guilde Il participe à l'optimisation MySQL quand c'est nécessaire.
 

Tu sais bien ce que je veux dire

Non justement c'est pour ça que je te pose la question    

Ah ok (je croyais à un troll ) : c'est mis à jour toutes les minutes

Donc ton nombre de connectés c'est le nombre de personne qui font une action pendant une période de 1 minute, ok va falloir que je vois pour Mountyhall, pour comparer.

 
Ben voilà, c'est ec que je disais... Tu as trop de tâche cron qui tourne... Si tu éxécutes des scripts constemment, c'est normal que ça sature... Déjà ce genre de script doivent être compilé pr éviter les surcharges et accéléré leurs éxécutions.
 
Ensuite, essaie de trouver un moyen pour éxécuter moins souvent tes tâches crons.
 
Par exemple pour tes enchères, tu les clos la journée de 8h à 17h et tu ne le fait que la nuit et tu dit que ce service  
d'enchère est maintenant un marché noir (je ne connais pas ton jeu non plus, c juste une idée)
 
Pour les classement des joueurs, tu ne fais la mise à jour que 1 fois par heure voir moins.

Les enchères sont exécutées 1 fois par minute.
Les classements (très gourmands en ressources) ne sont exécutés, quant à eux, qu'une fois par nuit.
Les autres tâches crons mettent à jour des profils, etc...
 
Mais la compilation du script m'intéresse beaucoup : tu peux m'en dire plus ?

Si ce sont des requêtes SQL dans les scripts, le gain sera inexistant, c'est au niveau MySQL que ça se jouera.
 
Par contre le MySQL est peut être optimisable lui.

C'est quasiment que des requêtes SQL en effet.
Donc, le fait de compiler le script pour toi, n'aura aucun impact ?
Ca aurait peut-être le mérite de décharger les ressources Web, non ?
Sinon, je vais essayer d'optimiser les requêtes MySQL.

Non ça ne changera rien du tout, tout le traitement se faisant au niveau MySQL, les ressources utilisées par la partie PHP sont faibles. Par contre ton cron fonctionne de quelle manière ? Un appel à une page viua lynx ou wget ou un appel PHP direct ? Si c'est par appel de page, c'est plus propre de faire un "php /..../script.php" qu'un "wget http://..../script.php", même si ça change pas grand chose niveau ressources.
 
L'optimisation se fait sur les requêtes oui, également sur le serveur MySQL lui même potentiellement.

c'est un sujet trsé interessant qu'il pourrait etre utile de developper au niveau des moyen d'optimiser MySQl par exemple. Enfin, ca pourrait me servir grandement, je suis entrain de developper un site en PHP/MySQL. J'ai choisi de developper massivement en objet donc les requetes ne se font que qu'un seule fois le reste.  
 
C'etait pour moi une bonne solution pour éviter les lourdes requetes, ceci dit, cela doit aussi bouffer de la ressource mémoire.  
Je n'arrive d'ailleurs pas a imaginer les ressources que l'utilisation d'objet peuvent prendre par rapport au même résultat en requete SQL.  
Par exemple, chaque client est un objet PHP, qui est stocké en variable de session tout au long de sa visite. 1 requetes au debut et l'objet client est connu du debut a la fin sans autre intervention de la BDD.

Oui c'est assez intéressant, mais c'est tellement variable selon les configs et l'utilisation... Faut voir aussi qu'un index peut diviser par 4 la charge s'il était mal placé par exemple.

En faîtes quand je parlais de compiler je parlais plutot en faîtes d'essayer de passer au perl ou au cgi. L'avantage sera que apache passera peut-être un peu moins de temps sur le cron.
 
Au passage je viens de voir ce MRTG
http://ns20251.ovh.net/mrtg/
 
On voit que ton espace disque est entièrement occupé !! Ton serveur est complet...
 
C'est normal qui ramme   .

Il est remplacé par celui-ci : http://ns695.ovh.net/mrtg

Sur celui là aussi, ton serveur est plein.

 
Moi je vois 50%
 
Sinon pour le CGI et perl, le problème reste le même, les ressources utilisées sont minimes par rapport au reste

Oui effectivement, j'ai regardé un peu vite...
 
Mais il devrai passer par un/des filer dans ces conditions non ?

Y'a un intermédiaire entre un unique disque SATA et un filer quand même, c'est peut être pas nécessaire là.

J'avoue ne pas comprendre là

 
Qu'est ce que tu appelles un "filer" ?

C'est bizarre que ton site rame avec autant de serveurs.
 
Tu fais combien de req/s avec apache et mysql? Avec mysql active le log des slow_query pour regarder si ya pas qqchose à améliorer à ce niveau.
 
Sinon je te conseille également de passer par une boite d'infogérance pour optimiser tes serveurs si tu n'as pas le temps/compétances pour le faire, tu seras gagnant et ca t'évitera de multiplier le nombre de serveurs.

Quelle version de MySQL aussi ?
 
@Limit : très bonne idée le slow-query, on optimise comme ça sur Mountyhall
 
Sur Mountyhall on est à 7000 requetes MySQL/minute avec des pics quotidiens à 10000.

tant qu'on en est dans les optimisations, quelqu'un a des liens vers des bonnes ressources pour l'optimisation web / mysql ?
 
(je galère sur un serveur d'images un peu roses qui rame comme pas possible, un P4 2.8 avec 1 go de ram et apache ne sort que 15 requètes par secondes  / 350 ko /s )
 
[sorry pour le HS]

Pour un serveur d'images qui booste je te conseille ça : http://www.acme.com/software/thttpd/

 
Je te sort la définition de OVH    
 

 
Ce sont des serveurs entièrement et uniquement dédié au stockage. Ils sont optimisés pour le stockage.  
Dans le sujet initial, cela pourrait être avantageux car ça diminuerai surement le nombre de serveur. On pourrait imaginer 1 filer de 80 go(par exemple, je ne connais pas la taille de la BDD) pour la BDD et 1 autre filer pour le reste(images, script etc...) et seulement 1 serveur "normal"(mais costaud quand même) avec apache et Mysql installé dessus, qui effectuerai les requêtes sur les filers.
 
Ca diminuerai (je pense) les coûts, on gagnerai aussi en rapidité. Ca n'encombrera pas le serveur principale(qui ne rammera donc pas), ça sécurisera les données...
 
Je pense que cette solution serai la meilleure et la plus simple à mettre en place.

Le site est coupé suite à un serveur de bdd qui a lâché. On est en train de transférer la sauvegarde, mais ça prend du temps

ah merde
 
j'ai un compte chez vous en plus

 
Ok on est d'accord, donc je le répète, il y a un intermédiaire entre un disque SATA seul et un filer...

 
aie

 
Donc je le répète, je ne comprensd pas  

 
Tu ne comprends pas quoi ? Je dis qu'un RAID SCSI sur le SQL pourrait déjà être une évolution très profitable et qu'il n'est peut être pas nécessaire de monopoliser une machine complète uniquement pour en faire un filer dont les CPU ne seront pas beaucoup utilisés au final.