Site web lent, serveur inactif : où passe le temps

Pourquoi la base de données est le suspect habituel

Quand une page ralentit, la base de données est l'endroit où le symptôme devient visible en premier. Les connexions s'empilent, la liste des processus se remplit de requêtes en état sending data, et le slow query log se met à grossir. Tout cela est réel, et rien de cela ne dit où le temps est passé. La base se trouve à la fin de la plupart des chemins de requête. Une page qui l'appelle deux cents fois au lieu de deux, un worker qui garde une connexion ouverte pendant qu'il attend une passerelle de paiement, un cache contourné à chaque hit : chacun apparaît comme de la charge sur la base, parce que la base fait exactement ce qu'on lui demande, plus souvent qu'on ne devrait le lui demander.

Il en va de même pour le serveur. Une machine à forte charge est une machine à qui l'on donne du travail. Que ce travail soit nécessaire est une question à laquelle le graphique de charge ne peut pas répondre.

Tracez une requête, pas tout le site

La méthode consiste à choisir une URL lente et à la suivre à travers les couches, en mesurant à chaque frontière. Commencez de l'extérieur, depuis une machine qui n'est pas sur le même réseau, et laissez curl rapporter où passe le temps avant l'arrivée du premier octet.

$ curl -o /dev/null -s -w 'dns %{time_namelookup}  connect %{time_connect}  tls %{time_appconnect}  ttfb %{time_starttransfer}  total %{time_total}\n' https://www.example.com/slow-page

Si le temps jusqu'au premier octet représente l'essentiel du total, l'attente est côté serveur. Si le total est bien plus grand que le temps jusqu'au premier octet, la page est lourde ou le chemin entre le visiteur et le edge est l'histoire, et le serveur n'a pas pris part à l'attente.

Sur la machine, échantillonnez le CPU pendant que la requête lente est en cours, pas une heure creuse plus tard.

$ mpstat -P ALL 1 5
$ vmstat 1 5

Un serveur essentiellement inactif pendant une requête lente, sans iowait et sans steal, s'est disculpé. Le temps est passé à attendre quelque chose, pas à calculer.

Puis l'application. La plupart des frameworks peuvent journaliser, par requête, le nombre de requêtes SQL émises, le temps total passé dedans, et le temps passé dans les appels HTTP sortants. Activez-le pour l'URL lente. Deux nombres tranchent le débat : combien de requêtes SQL une page émet, et quelle part du temps horloge a été passée entièrement en dehors de l'application.

Enfin la base de données, avec le slow query log actif et un seuil assez bas pour attraper ce qui compte.

SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 0.2;
SET GLOBAL log_queries_not_using_indexes = ON;

Lisez le log pour la fenêtre de la requête lente. Une poignée de requêtes qui prennent chacune des secondes est un problème de base de données. Des milliers de requêtes qui prennent chacune une milliseconde est un problème d'application dont on accuse la base.

Les motifs que la mesure fait ressortir

Une fois les couches séparées, la cause prend généralement l'une de quelques formes.

Un endpoint appelé en boucle. Un front-end qui va rechercher la même ressource à chaque changement d'état, ou une page qui émet une requête par ligne au lieu d'une requête par page. La base répond vite à chaque appel. C'est leur nombre qui est le problème.

Un appel synchrone à quelqu'un d'autre. Un prestataire de paiement, un ERP, une API d'expédition, un tag manager, assis sur le chemin de la requête derrière un long timeout. Le serveur est inactif pendant toute l'attente, et la page est aussi lente que le tiers le plus lent dont elle dépend.

Un cache mis en échec. Des en-têtes qui interdisent la mise en cache sur des pages qui ne changent pas, ou aucun cache en edge devant un trafic anonyme qui n'a jamais été dynamique.

Des pools dimensionnés au hasard. Des pools de workers, de connexions et de buffers réglés trop grands aussi souvent que trop petits. Un pool bien plus grand que ce que la machine peut servir en parallèle transforme une file en thrash.

L'épuisement réel est la dernière forme, et quand il apparaît, il est généralement en aval de l'une des trois premières. Que la machine vienne à manquer de quelque chose est la fin de l'histoire, pas le début.

Ce qu'un serveur plus gros change

Ajouter des cœurs ou de la mémoire raccourcit la partie de la requête qui calculait. Si cette partie était déjà petite, la page ne devient pas plus rapide. L'attente déménage avec elle. La boucle boucle toujours, le tiers prend toujours son temps, le cache est toujours contourné. La mise à niveau cache aussi la mesure qui aurait trouvé la cause, parce que le graphique qui était rouge est maintenant orange, et le ticket se ferme.

C'est pourquoi nous traçons avant de faire un devis. Une plateforme saine reste ennuyeuse, et le travail consiste à trouver la couche qui possède le temps, même quand cette couche se situe au-dessus de tout ce que nous exploitons, et à rendre la mesure qui désigne la ligne.