Tests de charge : modèles de charge ouverts et fermés

Ce que c'est

Un test de charge doit décider comment les nouvelles requêtes arrivent. Dans un modèle fermé, un nombre fixe d'utilisateurs virtuels envoient chacun une requête, attendent la réponse, puis envoient la suivante ; la documentation de k6 indique que dans le modèle fermé, une nouvelle itération ne démarre qu'une fois la précédente terminée, si bien que le débit d'arrivée est couplé au temps de réponse. Dans un modèle ouvert, les requêtes arrivent à un débit configuré, que les précédentes soient terminées ou non — ce qui correspond au comportement d'un trafic anonyme : les visiteurs ne s'attendent pas les uns les autres. Les deux modèles ont été mis en contraste dans l'article de Schroeder, Wierman et Harchol-Balter présenté à NSDI 2006, « Open Versus Closed: A Cautionary Tale », qui analyse comment le comportement du système diffère selon chacun.

Pourquoi c'est important

Sous un modèle fermé, un serveur qui ralentit freine son propre générateur de charge : moins de requêtes par seconde arrivent, et les périodes les plus lentes sont les moins échantillonnées. La documentation de k6 nomme ce phénomène coordinated omission (omission coordonnée) ; le README de wrk2 explique qu'un générateur qui attend chaque réponse se coordonne avec le serveur pour éviter de mesurer pendant les périodes de forte latence, et que wrk2 mesure donc la latence à partir du moment où une requête aurait dû être envoyée selon le débit constant configuré. Un test fermé peut ainsi rapporter une latence de queue saine pour un service qui s'effondrerait sous le débit d'arrivée réel.

Comment l'appliquer

• Déduire le modèle de la question posée. « Comment le service se comporte-t-il à N requêtes par seconde ? » nécessite un modèle ouvert (constant-arrival-rate de k6, option --rate de wrk2). « Comment se comportent K workers avec un temps de réflexion (think time) ? » (clients batch, pool fixe d'appelants d'API) relève réellement d'un modèle fermé.
• Dans les tests en modèle ouvert, préallouer suffisamment d'utilisateurs virtuels ; si l'outil ne peut pas soutenir le débit cible, c'est en soi le résultat du test, et l'outil devrait le signaler.
• Rapporter les percentiles à partir d'histogrammes complets, jamais de moyennes, et indiquer le modèle d'arrivée, le débit, le profil de montée en charge et la durée à côté de chaque chiffre.
• Monter en charge par paliers et maintenir chaque palier assez longtemps pour que les files d'attente se stabilisent avant de lire les résultats.
• Exécuter le générateur sur du matériel distinct et vérifier qu'il n'est pas lui-même le goulot d'étranglement (CPU, ports éphémères, descripteurs de fichiers).

Pièges

Les chiffres des deux modèles ne sont pas comparables ; les mélanger dans un même rapport induit en erreur. Les outils en modèle fermé avec un temps de réflexion nul produisent une charge dos à dos qu'aucun client réel ne génère. Les tests en modèle ouvert contre un service surchargé font croître des files d'attente sans limite jusqu'à ce que le client manque de ressources ; c'est le résultat correct, pas un bug de l'outil. Des requêtes qui ciblent toujours la même clé en cache font paraître un service plus rapide qu'il ne l'est.