Comment améliorer les temps de réponse de la jetée?

Question

J'essaye d'accélérer la jetée de test (pour la comparer avec apache) pour servir le contenu dynamique.

Je suis en train de tester cela en utilisant trois threads client demandant à nouveau dès qu'une réponse revient. Ceux-ci s'exécutent sur une boîte locale (OS X 10.5.8 mac book pro). Apache est quasiment sorti de la boîte (distribution XAMPP) et j'ai testé Jetty 7.0.2 et 7.1.6

Apache donne mes temps spikey: temps de réponse jusqu'à 2000ms, mais une moyenne de 50ms, et si vous supprimez les pointes (environ 2%), la moyenne est de 10 ms par appel. (C'était à une page de monde de bonjour de PHP)

La jetée ne me donne pas des pointes, mais des temps de réponse d'environ 200ms.

Cela appelait à l'hôte local: 8080/hello/qui est distribué avec jetée, et le démarrage de la jetée avec java -jar start.jar.

Cela semble lent pour moi, et je me demande si c'est juste moi de faire quelque chose de mal.

Toutes les suggestions sur la façon d'obtenir de meilleurs nombres sur la jetée seraient appréciées.

Merci

Answer 1

Eh bien, depuis que je suis en cours d'exécution avec succès un site avec un peu de trafic sur la jetée, j'été assez surpris par votre observation.

Alors j'ai juste essayé votre test. Avec le même résultat. J'ai donc décompilé le Hello Servlet fourni avec Jetty. Et je devais rire - il comprend vraiment la ligne suivante:

Thread.sleep(200L); 

Vous pouvez see pour vous-même.

Ma propre expérience avec des performances Jetty: J'ai couru des tests de charge multithread sur mon application dans le monde réel où j'ai eu un débit d'environ 1000 requêtes par seconde sur mon poste de travail dev ...

Answer 2

Speedup ou régler les performances de toute application ou serveur est vraiment difficile de se faire dans mon expérience. Vous aurez besoin de comparer plusieurs fois avec différents modèles de travail pour définir votre charge de pointe. Une fois que vous avez défini la charge de pointe pour le mélange configuration/environnement, vous devez ajuster et référencer, vous devrez peut-être exécuter 5 itérations et plus de votre test. Vérifiez la configuration d'Apache/Jetty en termes de nombre de threads de travail pour traiter la requête et faites en sorte qu'ils correspondent si possible. Voici quelques recommandations:

1. Tenez compte des différences des deux environnements (GC dans la jetée, pensez tuning min et le seuil de mémoire max à la même taille et procéder plus tard pour exécuter votre test)
2. La charge devrait venir d'une autre boîte. Si vous n'avez pas de deuxième box/PC/serveur, prenez votre CPU/core en compte et configurez votre test sur un CPU spécifique, faites de même pour jetty/apache. Ceci est donné que vous ne pouvez pas obtenir une autre machine pour être l'agent de stress. Exécuter plusieurs modèles de charge de travail

Déplacement à la modélisation du test ne les 2 étapes suivantes:

1. un fil pour chaque configuration pendant 30 minutes.
2. Commencer avec 1 thread et aller jusqu'à 5 avec un intervalle de 10 minutes pour augmenter le nombre,
3. Base sur les métriques L'étape 2 définit un nombre de threads pour le test. et exécutez ce nombre de threads simultanément pendant 1 heure.

corrélat les mesures (temps de réponse) de votre application de test sur le serveur hébergeant les ressources d'application (utilisation sar, en haut et d'autres commandes unix pour suivre cpu et mémoire), un autre processus pourrait être vous un impact sur l'application. (la mémoire est importante pour apache jetty sera contrainte à la configuration de la mémoire JVM, donc il ne devrait pas changer l'utilisation de la mémoire une fois que le serveur est opérationnel)

Answer 3

Soyez conscient du compilateur Hotspot.

Les méthodes doivent être appelées plusieurs fois (1000 fois?), Avant d'être compilées en code natif.

Answer 4

Vous devriez certainement vérifier avec profiler. Voici les instructions pour la configuration de profilage à distance avec la jetée:

http://sujitpal.sys-con.com/node/508048/mobile

Answer 5

Notez également que votre vitesse test est vraiment juste un test de latence, ce qui est bien tant que vous savez ce que vous mesurez. Mais Jetty échange sur le temps de latence pour le débit, si bien qu'il y a souvent des serveurs avec une latence plus faible, mais aussi un débit plus faible.

Le trafic réaliste pour un serveur Web n'est pas 3 connexions très occupées - 1 navigateur ouvrira 6 connexions, ce qui représente la moitié d'un utilisateur. Un trafic plus réaliste consiste en plusieurs centaines ou milliers de connexions, dont chacune est essentiellement inactive.

avoir une lecture de mes blogs sur ce sujet: https://webtide.com/truth-in-benchmarking/ et https://webtide.com/lies-damned-lies-and-benchmarks-2/