Saturation d'un serveur à cause du php, vous avez connu ca?

[fat-freddy]

Salut,

Je suis en train de mettre au point un site qui devrait recevoir un grand nombre de visiteur, je dispose d'un serveur Superplan chez ovh, Celeron-2.6 GHz et 128 Mo de ram et j'ai peur que mon serveur sature vite à cause des requêtes sql.

Avez vous déjà été confronté a ce probléme ? Si oui quel volume de visiteur cela représenté et dans quel contexte ? A savoir qu'il y a 3 requêtes assez simples sur chacune de mes pages.

Merci pour vos lumières :wink:
Fat

 

[fredsoft]

128 mo c'est pas assez

 

[totoro]

Le nb de visiteurs ne signifie rien, il faut plutot voir le nb de requetes si reelement ca vient de ca.

Tu as des accès sur la charge du serveur et d'apache (genre MRTG et phpsysinfo) ?

 

[spijoelx]

plusieurs éléments rentrent en compte en plus du nombre de pages affichées, comme le nombre de requete par page, l'optimisation de ton script, la configuration de ton mysql..

mais 128 de ram comme dit plus haut c'est pas suffisant, et ça l'est encore moins si tu comptes recevoir pas mal de trafic.

 

[fat-freddy]

ok 128 ce n'est pas suffisant mais pour quel ordre de volume ??

est-ce que cela pourrait supporté 50 000 visiteurs par jour à raison de 3 requêtes par page ou cela bloquerait déjà à 15 000 ?

c'est juste une approximation basée sur vos expériences que je souhaite, rien de bien precis...

 

[stream]

Salut freddy,

A mon avis, tu vas saturer dès 5 OOO visiteurs, mais c'est surtout le nombre de connexions simultanées qui est le + important.
Tu vas souvent avoir ce message :
" Too many connections ..."

Il te faut un minimum de 512 Mo.

 

[berberber]

En fait, pour en avoir fait l'experience, un serveur OVH de base comme celui-ci, n'est pas forcement livré avec une optimisation mysql. Clairement (seulement par experience 128 Mo ce n'est pas beaucoup), mais une optimisation des réglages (fait appel à un spécialiste si tu ne sais pas faire), permet d'ameliorer, avec les ressources disponibles grandement ton rendement, et permet plus de connexions mysql et de visites.

Une autre chose à voir serait peut etre de regarder l'architecture de ton site. De prévoir un cache par exemple. Mais là tout dépend de toi.

Tu parles de 50 000 visiteurs ou pages ?

A titre d'exemple, mon serveur avec 500 Mo de RAM il y a peu saturait lors de 25 000 (incluant des requetes mysql, car le probleme est souvent là) pages vues par jour.

 

[fat-freddy]

Oui je parlais bien de 50 000 visites par jour, ce n'est pas pour de suite mais j'espére y arriver donc je préfére anticiper

C'est étrange qu'un serveur dédier ne puisse pas supporter une si petite charge...

Vous auriez de bon lien de tuto pour optimiser la config mysql ?

thx

 

[Digit]

Faut voir aussi si les scripts PHP manipulent de gros objets gourmands en RAM, ce qui aura un impact négatif.
La durée de génération d'une page intervient également, car elle augmente le nb de pages servies simultanément et donc la conso RAM.

 

[nycius]

C'est étrange qu'un serveur dédier ne puisse pas supporter une si petite charge...

> euh tu tables sur des gros chiffres si cest du VU
50 000 * 30 = 1 500 000

avec 1 500 000 VU par mois ta pas un superplan chez ovh lolol

ta 2 serveurs mini qui se repartissent les charges

tu as qua prendre un serveur qui supporte les img et lautre qui gere les pages et un autre qui supporte ta base

 

[fat-freddy]

J'aurai imaginé être tranquille plus longtemps avec ce dédié ... zut

Sinon dans la série tuto vous en auriez un qui liste les ressources pompées par tel ou tel objets ou fonctions php, qui propose des optimisations efficaces ?

Je n'est rien trouvé de terrible sur le sujet...

 

[WebRankInfo]

vous auriez pas un tuto précisément sur l'optimisation des tables et des requêtes MySQL ? Du genre comment définir des clés, comment optimiser le + possible des requêtes MySQL ? Ca pourrait servir au serveur de WRI...

 

[nycius]

il y a ca :
http://dev.mysql.com/doc/mysql/fr/Optimization.html

utilisation de EXPLAIN
http://dev.mysql.com/doc/mysql/fr/EXPLAIN.html

 

[oberon]

quelques trucs ici :
http://www.chevrel.org/fr/optimiser/phpmysql/

en résumé : utilise la commande mysql explain, mets une solution de cache page en place.

 

[fat-freddy]

trés intéressants ces liens, je vais me pencher sur la mise en cache de mes pages, cela me semble une trés bonne solution
merci !

 

[totoro]

D'autres soluces à ne pas oublier :
- mise en cache de pages (surtout si tu as de l'espace disque), comme turck-mmcache (qui en passant optimise le code php)
- optimisation de ton apache (avec activation des options spécifiques à ton serveur, comme MMX, ...)
- optimisation de ton code (virer des requettes trop gourmandes avec des DISTINCT a tout va ou se genre de chose (quel plaie ce distinct...))

Quand ces voies auront été explorées, ca devrait déjà aller mieux...

Après tu ajoutes de la Ram, tu fais un référencement du feu de dieu, et surtout, surtout tu nous préviens quand tu atteints ts 50.000 VU / Jour, ca peut interesser pas mal de monde ici 8)

 

[shrom]

Une autre chose à laquelle on ne fait pas assez attention en général. Il ne faut pas optimiser les tables comme on le fait pour une application normale.

Si on veut des temps de réponse corrects et ne pas trop charger le serveur, il faut souvent dénormaliser les tables.Ca demande un peu plus de boulot lorsqu'on fait des insertions ( insertions multiples ) mais on obtient de très bons résultats en consultation.

Eviter aussi les requêtes récursives ( souvent utilisées dans les scripts de forums ) et préférer une organisation par représentation intervallaire.

Pour le reste des optimisations, la doc MySQL ou PostgreSQL suffiront.

 

[Bobez]

Merci oberon pour ce lien intéressant et nycius pour le complément sur EXPLAIN.

 

[Eservice]

Eviter aussi les requêtes récursives ( souvent utilisées dans les scripts de forums ) et préférer une organisation par représentation intervallaire.

kesako ?

 

[shrom]

Eviter aussi les requêtes récursives ( souvent utilisées dans les scripts de forums ) et préférer une organisation par représentation intervallaire.

kesako ?

Bonne introduction en Français:
http://sqlpro.developpez.com/cours/arborescence/

Il y a d'autres articles en anglais qui détaillent en profondeur le mécanisme.

 

[Eservice]

Merci shrom

Une remarque : les ajouts d'INDEX accélèrent les SELECT (si ils sont réellement utilisés par le SGBD : voir les liens précédents), mais ralentissent les INSERT (et UPDATE).
Il est préférable de commencer par n'ajouter que les INDEX les plus souvent utiles (les script php les plus fréquemment utilisés), à raison d'un INDEX par TABLE à la fois.
Si les gains sont insuffisants en ajouter un et retester.

Eviter aussi les INDEX sur une colonne contenant peu de valeurs. Par exemple un INDEX sur une colonne contenant 1, 2 ou 3 n'apportera rien.

 

[Digit]

Eviter aussi les grosses tables en RAM, elles occupent plus de place que les tables ISAM classiques (donc TRES gourmandes en RAM) et ne permettent pas certaines fonctionnalités (par exemple optimize)

 

[caro]

quelques trucs ici :
http://www.chevrel.org/fr/optimiser/phpmysql/

très bon tuto,
à lire absolument !

 

[totoro]

Bonne introduction en Français:
http://sqlpro.developpez.com/cours/arborescence/

Il y a d'autres articles en anglais qui détaillent en profondeur le mécanisme.

Je doute que cette solution la plus facile a mettre en oeuvre...
En tout cas ca a l'air efficace, mais bon, la gestion d'un arbre avec gestion bord droit, gauche, etc. n'est pas évidente pour tout le monde...

 

[shrom]

Je doute que cette solution la plus facile a mettre en oeuvre...
En tout cas ca a l'air efficace, mais bon, la gestion d'un arbre avec gestion bord droit, gauche, etc. n'est pas évidente pour tout le monde...

C'est pour cela qu'il y a des professionnels dans le développement d'applications. Si c'était toujours facile, je me retrouverais vite à pointer à l'ANPE.