Frustrant, n'est-ce pas? J'essaie de faire la même chose, voir comment mon serveur dédié nouvellement provisionné et configuré se compare aux autres. Ce que je finis par faire est de comparer mon serveur de production actuel (Dual Core 4 Go de RAM) au nouveau serveur (Quad Core 8 Go de RAM). J'ai besoin de «jouer sympa» avec mes comparaisons côte à côte, car le serveur de production est en ligne et je ne veux pas «casser» le serveur pour mes utilisateurs.
comparaison du courant vs nouvelle avec la commande suivante sur une page php qui appelle simplement phpinfo(): ab -kc 20 -t 60
Sur mon serveur de production actuel, je vois quelque chose comme ce qui suit, où il n'a pas pu terminer la tâche dans le laps de temps donné:
Time taken for tests: 60.1234 seconds
Complete requests: 24538
Failed requests: 58
(Connect: 0, Length: 58, Exceptions: 0)
Requests per second: 408.96 [#/sec] (mean)
Time per request: 48.905 [ms] (mean)
Time per request: 2.445 [ms] (mean, across all concurrent requests)
VS suivantes sur le nouveau serveur qui a terminé tous les tests de la moitié de la quantité de temps:
Time taken for tests: 29.838791 seconds
Complete requests: 50000
Failed requests: 11
(Connect: 0, Length: 11, Exceptions: 0)
Requests per second: 1675.67 [#/sec] (mean)
Time per request: 11.936 [ms] (mean)
Time per request: 0.597 [ms] (mean, across all concurrent requests)
Maintenant, ce n'est pas vraiment un test «équitable», car le serveur actuel gère 20 sites Web en plus du test d'évaluation. En outre, il est vraiment seulement tester Apache & php.
Mettre ce même test contre l'un de mes pages d'accueil plus complexes, qui « sent » lent sur le serveur actuel, je vois ce qui suit: serveur:
Time taken for tests: 60.14170 seconds
Complete requests: 510
Requests per second: 8.50 [#/sec] (mean)
Time per request: 2353.497 [ms] (mean)
Time per request: 117.675 [ms] (mean, across all concurrent requests)
Nouveau serveur:
Time taken for tests: 60.18651 seconds
Complete requests: 1974
Requests per second: 32.89 [#/sec] (mean)
Time per request: 608.092 [ms] (mean)
Time per request: 30.405 [ms] (mean, across all concurrent requests)
Ce test charge une page générée dynamiquement par Joomla CMS. C'est un peu plus un test du «monde réel». Encore une fois, avec le nouveau serveur ne traitant pas du trafic du site actuel, ce n'est pas une comparaison entre pommes et pommes. Je ne veux pas tester beaucoup plus ou je risque l'expérience de mon utilisateur final sur mes sites. Après avoir migré les sites vers le nouveau serveur, je prévois de refaire les tests ci-dessus afin de pouvoir voir les effets de mon trafic de site habituel sur l'analyse comparative. Résultats de la production de la même machine par rapport aux résultats d'essai inutilisés.
Maintenant, je cherche également à souligner le nouveau serveur et à m'assurer qu'il réagit bien. exécution de la commande ab -n -c 200 50000 Je regarde la haut commandement et de voir combien de CPU & mémoire sont utilisés tout en * f5 * ing la page dans mon navigateur pour voir si je reçois une des erreurs et aussi pour avoir une idée du temps qu'il faut au serveur pour répondre.
Mon premier test m'a donné:
Concurrency Level: 200
Time taken for tests: 692.160011 seconds
Complete requests: 50000
Failed requests: 30102
(Connect: 0, Length: 30102, Exceptions: 0)
Write errors: 0
Non-2xx responses: 30102
Total transferred: 456568770 bytes
HTML transferred: 442928962 bytes
Requests per second: 72.24 [#/sec] (mean)
Time per request: 2768.640 [ms] (mean)
Time per request: 13.843 [ms] (mean, across all concurrent requests)
Transfer rate: 644.17 [Kbytes/sec] received
Notez le taux de demande a échoué très élevé. Mon apache est réglé à un maximum de 250 demandes simultanées, mais mon MySQL était à seulement 175. MySQL était le point d'échec ici. Il ne pouvait pas traiter toutes les demandes provenant d'Apache. Le chargement de ma page de navigateur Web m'a donné une page d'erreur de connexion MySQL sur de nombreuses actualisations de pages. Donc, j'ai ajouté MySQL à 300 requêtes simultanées (je l'avais déjà fait, mais j'avais oublié de redémarrer MySQL, donc ça s'est avéré être un bon test - j'avais identifié un changement nécessaire, et j'ai accidentellement fait un test empirique test validant la nécessité du changement).
La prochaine course m'a donné les résultats suivants:
Concurrency Level: 200
Time taken for tests: 1399.999463 seconds
Complete requests: 50000
Failed requests: 5054
(Connect: 0, Length: 5054, Exceptions: 0)
Write errors: 0
Non-2xx responses: 5054
Total transferred: 1016767290 bytes
HTML transferred: 995713274 bytes
Requests per second: 35.71 [#/sec] (mean)
Time per request: 5599.998 [ms] (mean)
Time per request: 28.000 [ms] (mean, across all concurrent requests)
Transfer rate: 709.24 [Kbytes/sec] received
Cela a pris deux fois plus long, mais le taux de demandes ayant échoué était beaucoup plus faible. Fondamentalement, le serveur est maintenant configuré pour être capable de gérer au moins 200 pages vues simultanées d'une page d'accueil de mon site, mais cela prendra 5 secondes une page pour les servir. Pas génial, mais beaucoup mieux que les erreurs MySQL que je recevais précédemment. Pendant tout ce temps, mon utilisation du processeur du serveur est fixée à 100% avec la 'load average' planant au-dessus de 180. MySQL utilise environ 8-9% du CPU et n'utilise pas beaucoup de RAM I Je l'ai alloué, car je ne fais que marteler la même page à maintes reprises, donc il ne s'agit que d'une base de données unique. 400 Mo de 4 Go + il est configuré pour devenir. top montre l'utilisation de la mémoire tampon et de la mémoire cache à environ 50% de la RAM totale disponible. Donc, pendant que je charge la machine avec ce test, ça ne se rapproche pas du point surchargé. Dans le cadre d'une utilisation réelle de la base de données, MySQL devrait récupérer une grande partie de la mémoire que je lui ai allouée, de sorte que le serveur devrait être assez proche de la pleine charge à ce moment-là.
Mon prochain test était de tester apache à la 'pleine charge' de 250 connexions ab -n -c 50000 250
Concurrency Level: 250
Time taken for tests: 1442.515514 seconds
Complete requests: 50000
Failed requests: 3509
(Connect: 0, Length: 3509, Exceptions: 0)
Write errors: 0
Non-2xx responses: 3509
Total transferred: 1051321215 bytes
HTML transferred: 1029809879 bytes
Requests per second: 34.66 [#/sec] (mean)
Time per request: 7212.577 [ms] (mean)
Time per request: 28.850 [ms] (mean, across all concurrent requests)
Transfer rate: 711.73 [Kbytes/sec] received
Cette montre des résultats similaires à l'épreuve de connexion 200 avec le bon MySQL bouchon de connexion. C'est bon pour moi je pense. Je n'aime pas les 7 secondes pour retourner une page, mais je pense que je peux améliorer cela au niveau de Joomla en activant le cache dans Joomla soit avec APC ou Memcache qui sont tous les deux installés mais pas encore utilisés par Joomla.
En essayant de pousser ma chance, j'ai pensé que j'essaierais 300 connexions simultanées. ab -n 50000 -c 300 Le navigateur affiche une longue attente pour un chargement rapide de la page. Sinon, pas vraiment beaucoup de changement dans les résultats.
Concurrency Level: 300
Time taken for tests: 1478.35890 seconds
Complete requests: 50000
Failed requests: 2266
(Connect: 0, Length: 2266, Exceptions: 0)
Write errors: 0
Non-2xx responses: 2266
Total transferred: 1079120910 bytes
HTML transferred: 1057241646 bytes
Requests per second: 33.83 [#/sec] (mean)
Time per request: 8868.215 [ms] (mean)
Time per request: 29.561 [ms] (mean, across all concurrent requests)
Transfer rate: 712.99 [Kbytes/sec] received
Je ne sais pas si mon interprétation de ces résultats sont « droit » ou si je manque quelque chose valueable, mais avec le manque d'instruction que je pouvais trouver, ce que je suis venu avec. J'ai juste utilisé les résultats pour m'assurer d'avoir un bon taux de réponse - l'absence d'un taux de réponse parfait m'inquiète, mais je ne sais pas comment voir ou reproduire les échecs d'une manière que je peux les inspecter .
La lenteur de la requête me préoccupe également, mais je pense que je peux en traiter une grande partie au niveau de la couche application. Je suis confiant que pendant que le serveur ralentirait à une exploration, il pourrait manipuler une situation lourde de charge.En regardant d'autres outils d'optimisation des performances comme MonYog après ces tests d'évaluation, j'ai également constaté que mes configurations actuelles sont «assez bonnes». Je souhaite qu'il y avait un endroit où les gens ont posté des résultats de tests que je peux reproduire avec une description matérielle et des configurations logicielles, donc je sais si je suis "compétitif" ou si j'ai encore beaucoup de travail à faire pour utiliser au mieux mon équipement. Ainsi, pourquoi je publie mes résultats.
Je pense que vous pourriez mal interpréter la ligne de demande ayant échoué, voir aussi ma réponse. – amarillion
Merci pour l'amarillion de clarification – creuzerm
testez-vous ab sur la machine locale? C'est-à-dire que vous faites AB sur la même machine que le serveur Web. Je reçois seulement plus de 1k demandes par seconde quand je fais le test d'apache sur mon propre ordinateur. – David