Alternatives to ApacheBench for profiling my code speed

Question

J'ai fait quelques expériences en utilisant Apache Bench pour profiler les temps de réponse de mon code, et cela ne génère pas tout à fait le type de données dont j'ai besoin. J'espère que les bonnes personnes ici ont des idées.

Plus précisément, j'ai besoin d'un outil qui

• Effectue des requêtes HTTP via le réseau (il n'a pas besoin de faire quelque chose de très élaboré)
• Enregistre les temps de réponse le plus précisément possible (au moins à quelques millisecondes près)
• Écrit les données de temps de réponse dans un fichier sans autre traitement (ou les fournit à mon code, s'il s'agit d'une bibliothèque)

Je connais ab -e, qui imprime les données dans un fichier. Le problème est que cela n'imprime que les données quantiles, ce qui est utile, mais pas ce dont j'ai besoin. L'option ab -g fonctionnerait, sauf qu'elle n'imprime pas les données inférieures à la seconde, ce qui signifie que je n'ai pas la résolution dont j'ai besoin.

J'ai écrit quelques lignes de code en Python pour le faire, mais httplib est horriblement inefficace et donc les résultats étaient inutiles. En général, j'ai besoin d'une meilleure précision que ce que Python pur est susceptible de fournir. Si quelqu'un a des suggestions pour une bibliothèque utilisable depuis Python, je suis tout ouïe.

J'ai besoin de quelque chose qui soit performant, reproductible et fiable.

Je sais que la moitié de mes réponses vont être du genre "la latence internet rend ce type de mesures détaillées sans intérêt." Dans mon cas d'utilisation particulier, ce n'est pas vrai. J'ai besoin de détails de synchronisation haute résolution. Quelque chose qui utilise vraiment mon matériel HPET serait génial.

Je mets une prime ici en raison du faible nombre de réponses et de vues.

Answer 1

J'ai utilisé un script pour contrôler 10 boîtes sur le même commutateur afin de générer une charge en "rejouant" les requêtes vers 1 serveur. Mon application web enregistrait le temps de réponse (serveur uniquement) avec la précision nécessaire, mais je ne me préoccupais pas du temps de réponse vers le client. Je ne suis pas sûr que vous souhaitiez inclure le trajet aller-retour vers le client dans vos calculs, mais si vous le faisiez, il ne devrait pas être difficile à coder. Ensuite, j'ai traité mes journaux avec un script qui extrayait les temps par URL et créait des graphiques de dispersion et des graphiques de tendance en fonction de la charge.

Cela a satisfait mes besoins qui étaient :

• Distribution réelle des appels vers différentes URL dans le monde réel.
• Évolution des performances en fonction de la charge.
• Ne pas influencer l'application web en exécutant d'autres opérations intensives sur la même boîte.

J'ai créé un contrôleur sous forme de script shell qui, pour chaque serveur, lançait un processus en arrière-plan pour parcourir toutes les URL d'un fichier en appelant curl sur chacune d'entre elles. J'ai écrit le processeur de journaux en Perl puisque je faisais plus de Perl à ce moment-là.