Comments on: Java Scalability 101: Volume 1, Web Servers http://blog.heluna.com/2007/09/21/java-scalability-101-volume-1-web-servers/ Antispam, the Internet, and General Commentary. Thu, 07 Aug 2008 18:29:28 +0000 http://wordpress.org/?v=2.2 By: Carlos http://blog.heluna.com/2007/09/21/java-scalability-101-volume-1-web-servers/#comment-228 Carlos Tue, 20 Nov 2007 13:55:02 +0000 http://blog.heluna.com/2007/09/21/java-scalability-101-volume-1-web-servers/#comment-228 Hi Mark, With the propose configuration for 1000 clients, how can we estimate system resources (CPU and MEM) based on the number of simultaneous users Hi Mark,
With the propose configuration for 1000 clients, how can we estimate system resources (CPU and MEM) based on the number of simultaneous users

]]> By: napyfab:blog» Blog Archive » links for 2007-09-25 http://blog.heluna.com/2007/09/21/java-scalability-101-volume-1-web-servers/#comment-13 napyfab:blog» Blog Archive » links for 2007-09-25 Tue, 25 Sep 2007 23:41:06 +0000 http://blog.heluna.com/2007/09/21/java-scalability-101-volume-1-web-servers/#comment-13 [...] Heluna Weblog » Java Scalability 101: Volume 1, Web Servers (tags: performance apache scalability tomcat j2ee java webservice http) [...] […] Heluna Weblog » Java Scalability 101: Volume 1, Web Servers (tags: performance apache scalability tomcat j2ee java webservice http) […]

]]> By: Michael P http://blog.heluna.com/2007/09/21/java-scalability-101-volume-1-web-servers/#comment-11 Michael P Mon, 24 Sep 2007 22:56:51 +0000 http://blog.heluna.com/2007/09/21/java-scalability-101-volume-1-web-servers/#comment-11 Hi Mark! Thanks for your answer! My use case is a little bit special in that Tomcat is not running a "normal" web application but instead is used as the backend for a desktop application which performs requests over XML-RPC. Each of these requests is seperate (except the login-sequence) and is performed approx. every 2 minutes by each client. So I think maxKeepAliveRequests=”1″ is justified in this special case. (for normal web applications, of course you are right!). Using NIO, sendfile and Comet-Servlets for large requests/responses I think there is no need for a native web server (well, maybe except for load balancing.) Looking forward to your next article! Michael Hi Mark!

Thanks for your answer!
My use case is a little bit special in that Tomcat is not running a “normal” web application but instead is used as the backend for a desktop application which performs requests over XML-RPC. Each of these requests is seperate (except the login-sequence) and is performed approx. every 2 minutes by each client. So I think maxKeepAliveRequests=”1″ is justified in this special case. (for normal web applications, of course you are right!).
Using NIO, sendfile and Comet-Servlets for large requests/responses I think there is no need for a native web server (well, maybe except for load balancing.)

Looking forward to your next article!
Michael

]]> By: Mark http://blog.heluna.com/2007/09/21/java-scalability-101-volume-1-web-servers/#comment-10 Mark Mon, 24 Sep 2007 21:59:57 +0000 http://blog.heluna.com/2007/09/21/java-scalability-101-volume-1-web-servers/#comment-10 Hi James, We have not tried the NIO solutions as of yet; while NIO certainly looks promising from a throughput standpoint, we still enjoy the versatility and configuration that Apache allows. Many additional benefits that Apache has had years to refine are just now starting to be implemented in Tomcat/Resin/etc. Michael-- first of all, using MaxKeepAliveRequests set to 1 will be an incredible strain upon your app server as it closes and reopens TCP/IP connections. MaxKeepAliveRequests should always be set based upon the content of your average page; if your page has 10 or 15 elements per page, that should be the minimum number of MaxKeepAliveRequests; you want users to have an incredibly fast initial load (even with pipelining). The documentation around the Tomcat mod_jk connector applies only for requests that get sent through to the application server. Additionally, the documentation doesn't take into account the maximum amount of concurrent clients available using a webserver vs. strictly the application server. The slight performance hit of sending one page through the connector is more than made up for by the speed of the web server combined with its versatility. Thanks for the comments! -Mark Hi James,

We have not tried the NIO solutions as of yet; while NIO certainly looks promising from a throughput standpoint, we still enjoy the versatility and configuration that Apache allows. Many additional benefits that Apache has had years to refine are just now starting to be implemented in Tomcat/Resin/etc.

Michael– first of all, using MaxKeepAliveRequests set to 1 will be an incredible strain upon your app server as it closes and reopens TCP/IP connections. MaxKeepAliveRequests should always be set based upon the content of your average page; if your page has 10 or 15 elements per page, that should be the minimum number of MaxKeepAliveRequests; you want users to have an incredibly fast initial load (even with pipelining).

The documentation around the Tomcat mod_jk connector applies only for requests that get sent through to the application server. Additionally, the documentation doesn’t take into account the maximum amount of concurrent clients available using a webserver vs. strictly the application server. The slight performance hit of sending one page through the connector is more than made up for by the speed of the web server combined with its versatility.

Thanks for the comments! -Mark

]]> By: Michael P http://blog.heluna.com/2007/09/21/java-scalability-101-volume-1-web-servers/#comment-9 Michael P Mon, 24 Sep 2007 21:23:25 +0000 http://blog.heluna.com/2007/09/21/java-scalability-101-volume-1-web-servers/#comment-9 Hi! From the Tomcat docs: (http://tomcat.apache.org/tomcat-5.5-doc/connectors.html) "The HTTP connector is setup by default with Tomcat, and is ready to use. This connector features the lowest latency and best overall performance. [...] When using a single server, the performance when using a native webserver in front of the Tomcat instance is most of the time significantly worse than a standalone Tomcat with its default HTTP connector, even if a large part of the web application is made of static files." Doesn't that mean it is prefered to NOT use a "real" web server in front of Tomcat (with, say, mod_jk)? How many Tomcat instances are needed for a native web server to start being more performant if I configure my Tomcat Http-Connectors according to the points you stated (means maxKeepAliveRequests="1" and so on)? Thanks! Hi!
From the Tomcat docs: (http://tomcat.apache.org/tomcat-5.5-doc/connectors.html)
“The HTTP connector is setup by default with Tomcat, and is ready to use. This connector features the lowest latency and best overall performance.
[…]
When using a single server, the performance when using a native webserver in front of the Tomcat instance is most of the time significantly worse than a standalone Tomcat with its default HTTP connector, even if a large part of the web application is made of static files.”

Doesn’t that mean it is prefered to NOT use a “real” web server in front of Tomcat (with, say, mod_jk)? How many Tomcat instances are needed for a native web server to start being more performant if I configure my Tomcat Http-Connectors according to the points you stated (means maxKeepAliveRequests=”1″ and so on)?

Thanks!

]]> By: James Law http://blog.heluna.com/2007/09/21/java-scalability-101-volume-1-web-servers/#comment-8 James Law Mon, 24 Sep 2007 20:42:15 +0000 http://blog.heluna.com/2007/09/21/java-scalability-101-volume-1-web-servers/#comment-8 I am curious if you have tried any of the NIO enabled solutions out there. Seems like there is a trend away from webservers for application hosting on java: http://www.javalobby.org/java/forums/m92139905.html I am curious if you have tried any of the NIO enabled solutions out there. Seems like there is a trend away from webservers for application hosting on java:

http://www.javalobby.org/java/forums/m92139905.html

]]>