Débit

Ce sont des vrais nombres d’un vrai run, pas des projections. Lisez les mises en garde avant d’en citer un. Le banc utilisait un SMSC de test, et la découverte la plus utile porte sur cela.

​

La baseline

Le burst corrigé est celui contre lequel comparer les travaux futurs : 752 msg/s livrés, 98,9% de succès, 26,3 s pour 20 000 messages.

​

Le routeur n’a jamais été le goulot

fireflo_router_queue a lu 0 pendant tout le burst de 20 000 messages et a fait un pic à 18 sur tous les autres runs. Les messages étaient routés aussi vite qu’ils arrivaient ; ils s’empilaient ensuite dans la file du worker vendeur, qui a atteint 7 987. Tout ce qui limitait le débit était en aval du code de routage.

​

La seule ligne qui a coupé les pertes de 92%

Le premier burst a perdu 2 528 messages, chacun message.dropped reason=maxAttempts attempts=20 limit=20, avec 151 985 tentatives de submit pour 24 000 messages acceptés. Environ six chacun. La connexion vendeur n’a jamais chuté. Ce n’était pas de la connectivité. Le SMSC de test a cessé de répondre assez vite sous burst, les submits ont expiré, le worker a retenté, et les messages qui utilisaient les 20 tentatives de routage ont été abandonnés. Re-lancer à transceivers = 1, mêmes messages, même fenêtre, mêmes threads routeur : La file a toujours atteint 8 042 et le routeur n’a toujours jamais engorgé, donc la forme du run était identique. Ce qui a changé est qu’une seule session ne provoque pas ce que fait le SMSC de test quand sur-sessionné.

​

Le levier qui semblait évident et n’a rien fait

Une version antérieure de la baseline disait que le remède pour les 1,1% résiduels était d’augmenter outSms.routing.maxAttempts et outSms.routing.retryBackoffMillis, raisonnant qu’un message ne survit qu’environ deux secondes d’un vendeur qui n’accepte pas. Cela a été mesuré et c’est faux. Aucune amélioration, et légèrement plus lent. Plus de retries contre un vendeur qui n’accepte pas est plus de charge sur la chose qui refuse déjà. Ce qui a corrigé était vendor1.tps = 300. Rythmer le gateway à ce que le vendeur pouvait vraiment prendre. Zéro perdus, zéro ESME_RMSGQFUL, et exactement 1,00 submits par message.

​

Ce qu’il faut mesurer sur votre propre déploiement

​

Mises en garde

• Un SMSC de test n’est pas un opérateur. Les deux runs de burst étaient bornés par le simulateur, pas par FireFlo.
• L’écart run-to-run était plus grand que l’effet du paramètre de fenêtre. Augmenter windowSize 100 → 500 et transceivers 1 → 4 a produit 337 et 910 msg/s sur deux runs de configuration identique, contre 500 et 840 pour la baseline. Ce banc ne peut pas résoudre cet effet. Ce qui est une déclaration sur la mesure, pas une preuve que la fenêtre ne compte pas.
• message.trace.mode = all a produit 226 MB de log pour un run de 20 000 messages. Utile pour une enquête, ruineux comme défaut.

​

Connexes