Wie ermittelt man in Tomcat die beste Anzahl von maxSpare, minSpire und maxThreads, acceptCount usw.? Sind die bestehenden Best Practices?Wie ermittelt man die beste Anzahl von Threads in Tomcat?
Ich verstehe, dass dies auf Hardware (z. B. pro Kern) basieren muss und nur eine Grundlage für weitere Leistungstests und Optimierung auf spezifischer Hardware sein kann.
Das Problem "Wie viele Threads" ist ein ziemlich großes und kompliziertes Problem und kann nicht mit einer einfachen Faustregel beantwortet werden.
In Anbetracht wie viele Kerne Sie haben, ist nützlich für Multithread-Anwendungen, die dazu neigen, eine Menge CPU zu verbrauchen, wie Zahlenverarbeitung und dergleichen. Dies ist selten der Fall bei einer Web-App, die normalerweise nicht von der CPU, sondern von anderen Faktoren gehackt wird.
Eine häufige Einschränkung ist die Verzögerung zwischen Ihnen und anderen externen Systemen, insbesondere Ihrer DB. Jedes Mal, wenn eine Anfrage eintrifft, wird sie wahrscheinlich die Datenbank mehrmals abfragen, was bedeutet, einige Bytes über eine JDBC-Verbindung zu streamen und dann auf diese Bytes in der Datenbank zu warten (selbst wenn es auf localhost ist, gibt es immer noch eine kleine Verzögerung) Warten Sie dann, bis die Datenbank unsere Anforderung berücksichtigt hat, und warten Sie dann, bis die Datenbank sie verarbeitet. Die Datenbank selbst wartet darauf, dass die Festplatte nach einer bestimmten Region sucht Der Thread ist inaktiv, sodass ein anderer Thread problemlos diese CPU-Ressourcen verwenden könnte, um etwas Nützliches zu tun. Es ist durchaus üblich, 40% bis 80% der Zeit zu sehen, die für das Warten auf die DB-Antwort benötigt wird.
Das gleiche passiert auch auf der anderen Seite der Verbindung. Während ein Thread von Ihnen seine Ausgabe an den Browser schreibt, kann die Geschwindigkeit der CLIENT-Verbindung dazu führen, dass Ihr Thread im Leerlauf bleibt und darauf gewartet wird, dass der Browser bestätigt, dass ein bestimmtes Paket empfangen wurde. (Das war vor einigen Jahren ein ziemliches Problem. Kürzere Kernel und JVMs verwenden größere Puffer, um zu verhindern, dass Ihre Threads im Leerlauf laufen. Allerdings kann ein Reverse Proxy vor Ihrem Webanwendungsserver, sogar einfach ein httpd, wirklich nützlich sein, um Leute zu vermeiden mit einer schlechten Internetverbindung, um als DDOS-Angriffe zu fungieren :))
Angesichts dieser Faktoren sollte die Anzahl der Threads in der Regel viel mehr als die Kerne, die Sie haben. Selbst auf einem einfachen Dual-oder Quad-Core-Server sollten Sie mindestens einige Dutzend Threads konfigurieren.
Also, was begrenzt die Anzahl der Threads, die Sie konfigurieren können?
Zunächst einmal verbraucht jeder Thread (der verwendet wird) eine Menge Ressourcen. Jeder Thread hat einen Stack, der RAM verbraucht. Darüber hinaus wird jeder Thread tatsächlich Sachen auf dem Heap zuweisen, um seine Arbeit zu tun, was wiederum RAM verbraucht, und der Vorgang des Umschaltens zwischen Threads (Kontextwechsel) ist ziemlich schwer für den JVM/OS-Kernel.
Dies macht es schwierig, einen Server mit Tausenden von Threads "reibungslos" zu betreiben.
dieses Bild gegeben, gibt es eine Reihe von Techniken (meist: versuchen, scheitern, Melodie, versuchen Sie es erneut) mehr oder weniger, um zu bestimmen, wie viele Threads Sie App benötigen:
1) Versuchen Sie, wo Ihr zu verstehen Threads verbringen Zeit. Es gibt eine Reihe guter Tools, aber selbst jvisualvm profiler kann ein großartiges Tool sein oder ein Tracing-Aspekt, der zusammenfassende Timing-Statistiken liefert. Je mehr Zeit Sie damit verbringen, auf etwas Externes zu warten, desto mehr Threads können Sie generieren, um die CPU in Leerlaufzeiten zu nutzen.
2) Bestimmen Sie Ihre RAM-Auslastung.Angesichts der Tatsache, dass die JVM eine bestimmte Menge an Speicher (vor allem den Permgenraum, in der Regel bis zu hundert Megabyte, wird wieder jvisualvm sagen) unabhängig davon, wie viele Threads Sie verwenden, versuchen Sie mit einem Thread und dann mit zehn und dann mit einhundert, während die App mit jmeter oder was auch immer betont, und sehen, wie Heap-Nutzung wächst. Das kann eine harte Grenze darstellen.
3) Versuchen Sie, ein Ziel zu bestimmen. Jede Benutzeranforderung benötigt einen zu behandelnden Thread. Wenn Ihre durchschnittliche Reaktionszeit 200ms pro "get" beträgt (es wäre besser, das Laden von Bildern, CSS und anderen statischen Ressourcen nicht in Betracht zu ziehen), kann jeder Thread 4/5 Seiten pro Sekunde bedienen. Wenn erwartet wird, dass jeder Benutzer alle drei bis vier Sekunden "klickt" (hängt davon ab, ob es sich um ein Browserspiel oder eine Website mit vielen langen Texten handelt), wird ein Thread "20 gleichzeitige Benutzer bedienen", was auch immer es bedeutet. Wenn in der Hauptverkehrszeit 500 einzelne Nutzer innerhalb einer Minute auf Ihre Website zugreifen, benötigen Sie genug Threads, um damit umzugehen.
4) Crashtest die obere Grenze. Verwenden Sie jmeter, konfigurieren Sie einen Server mit vielen Threads auf einer Ersatzvirtualmaschine und sehen Sie, wie sich die Reaktionszeit verschlechtert, wenn Sie ein bestimmtes Limit überschreiten. Mehr als Hardware ist hier die Thread-Implementierung des zugrundeliegenden Betriebssystems wichtig, aber egal, was es bringt, wenn die CPU mehr Zeit darauf verwendet, herauszufinden, welcher Thread ausgeführt wird, als tatsächlich ausgeführt wird, und diese Zahl ist nicht so unglaublich hoch.
5) Überlegen Sie, wie sich Threads auf andere Komponenten auswirken. Jeder Thread wird wahrscheinlich eine (oder mehr als eine) Verbindung zur Datenbank verwenden, ist die Datenbank in der Lage, 50/100/500 gleichzeitige Verbindungen zu bewältigen? Selbst wenn Sie einen Cluster von Nosql-Servern mit mehreren Shards verwenden, bietet die Serverfarm genügend Bandbreite zwischen diesen Computern? Was sonst wird auf demselben Computer mit dem Web-App-Server ausgeführt? Ansteh httpd? Tintenfisch? die Datenbank selbst? ein lokaler Caching-Proxy für die Datenbank wie mongos oder memcached?
Ich habe gesehen, Systeme in der Produktion mit nur 4 Threads + 4 Ersatz Threads gesehen, weil die Arbeit von diesem Server getan wurde, um nur die Größe der Bilder zu ändern, so war es fast 100% CPU intensiv und andere auf mehr oder weniger konfiguriert gleiche Hardware mit ein paar hundert Threads, da die Webapp viele SOAP-Aufrufe an externe Systeme machte und die meiste Zeit damit verbrachte, auf Antworten zu warten.
Oce haben Sie die ca. bestimmt. Minimale und maximale Threads optimal für Sie webapp, dann konfiguriere ich es normalerweise so:
1) Basierend auf den Einschränkungen für RAM, andere externe Ressourcen und Experimente zum Kontextwechsel gibt es ein absolutes Maximum, das nicht erreicht werden darf. Verwenden Sie daher maxThreads, um sie auf ungefähr die Hälfte oder 3/4 dieser Anzahl zu beschränken.
2) Wenn die Anwendung einigermaßen schnell ist (z. B. REST-Webdienste, die normalerweise eine Antwort senden, sind einige Millisekunden), können Sie einen großen acceptCount konfigurieren, bis zur gleichen Anzahl von maxThreads. Wenn Sie einen Load Balancer vor Ihrem Webanwendungsserver haben, legen Sie einen kleinen acceptCount fest. Es ist besser für den Load Balancer, nicht akzeptierte Anforderungen zu sehen und zu einem anderen Server zu wechseln, als Benutzer auf einen bereits ausgelasteten zu legen.
3) Da das Starten eines Threads (immer noch) als eine schwere Operation angesehen wird, verwenden Sie minSpareThreads, um einige Threads bereit zu haben, wenn die Spitzenzeiten ankommen. Dies hängt wiederum von der Art der Belastung ab, die Sie erwarten. Es ist sogar sinnvoll, minSpareThreads, maxSpareThreads und maxThreads so einzurichten, dass eine genaue Anzahl von Threads immer bereit ist, nie wiederhergestellt wird und die Performance vorhersehbar ist. Wenn Sie Tomcat auf einem dedizierten Computer ausführen, können Sie minSpareThreads und maxSpareThreads ohne die Gefahr, andere Prozesse zu manipulieren, erhöhen. Tun Sie dies anders, denn Threads sind Ressourcen, die mit den anderen auf den meisten Betriebssystemen ausgeführten Prozessen geteilt werden.