Tout d'abord, ce n'est pas une réponse, mais une approche diagnostique.
Ce n'est en aucun cas complet - ou même quelque chose de proche, ce n'est qu'un point de départ.
Temps jusqu'au premier octet
Le délai jusqu'au premier octet (TTFB) comprend un certain nombre de composants:
- Recherche DNS: Trouver l'adresse IP du domaine (amélioration possible: serveurs DNS plus nombreux / distribués / réactifs)
- Temps de connexion: ouvrez un socket sur le serveur, négociez la connexion (la valeur typique devrait être autour du temps de «ping» - un aller-retour est généralement nécessaire - keepalive devrait aider pour les demandes ultérieures)
- En attente: le traitement initial requis avant l'envoi du premier octet (c'est là que devrait être votre amélioration - ce sera le plus important pour le contenu dynamique.
Lorsque vous regardez une sortie ApacheBench, vous voyez également:
- Traitement: il s'agit de la somme de l'attente + du transfert complet du contenu (si le temps de transfert est nettement plus long que ce qui serait attendu pour télécharger la quantité de données reçues, un traitement supplémentaire (après le premier octet reçu) est en cours (par exemple, la page est vidage du contenu tel qu'il est disponible)
Comparaisons pour éliminer les composants
À quelques exceptions près, votre problème va résider dans le traitement backend, qui se résume généralement à un code trop complexe / inefficace ou à une configuration MySQL mal configurée.
Un bon moyen d'aborder ce problème consiste à effectuer une série de comparaisons qui élimineront divers aspects de votre configuration. Une bonne comparaison doit rester aussi constante que possible pour aider à réduire le problème. Actuellement, vous avez fourni les comparaisons suivantes:
- Site identique (cloné) fonctionnant sur l'ancien serveur et le nouveau serveur:
- Différence: serveur
- Résultat: l'ancien serveur est rapide; le nouveau serveur est lent
- Notes: Ce dont vous avez besoin ici est de quantifier les différences entre ces serveurs - à la fois en termes de pile utilisée (Nginx, etc.) et de matériel (l'ancien serveur est-il plus rapide car c'est une machine plus puissante?)
- Conclusion: le code peut fonctionner rapidement sur la bonne configuration
- Site de test vs site complet sur le nouveau serveur
- Différence: contenu, thèmes, plugins, etc.
- Résultat: le site de test est rapide, le site complet est lent
- Remarques: en théorie, ce test devrait vous aider à éliminer de nombreux aspects de votre configuration - DNS, réseau, même votre configuration nginx / php / mysql - cependant, ce n'est pas tout à fait «juste».
- Conclusion: le contenu supplémentaire a un impact significatif sur les performances
Le test idéal vous obligerait à dupliquer votre site complet, puis à supprimer tout le contenu, sauf un article et les commentaires associés. Le but de ce test serait de déterminer de manière concluante si la grande quantité de contenu est le problème ou si d'autres aspects de votre configuration (plugins wordpress, thème, etc.) en sont la cause. Vous compareriez essentiellement les performances de sites identiques, sur le même (nouveau) serveur - en chargeant la même page (même longueur, etc.) - avec la seule différence étant le contenu total du site (par exemple, il y a de fortes chances qu'un plugin ne le fasse pas). bien évoluer avec un contenu accru).
Sans rien changer, vous pouvez faire d'autres comparaisons:
- Test à partir d'un emplacement distant par rapport à local - cela aidera à identifier si le réseau, la latence, le DNS, etc. sont la cause
- Vous avez déjà (quelque peu) fait cela et avez principalement conclu que vous n'aviez pas de problème de réseau.
- Testez via Varnish (c'est-à-dire le port 80) vs nginx directement (port 8080) - essayez de ne pas changer votre configuration entre les tests - utilisez simplement le bon port. Cela vous montrera l'impact du vernis. Étant donné que Varnish est une couche de mise en cache, il devrait servir très rapidement toutes les demandes après la première - essentiellement, il devrait contourner le backend et le traitement nécessaire pour générer une page dynamique et servir la copie en cache très rapidement.
- Vous l'avez fait (mais pas localement) et vous avez démontré que Varnish a un impact positif significatif sur vos performances.
Réglage de votre backend
À ce stade, vous devriez soit avoir trouvé le problème, soit conclu qu'il se trouve dans votre backend. Cela vous laisse Nginx, PHP ou MySQL.
(Je dois mentionner ici, qui est - il toujours utile de savoir si votre goulot d' étranglement est CPU, RAM, ou E / S - entre sar, top, iostat, vmstat, free., Etc , vous devriez être en mesure de venir à une conclusion à ce sujet )
Nginx
Nginx prend simplement les demandes et sert du contenu statique ou déplace les demandes vers PHP-FPM - il n'y a généralement pas grand-chose à optimiser avec Nginx.
- Définir les travailleurs = # cœurs de processeur
- Activer keepalive (une valeur de 10-15 est bonne)
- Désactiver la journalisation inutile
- Augmentez la taille des tampons si nécessaire
- Évitez les instructions if (utilisez des noms statiques au lieu d'expressions rationnelles dans la mesure du possible, éliminez les extensions inutiles)
Idéalement, votre blog de test et votre blog cloné ont des configurations identiques, auquel cas, vous avez effectivement éliminé Nginx comme problème.
Application
Dans le cas où vous essayez d'identifier un problème dans votre code (par exemple un plugin lent, etc.), les journaux lents sont le point de départ.
- Activez le journal lent MySQL et le journal lent PHP-FPM exécutez votre benchmark et voyez ce qui se présente comme lent.
MySQL
- Augmentez vos caches et exécutez mysqltuner.pl pour obtenir un bon point de départ.
PHP
- désactiver les extensions inutiles,
- désactiver register_globals, magic_quotes_ *, expose_php, register_argc_argv, always_populate_raw_post_data
- augmenter la mémoire_limit
- open_basedir et safe_mode ont d'importantes implications en termes de performances, mais peuvent également fournir une couche de défense supplémentaire. Testez avec et sans eux, pour déterminer si leur impact sur les performances est tolérable.
PHP-FPM
- Ajustez les valeurs pm. * - augmentez-les pour faire face à une charge élevée
Il convient de noter que vos résultats htop montrent que php-fpm consomme la majeure partie du processeur - et votre problème semble être directement lié à cela.
Mise en cache
Une fois que vous avez optimisé chaque goulot d'étranglement probable, commencez la mise en cache.
- Vous disposez déjà d'un cache opCode (APC) - assurez-vous qu'il fonctionne (il est fourni avec un fichier de test) - vérifiez vos taux d'accès au cache et, si possible, mettez le cache APC en mémoire plutôt qu'au disque.
- Configurez votre code pour le mettre en cache (par exemple en utilisant un plugin pour Wordpress tel que W3TC)
- Avec nginx, vous pouvez configurer la mise en cache FastCGI - mais comme vous avez Varnish, il vaut mieux éviter cela.
- Configurez une couche de mise en cache, telle que Varnish (ce que vous avez déjà fait) - et assurez-vous qu'elle fonctionne (par exemple, utilisez varnishstat, lisez Atteindre un taux de réussite élevé )
- Ajoutez plus de cache pour les composants de votre site - par exemple MemCached si applicable
Parfois, étant donné les limites de votre application et de votre matériel, il se peut que vous ne puissiez pas améliorer les performances du backend autant - cependant, c'est le point de la mise en cache - pour minimiser l'utilisation du backend.
Lectures complémentaires
if -fdirective que vous utilisez dans lelocationconteneur dans la configuration nginx. Sur la base de ce que je lis ici wiki.nginx.org/Pitfalls , j'ai le sentiment que le-ffait une recherche inefficace du fichier qui pourrait provoquer un problème de Time To First Byte, surtout si vous avez des répertoires avec un grand nombre de des dossiers.