Pourquoi le temps de réponse explose-t-il lorsque la fréquence des demandes diminue?

Correction : le temps de réponse ( %D) est μs pas ms! 1

Cela ne change rien à l'étrangeté de ce modèle, mais cela signifie qu'il est pratiquement moins dévastateur.

Pourquoi le temps de réponse est-il inversement corrélé à la fréquence de demande?

Le serveur ne devrait-il pas répondre plus rapidement lorsqu'il est moins occupé à traiter les demandes?

Une suggestion sur la façon de faire profiter Apache de moins de charge?

Ce modèle est périodique. Cela signifie qu'il apparaîtra si les impressions tombent en dessous d'environ 200 demandes par minute - ce qui se produit (en raison de l'activité naturelle des utilisateurs) de la fin de la nuit au petit matin.

Les requêtes sont des POST très simples envoyant un JSON de moins de 1000 caractères - ce JSON est stocké (ajouté à un fichier texte) - c'est tout. La réponse est simplement "-".

Les données affichées dans les graphiques ont été enregistrées avec Apache lui-même:

LogFormat "%{%Y-%m-%d+%H:%M:%S}t %k %D %I %O" performance
CustomLog "/var/log/apache2/performance.log" performance

Il s'agit d'un comportement courant dans les centres de données. Le temps de réponse lent correspond à ce que l'on appelle communément la fenêtre de lot. Il s'agit d'une période pendant laquelle l'activité de l'utilisateur devrait être faible et des processus par lots peuvent être exécutés. Des sauvegardes sont également effectuées pendant cette période. Ces activités peuvent mettre à rude épreuve les ressources du serveur et des réseaux, entraînant des problèmes de performances comme vous le voyez.

Il existe quelques ressources qui peuvent provoquer des problèmes:

• Charge CPU élevée. Cela peut amener apache à attendre une tranche de temps pour traiter la demande.
• Utilisation élevée de la mémoire. Cela peut vider les tampons qui permettent à apache de servir les ressources sans les lire depuis le disque. Il peut également provoquer la pagination / l'échange de travailleurs apache.
• Activité disque élevée. Cela peut entraîner la mise en file d'attente des activités d'E / S disque avec des retards correspondants dans la diffusion du contenu.
• Activité réseau élevée. Cela peut entraîner la mise en file d'attente des paquets pour la transmission, augmenter les tentatives et dégrader le service.

J'utilise sarpour enquêter publié comme ça. atsarpeut être utilisé pour recueillir des sardonnées dans des fichiers de données quotidiens. Ceux-ci peuvent être examinés pour voir à quoi ressemble le comportement du système pendant la journée lorsque les performances sont normales et pendant la nuit lorsque les performances sont variables.

Si vous surveillez le système avec muninou un autre système qui collecte et représente graphiquement l'utilisation des ressources, vous pouvez y trouver des indicateurs. Je trouve toujours sarplus précis.

Il existe des outils comme niceet ionicequi peuvent être appliqués aux processus par lots pour minimiser leur impact. Ils ne sont efficaces que pour les problèmes de CPU ou d'E / S. Il est peu probable qu'ils résolvent les problèmes liés à l'activité de la mémoire ou du réseau.

Déplacer l'activité de sauvegarde vers un réseau distinct et réduire les conflits de réseau. Certains logiciels de sauvegarde peuvent être configurés pour limiter la bande passante qui sera utilisée. Cela pourrait résoudre les conflits de réseau.

Selon la façon dont les processus par lots sont déclenchés, vous pourrez peut-être limiter le nombre de processus par lots exécutés en parallèle. Cela peut en fait améliorer les performances des processus par lots car ils connaissent probablement le même conflit de ressources.

Cette relation peut se produire dans l'autre sens si les expéditeurs de demande attendent la fin d'une demande précédente avant d'en soumettre une nouvelle. Dans ce cas, le trafic diminue à mesure que le temps de demande augmente (pour une raison quelconque), en raison de la mise en file d'attente côté client.

Ou cela peut être un artefact de votre mesure - si le graphique ci-dessus montre les demandes terminées , par opposition aux demandes arrivantes , le taux baissera à mesure que le temps de traitement des demandes augmente (en supposant une capacité finie: D).

Bien que la réponse de @ BillThor puisse être correcte, il semble peu probable que la période de faible charge soit entièrement occupée par les processus de sauvegarde (c'est-à-dire que les périodes correspondent précisément).

Une autre explication est simplement la mise en cache. Si un script / une base de données / quelque chose n'a pas été utilisé récemment, les données en cache pertinentes peuvent avoir été supprimées afin de libérer de la mémoire pour le reste du système d'exploitation. Cela peut être des index sur une base de données, ou des tampons O / S par rapport à un fichier, ou toute autre chose similaire. Une requête va alors devoir reconstituer ces informations si cela fait un certain temps depuis la dernière requête. Dans les périodes chargées, cela ne se produira pas car la dernière requête aura été fréquente. Cela expliquerait également pourquoi vous voyez des temps de réponse faibles et des temps de réponse élevés pendant la période occupée.

Ce que vous voyez là-bas me semble être un problème statistique. Ce n'est peut-être pas le cas, la réponse de @ BillThor pourrait être juste, mais je posterai ceci pour être complet.

Les graphiques des temps de réponse sont basés sur le centile. Un pool d'échantillons de 800 à 1000 requêtes est un bon nombre d'échantillons pour cela, un pool de 50 à 100 requêtes n'est peut-être pas tellement.

Si vous supposez que le nombre de demandes lentes n'est pas une fonction linéaire du volume de demandes, de sorte qu'une augmentation de l'ordre de grandeur des demandes n'entraîne pas une augmentation de l'ordre de grandeur des demandes lentes, alors des volumes de demandes plus élevés se traduiront par temps de demande moyen inférieur.

Il y a des mensonges, de gros mensonges et des statistiques.

Mon hypothèse: vous avez trois catégories distinctes de demandes:

1. Le flux variable normal qui contient la majorité des demandes et celles-ci sont toutes terminées en 200-300 μs.
2. Petit flux à un débit constant d'environ 20 requêtes par minute (même la nuit). Chaque opération prend environ 2 500 μs.
3. Petit flux à un taux constant d'environ 10 requêtes par minute (même la nuit). Chacun prend bien au-dessus de 4.000 μs.

La nuit, les 50 demandes par minute sont respectivement 20 + 20 + 10. Et donc, le résultat du 50% centile dépend désormais fortement du résultat du flux 2. Et 95% du centile dépend du flux 3, il ne peut même jamais s'afficher sur le graphique.

Pendant la journée, les flux 2 + 3 sont bien cachés au-dessus du 95% percentile.

Plus j'y regarde, plus j'ai tendance à penser qu'il y a un problème avec la collecte de données.

Tout d'abord, il se passe quelque chose de vraiment bizarre avec votre TPS. Alors que le schéma global semble normal, il y a une coupure très nette se produisant vers 21 h, puis de nouveau vers 7 h. Un graphique normal sera beaucoup plus fluide pendant la transition vers les heures creuses.

Cela suggère qu'il y a un changement dans le profil, et vous avez peut-être 2 types de clients distincts:

1. Celui qui fonctionne uniquement entre 7 h (ish) et 21 h (ish), à des volumes élevés, et
2. un autre qui fonctionne probablement 24 heures sur 24, à des volumes inférieurs.

Le deuxième indice est vers 18h00. La plupart du temps avant et après, nous avons le haut profil de volume - élevé TPS et une faible latence. Mais vers 18h00, il y a une chute soudaine de 800-1000 tr / min à moins de 400 tr / min. Qu'est-ce qui pourrait éventuellement causer ça?

Le troisième indice est la réduction des temps de réponse du 5e centile. En fait, je préfère regarder les temps de réponse minimum (mais le 5e centile est peut-être meilleur) pour deux raisons: il me dit le temps de service (c'est-à-dire le temps de réponse moins la mise en file d'attente), et les temps de réponse ont tendance à suivre une distribution de Weibull, ce qui signifie que le mode (ou la valeur la plus courante) est juste au-dessus du minimum.

Donc, la descente dans le 5e centile me dit qu'il y a une interruption soudaine de la série, et le temps de service a en fait chuté même si la variance et les temps de réponse moyens ont considérablement augmenté.

Prochaines étapes

À ce stade, je plongerais profondément dans les journaux pour découvrir ce qui est différent à propos des échantillons à faible volume de 18h00 par rapport aux échantillons à volume élevé avant et après.

Je chercherais:

• différences de localisation géographique (dans le cas où la latence affecte le $ request_time)
• différences d'URL (ne devrait pas en être)
• différences dans la méthode HTTP (POST / GET) (ne devrait pas en être)
• demandes répétées de la même IP
• et toutes autres différences ...

BTW, "l'événement" de 18h00 est une preuve suffisante pour moi que cela n'a rien à voir avec la congestion / l'activité du centre de données. Pour que cela soit vrai, la congestion devrait entraîner une baisse du TPS, ce qui est possible à 18h00 mais extrêmement peu susceptible de provoquer une baisse soutenue et incurvée du TPS pendant 10 heures entre 21h00 et 7h00.