Wie effizient ist Apache Tomcat für Long Polling?

Question

Ich ging durch diese Question über lange Polling wo andere als die Bereitstellung der Lösung ein interessanter Punkt wurde in Bezug auf die Ineffizienz von Apache gemacht, um eine große Anzahl von Anfragen zu behandeln. Ich hatte die gleiche Sorge um Apache Tomcat?

Ist Apache Tomcat effizient genug, um lange Abfragen zu verarbeiten? Ich weiß eine Sache, dass Apache Tomcat eine ziemlich große Anzahl von gleichzeitigen Threads unterstützt, aber ist es auf ein solches Limit skaliert, dass wir es für Long Polling in der oben beschriebenen Weise verwenden können?

Answer 1

Sie sind auf der question auf diesen Kommentar Bezug genommen wird,

dies auf einem normalen Web-Server wie Apache ausgeführt werden alle „Worker-Threads“ schnell binden und
lassen Sie es nicht in der Lage auf andere zu reagieren fordert

Neuere Versionen von apache tomcat comet unterstützen, die IO nicht blockieren können tomcat auf eine große Anzahl von Anfragen skalieren zu können. Aus diesem article,

Dank der nicht-blockierende I/O-Fähigkeit in Java 4 Neuen I/O-APIs für das Java-Plattform (NIO) Paket eingeführt, eine persistente HTTP Verbindung erfordert nicht, dass ein Faden wird ständig daran befestigt. Threads können Verbindungen nur zugewiesen werden, wenn Anforderungen verarbeitet werden. Wenn eine Verbindung zwischen Anforderungen inaktiv ist, kann der Thread wiederverwendet werden, und die Verbindung wird in einem zentralisierten NIO platziert. Wählen Sie aus, um neue Anforderungen zu erkennen, ohne einen separaten Thread zu verwenden. Dieses Modell , genannt Thread pro Anfrage, ermöglicht möglicherweise Webservern eine wachsende Anzahl von Benutzerverbindungen mit einer festen Anzahl von Threads behandeln. Mit derselben Hardwarekonfiguration skalieren Webserver, die unter ausgeführt werden, diesen Modus viel besser als im Thread-pro-Verbindung-Modus. Heutzutage verwenden gängige Webserver - einschließlich Tomcat, Jetty, GlassFish (Grizzly), WebLogic und WebSphere - alle Threads pro Anforderung über Java NIO.

Answer 2

Sehen Sie diese report comparing Tomcat and Jetty for Comet:

• Tomcat etwas bessere Leistung zu haben, neigt, wenn es wenige sehr beschäftigt Verbindungen. Es hat einen leichten Vorteil in der Anforderungslatenz, was am offensichtlichsten ist, wenn viele Anfragen/Antworten über einige Verbindungen ohne signifikante Leerlaufzeit gesendet werden.

• Anlegestelle ist tendenziell besser skalierbar, wenn es viele Verbindungen mit beträchtlicher Leerlaufzeit gibt, wie dies bei den meisten Websites der Fall ist. Der kleine Speicherbedarf von Jetty und die erweiterte NIO-Nutzung ermöglichen eine größere Anzahl von Benutzern pro verfügbarem Speicher. Der kleinere Footprint bedeutet auch, dass weniger Speicher und CPU-Cache vom Servlet-Container belegt werden und mehr Cache verfügbar ist, um die Ausführung von nicht-trivialen Anwendungen zu beschleunigen.

• Landungssteg hat auch eine bessere Leistung in Bezug auf dem statischen Inhalt, wie Landungssteg der Lage ist, vorab im Speicher abgebildeten Dateipuffer mit NIO sammeln Schreibvorgänge kombiniert zu verwenden, um das Betriebssystem zu instruieren, ohne Eingabe von Benutzerspeicherdateiinhalt bei maximaler DMA Geschwindigkeit zu senden Raum oder die JVM.

Wenn Ihre Anwendung Perioden haben wird, wo es Verbindungen im Leerlauf oder Kunden sind, die einfach auf eine Antwort vom Server warten, dann würde Jetty eine bessere Wahl über Tomcat sein. Ein Beispiel wäre ein Börsenticker, bei dem die Kunden wenige Anfragen senden und nur auf Updates warten.

Darüber hinaus waren die Jetty-Team die Pioniere für Comet, und die meisten Informationen und Beispiele, die ich gefunden habe, neigen dazu, nur auf Jetty konzentrieren. Wir verwenden Jetty seit 2008 auf einem Comet-Server und waren mit den Ergebnissen zufrieden.

Die andere Sache zu berücksichtigen ist, dass Jetty als eigenständiger Webserver konzipiert ist. Das bedeutet, dass Sie keinen Apache-Server vor Jetty benötigen. Wir führen Jetty Standalone auf Port 80 aus, um alle Anfragen unserer Anwendung zu bedienen, einschließlich der Comet-Anfragen.

Wenn Sie Tomcat für Comet-Anfragen verwenden, müssen Sie höchstwahrscheinlich den direkten Zugriff auf Port 8080 erlauben und Apache umgehen, da Apache möglicherweise Ihr langes Polling negiert.