mod_cluster to the rescue?
We want to conclude this section with a small note about mod_cluster. Mod_cluster is a new httpd-based load balancer. Like mod_jk, mod_cluster uses a communication channel to forward requests from httpd to one of a set of application server nodes. Unlike mod_jk, mod_cluster leverages an additional connection between the application server nodes and httpd.
The application server nodes use this connection to transmit server-side load balance factors and lifecycle events back to httpd using a custom set of HTTP methods, known as the Mod-Cluster Management Protocol (MCMP). This additional feedback channel allows mod_cluster to offer a level of intelligence and granularity not found in other load balancing solutions.
There are not many statistics about mod_cluster on the web so all in all we were curious to know how this library performed under heavy load. So here’s a benchmark performed using the same pattern employed in the previous benchmark:
The performance of mod_cluster is pretty much the same as Apache’s mod_proxy and this should be no surprise at all as much of the Apache-JBoss Web server communication is based on mod_proxy.
However, mod_cluster provides innovative load balancing features like dynamic registration of AS instances and context mountings, pluggable policies for calculating the load balance factors, and many others (You can find advanced mod_cluster design documentation at this URL: http://community.jboss.org/wiki/ ModClusterDesign).
At the end of this journey through Apache-JBoss connectivity, we have arranged the most important points in the following table. You can use it as a guide for deciding which module is best suited to the needs of your project:
|
Module |
Advantage |
Disadvantage |
|
mod jk |
Advanced load balancer. Advanced failure node detection. |
Out-of-the box not tuned configuration. |
|
Complex module configuration (need a separate module to build and maintain). |
||
|
mod proxy |
Out-of-the box good performance. Simple module configuration (No need for a separate module.) |
Basic load balancer Does not support domain model clustering |
|
mod_ cluster |
Good performance. Fine-grained control for your communication channel and dynamic configuration of httpd workers. |
Newer project, with smaller community of users. |
Last tips before rolling JBoss Web server in production
Once that you are ready to roll in production your web application on JBoss Web server/Tomcat you should consider making some changes from the default configuration, which is just fine when you are using the Web server for developing. These properties can be set as the init parameter of the core JspServlet class which handles JSP to Servlet translation:
The following table describes the meaning of these parameters:
|
Parameter |
Value |
|
development |
Used to disable on access checks for JSP pages compilation. Set this to false in production. |
|
checkInterval |
Sets the time in seconds between checks to see if a JSP page (and its dependent files) needs to be recompiled. Default 0 seconds |
|
trimSpaces |
Can be used to remove useless bytes from the response. Set this to true as a minor performance optimization |
|
genStringAsCharArray |
Takes care to generate slightly more efficient char arrays. Set this to true. |
Summary
In this topic, we have learnt how to configure optimally the embedded JBoss Web server, which is behind the scenes of the well-known Tomcat Web server.
• The default JBoss Web server configuration is fit for a Web application with little or medium traffic. In order to carry high loads the Web configuration needs to be appropriately tuned.
° The MaxThreads parameter of server.xml is the most important parameter as it determines the maximum number of concurrent connections allowed. A good rule of thumb is setting it at about 25% more of the currentBusyThreads property of your Web server Thread Pool.
° The minimum number of threads always kept alive are controlled by the MinSpareThreads attribute.
° By setting an appropriate value of maxidleTime, you can reduce the number of threads used by your applications at idle time.
° Setting the correct number of threads to be used greatly influences the performance of your application. Too few threads will require costly threads creation (low MinSpareThreads property) or might cause connection refused (low MaxThreads and acceptCount properties). Too many threads will make your application CPU-bound and might potentially exhaust your memory.
• The Apache Portable Runtime Connector provides advanced IO functionality and native process handling which can greatly enhance the performance of your web applications. Best results have been observed on Unix platforms.
• Hardware capabilities and kernel configuration can actually limit the number of connections released by the Web server. The default kernel configuration is usually targeted at Web applications with small or moderate traffic.
• Fronting a JBoss Web server with Apache or any other Web server can be useful to take advantage of the Web server native modules. It can be required for security policies.
• Before rolling your Web applications in production don’t forget to set up the development property to false of the JspServlet class. Also checklnterval should accordingly be set to 0 seconds. Minor optimizations can be achieved by setting trimSpaces and genStringAsCharArray to true.
