Tomcat läuft bei Stresstest nicht unter Volllast hat aber guten Durchsatz

[hugediggs]

Ich habe hier ein Debian, auf dem ein Tomcat 8.5 inkl. Webapplikation läuft (habe ich "geerbt"). Nun soll ich das Ding mal einem Stresstest unterziehen und gucken, wie so die Antwortzeiten sind.
Bei einem 8 Core System habe ich bei 8 paralleln Requests den besten Durchsatz, also Requests pro Sekunde. Mit mehr Nutzern fällt die Leistung ab. Habe ich auch erwartet. Blöd ist dabei nur, dass die Kiste im Schnitt "nur" zwischen 70% und 80% läuft, also nicht unter Volllast.

Woran könnte das ungefähr liegen? Wenn sich das System langweilt, müsste ich ja auch mehr parallele Requests durchbringen können!?

[whisper]

Tomcat hat Parameter bis der Arzt kommt, da kann man auf Deubel komm raus konfigurieren, bis es kracht.
Der Lasttest wird womit gemacht?
Selber Rechner, oder von außen?
Die Test URLS alle ohne DB Zugriff, oder mit?
(hier läuft ein Confluence)
Bin nicht der Owner des tomcat, sehe nur die wahnsinns lange Parameterliste

[hugediggs]

Das sind die Parameter, mit denen der Tomcat läuft.

Code: Alles auswählen

-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Djdk.tls.ephemeralDHKeySize=2048
-Djava.protocol.handler.pkgs=org.apache.catalina.webresources
-XX:+UseCompressedOops
-XX:-OmitStackTraceInFastThrow
-XX:+ParallelRefProcEnabled
-XX:ObjectAlignmentInBytes=8
-XX:ReservedCodeCacheSize=512M
-Xmx12g
-Xms12g
-XX:MaxMetaspaceSize=1g
-XX:MetaspaceSize=1g
-XX:NewSize=1g
-XX:MaxNewSize=1g
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=6666
-XX:-UseParallelGC
-XX:+UseConcMarkSweepGC
-XX:+CMSClassUnloadingEnabled
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
-XX:+PrintGCTimeStamps
-verbose:gc
-XX:+ExplicitGCInvokesConcurrent
-XX:CMSInitiatingOccupancyFraction=85
-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSFullGCsBeforeCompaction=1
-XX:+UseParNewGC
-XX:ParallelGCThreads=10
-XX:+CMSParallelRemarkEnabled
-XX:SurvivorRatio=10
-XX:TargetSurvivorRatio=85
-XX:+PrintClassHistogramBeforeFullGC
-XX:+PrintClassHistogramAfterFullGC
-Dbackoffice.syncAllAssetsEnabled=true

Für den Lasttest nutze ich curl mit GNU parallel, hatte mir aber aus Verzweiflung schon ein C-Programm geschrieben, was das auch macht. Kein Erfolg. Es handelt sich um eine Seite ohne DB-Zugrif und die Seite wurde sowohl von gleichen Rechner als auch von einem Rechner im gleichen Netz aufgerufen. Auf der gleichen Kiste ist meiner Meinung nach sinnlos, da ich nicht zig Threads aufmachen und erwarten kann, dass der Tomcat mit den übrigen was reisen kann...

[whisper]

Für den Lasttest nutze ich curl mit GNU parallel, hatte mir aber aus Verzweiflung schon ein C-Programm geschrieben, was das auch macht. Kein Erfolg. Es handelt sich um eine Seite ohne DB-Zugrif und die Seite wurde sowohl von gleichen Rechner als auch von einem Rechner im gleichen Netz aufgerufen. Auf der gleichen Kiste ist meiner Meinung nach sinnlos, da ich nicht zig Threads aufmachen und erwarten kann, dass der Tomcat mit den übrigen was reisen kann...

Natürlich ist der Tester auf der gleichen Maschine sinnlos, kenne ja deinen Hintergrund nicht
Ich habe früher einen http tester (Name vergessen) von http://acme.com/ benutzt. Gibt es wohl nicht mehr. Aber es gibt ja noch viel mehr.
Mit curl sollte i.o. sein.
Ein Stresstest sollte definitionsgemäß ja festgestellt werden ab wie viel Zugriffen Fehler auftreten, das passiert also noch nicht bei 8, sondern vielleicht bei 100.
Dass das Betriebssystem scheinbar keine 100% Last hat, empfinde ich als erstmal nicht so schlimm.
Hat der Server Nagios, controld munin, Cactus, o.ä.? Vielleicht erhellt das etwas den Grund.
Es könnte sein, dass tomcat selber so gestrickt ist, den Server nicht bis aufs letzte zu blockieren, würde Sinn machen.
Meine persönlichen Erfahrungen mit tomcat basieren auf mehr als 15 Jahre zurückliegenden Ereignissen, da hat sich ja viel getan.
Was hast du benutzt um die Auslastung zu messen? top, htop, oder etwas anderes.

[hugediggs]

zum auslesen der last nehme ich top und visualvm (verbinde mich direkt via jmx). ein diagnose tool läuft da nicht drauf. laut thread dump treten fehler auf, indem threads blockieren. aber wenn der server noch oben hin noch luft hat, sollte der doch weiterhin reinkommende equests abfrühstücken können und sich die auslastung noch oben verschieben, oder?

[whisper]

Hast du schon mal mit den Parametern -XX:ParallelGCThreads u.a.
gespielt?
Durchaus möglich, das die Garbage Collection das ganze begrenzt.
https://blog.codecentric.de/2012/01/nut ... gs-teil-6/