Question

Je fais un test de contrainte avec JMeter sur une application Web (construit avec Spring, Struts2 REST, utilise PostgreSQL).

Je simule un scénario d'utilisateur typique avec mon application:

4 GET, 3 INSERT, 20 UPDATE appels.

Spécifications du serveur:

4core Intel Xeon X5365 3GHz

8 Go de RAM

disque SATA unique de 320 Go

Système d'exploitation: Ubuntu 8.10 32 bits

DB: Postgresql 8.4

Tomcat 6.0.18

Java 1.6.0_14

Les résultats montrent que le serveur traiterait environ 130 transactions simultanées. Ce nombre est-il possible? Y at-il des résultats en ligne à comparer avec les miens?

Était-ce utile?

La solution

Le goulot d'étranglement sera dans votre base de données, il est donc très difficile de comparer sans connaître les performances de votre base de données.

Nous avons une machine similaire (sauf avec 16 Go de RAM, exécutant Tomcat 5.5). En charge de pointe, il peut facilement desservir 256 connexions simultanées. Nous discutons de changer le maxThreads à 512.

Quelques conseils de réglage,

  1. Si vous exécutez Apache en tant que serveur frontal, utilisez mod_jk . Ses performances sont bien meilleures que mod_proxy .
  2. Si vous utilisez HTTP directement ou utilisez mod_proxy, utilisez le connecteur NIO de Tomcat 6.
  3. Assurez-vous que votre pool de threads (maxThreads) est suffisamment grand et que le nombre par défaut n'est que de 200.
  4. Rendre Tomcat sans état. Surtout, n'utilisez pas HttpSession. Cet état peut provoquer une fuite de mémoire dans l'application et dégrader les performances progressivement. Poussez tout votre état à la base de données ou au client (cookies).
  5. Utilisez le pool de bases de données (DBCP). Nous avons MySQL, le pilote JDBC est très bavard.
  6. Si vous exécutez une instance de JMeter, celle-ci risque de devenir le goulot d'étranglement. Exécutez plusieurs esclaves de différents réseaux pour simuler une charge de production réelle.
Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top