Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Real-Time Tracking and Tuning for Busy Tomcat Servers : Page 3

Learn a technique for configuring your Tomcat servers to handle heavy traffic while determining how appropriate your current configuration is for changing load demands.


advertisement

The Value of Tomcat Valves

Valve is a core architectural component of the Tomcat server. Its main purpose is to provide a standard, flexible, and extensible way for tying the server or user-defined events to requests coming into a Tomcat server on a per-request basis. In that sense, Valves are similar to filters in Java Web applications. You can chain them together to perform some action upon each request. This per-request nature is the key ingredient for the custom performance monitoring mechanism.

In a Web environment, it is far more meaningful to track server parameters on a per-request basis than on some pre-determined time interval. Due to the erratic, spike-prone nature of the Web, the server may be idle one moment and then flooded with requests the next. For that reason, Valve provides far better and more pertinent information than regular interval tracking, in terms of how Tomcat's resources are utilized on a request-by-request basis.

Using Tomcat MBeans for Resource Monitoring

Tomcat server ships with a rich set of MBean objects (see JMX standard) that provide unprecedented access to the server's control and management functions, as well as to server-managed resources and deployed applications.

While JMX-based server control and management functions are powerful and comprehensive, using JMX for managing and monitoring production servers can be controversial. Typical JMX-based management requires client software and remote connectivity components. These components, such as JConsole and RMI-based JMX servers, can add overhead to already busy production machines. In addition, monitoring may require relaxation of stringent security rules. Because of these reasons, the solution that this article proposes does not require complete JMX support. (Working with Tomcat's JMX features is beyond the scope of this article. See the previously published DevX article on best practices for monitoring Tomcat using MBeans.)



Instead of accessing MBeans through the external console, monitoring Valve accesses the local MBeans directly on the server without incurring any overhead or interfering with the security rules of the system. This solution is concerned only with the MBeanServer object and basic attribute retrieval of resource pool MBeans. For the JDBC Pool, it uses the MBean identified in Table 1.

DataSource MBean
Property Value Description
name "jdbc/testDB" Must match the name of the JDBC datasource in context.xml file
class "javax.sql.DataSource" Constant value
host "localhost" Name of the host server as defined in server.xml file
path "/Test" Path of the Web application to which the JDBC source is attached
type "DataSource" Constant value
Table 1. MBean Properties for JDBC Pool in Resource Monitoring Solution

For the Connector Threads Pool, it uses the MBean identified in Table 2.

Connector MBean
Property Value Description
name "jk-8009" This is the connector type that you want to track. Two common connectors are jk-8009 for Tomcat AJP connector and http-8080 for HTTP connector. Use jk-8009 if Tomcat is attached to the Web server via mod_jk, otherwise use http-8080.
type "ThreadPool" Constant value
Table 2. MBean Properties for Connector Threads Pool in Resource Monitoring Solution

For the JDBC DataSource MBean, the solution reads out the following MBean attributes:

  • numActive – number of currently active JDBC connections for the pool
  • maxActive – maximum number of available connections
  • For the connector thread pool MBean, the solution reads out the following:

  • currentThreadsBusy – number of threads currently busy processing incoming requests
  • currentThreadCount – total number of loaded threads ready to process requests (These threads are available to get immediately busy with spikes of traffic.)


  • Comment and Contribute

     

     

     

     

     


    (Maximum characters: 1200). You have 1200 characters left.

     

     

    Sitemap