ab est un peu ennuyeux si votre site a besoin de cookies, etc, ab est trop simple.
Fondamentalement, d'après mon expérience dans la réparation de plusieurs sites Web PHP implosants, cela se passe généralement comme ceci :
1) Les gens utilisent MySQL
Vous pouvez tout à fait utiliser MySQL, facebook et flickr (les fanboys de mysql adorent ceux-là) SI VOUS CONNAISSEZ LES GOTCHAS qui sont :
- Si vous avez une table MyISAM non en lecture seule et que toute requête de plus de 100 us (même sélectionne), vous êtes mort
Sur un site que j'ai réparé, le gars avait loué un serveur double-quad-core parce que "son site a besoin de puissance". Je regarde son site, je regarde mon site précédent avec> 100K membres et un tracker torrent qui tournait sur un serveur Via C7 micro-demi-pizzabox, et je lui dis, ton site tourne bien sur le Celeron 300 qui est dans mon sous-sol , et c'est même exagéré, je peux vous le louer pour la moitié du prix de votre Xeon, lol.
Il s'est avéré que le gars était un bon développeur et un gars vraiment sympa, mais il était nul à MySQL, donc son site avait le typique Search Query From Hell qui peut tuer n'importe quel site Web :
- 10 requêtes de recherche infernales par seconde (il avait environ 300 000 membres sur son site warez illégal)
- la requête de recherche depuis l'enfer prend environ 0,1 à 0,2 seconde
- un petit flux de mises à jour simultanées sur la même table MyISAM pour pimenter les choses
=> sérialisation totale (verrous en écriture MyISAM) de toutes les requêtes. 1 cœur à 100 %, 7 cœurs inactifs, loadavg> 1000 (oui il utilisait apache), temps de page> 30 secondes, ça marche.
Le correctif était simple :optimisez la requête de recherche depuis l'enfer, fixez le point 2) ci-dessous, passez à InnoDB, passez à lighttpd. loadavg est tombé à 0,02
2) MISES À JOUR
Personne n'est intéressé par les compteurs de pages.Issue 1 UPDATE pour chaque page vue et vous êtes mort.Ajoutez un peu de MyISAM pour plus d'effets. Aussi un tueur sur InnoDB, pas sur le verrouillage, mais plutôt sur les attentes d'E/S du disque de synchronisation.
3) TEXTE INTÉGRAL
- MyISAM n'est pas utilisable pour les tables en lecture-écriture à cause du verrouillage.
- MyISAM est aussi fiable qu'un ramdisk (en fait, moins :vous avez besoin d'un plantage du système d'exploitation pour corrompre un ramdisk, corrompre les tables MyISAM nécessite juste un plantage MySQL ou simplement trop le frapper simultanément, vous obtiendrez "moteur de table inconnu erreur", j'ai vu cela plusieurs fois)
- FULLTEXT non disponible sur InnoDB
- Toute insertion dans un index FULLTEXT déclenche presque une reconstruction complète de l'index (lorsque j'ai inséré un message de forum, il reconstruisait 400 Mo d'index)
==> Si vous avez besoin d'indexation de texte intégral, de performances et de fiabilité, utilisez Sphinx ou Xapian.
Je n'ai pas essayé Sphinx (les gens en disent du bien), mais Xapian recherche avec plaisir dans 4 Go de texte en un clin d'œil.
4) Les gens utilisent apache.
Cela se combine bien avec les points ci-dessus.
Contrairement à un serveur approprié comme lighttpd dont l'utilisation du processeur est indétectable (le minable Via C7 servait 100 hits HTTP/s et lighttpd utilisait moins de 1% de CPU), apache tuera votre boîte.
Lorsque MySQL commence à mourir (il meurt facilement), les clients commencent à appuyer fort sur F5, et bientôt vous avez environ 1000 processus apache, chacun contenant un interpréteur PHP, et chaque interpréteur PHP détient une connexion MySQL inactive, attendant un verrou MyISAM, sauf un, qui fait une mise à jour triviale de votre compteur de pages vues, mais cela prend un certain temps, car le serveur est parti en échange de déjeuner, à cause des processus 1000 apache et 1000 php et 1000 mysql.
Lighttpd n'utilise pas de processeur pour les pages statiques. Le seul moyen pour lighttpd de saturer votre processeur est de le frapper fort avec apachebench à environ 20 000 requêtes/s. Ensuite, Lighttpd parle à quelques-uns, comme 10 backends php-fcgi (2-4 par cœur, c'est bien) qui parlent à quelques connexions MySQL. Tout est beaucoup plus rapide en conséquence, et lorsqu'il est surchargé, il se dégrade gracieusement, pas de manière explosive.
Pour arriver à la question initiale, vous voulez certainement profiler vos requêtes SQL. Ajoutez un journal des requêtes à votre application PHP qui affiche (uniquement pour vous), la liste des requêtes et le temps qu'elles prennent, ainsi que le temps écoulé entre le début du script PHP et sa fin (les en-têtes/pieds de page sont un bon endroit pour ceci).
Pour une page complexe (hors recherche), vous vous attendez à environ 3 ms MySQL et 3 ms PHP, c'est une bonne cible. Vous avez bien sûr besoin d'un cache de code compilé PHP.
Pour la charge actuelle, vous pouvez faire plusieurs choses. Les réponses les plus coûteuses, mais les plus détaillées, seront fournies via une application d'entreprise telle que "Gomez".
Cependant, si vous cherchez à le faire vous-même, consultez mes réponses précédentes ci-dessous ou utilisez des utilitaires shell tels que :htop, top, w et use Apache server-status
Réponses précédentes avant la révision de la question :
Ce que vous demandez est parfois appelé profilage d'application.
Vous devez créer une formule de mémoire approximative comme :
httpd ram + utilisation de la mémoire php + utilisation du processus mysql =empreinte mémoire totale des requêtes
Vous aurez également besoin d'une formule CPU, mais vous pouvez également regarder en haut lors d'un test de charge.
Apache a la commande 'ab'.
"ab est un outil d'analyse comparative de votre serveur Apache Hypertext Transfer Protocol (HTTP). Il est conçu pour vous donner une idée des performances de votre installation Apache actuelle. Cela vous montre en particulier le nombre de requêtes par seconde que votre installation Apache est capable de traiter. " http://httpd.apache.org/docs/2.0/programs/ab.html
Voici une ligne de commande de référence générique "ab" :
ab -n 10 -c 1 http://www.yoursite.com/
# qty 10 total requests, 1 request at a time
La stratégie consiste à tester la charge par processus (utilisateur) sur votre application depuis la demande de page Web jusqu'à l'achèvement. Si vous pouvez identifier la quantité de RAM utilisée par Apache, PHP et MySQL pour chaque requête, vous pouvez rapidement identifier la capacité de votre système.
Vous devrez probablement utiliser une combinaison d'outils de diagnostic comme vmstat ou top ou iostat ou ps, etc. pour prendre un instantané de ce qu'un certain nombre de requêtes exigeront de votre système.
Enfin, vous allez vouloir installer Xdebug. Cet outil vous aidera à profiler le côté php de l'application.http://xdebug.org/
Voici le tutoriel d'IBM sur l'installation de Xdebug :
http://www.ibm.com/developerworks/opensource/library/os-php-fastapps2/