Other Features

Your web application server might use other features not defined in the J2EE specification. We've included below some performance pointers for a few of the more common of these features.

Built-in HTTP Servers

Many web application servers include their own, built-in HTTP servers. By using the built-in HTTP server, the web site avoids the performance overhead of the plug-in processing normally associated with a stand-alone HTTP server. These built-in HTTP servers often run "out of the box" with little setup, which makes them particularly appealing to web site teams hard-pressed for time.

While the built-in HTTP servers have a lot going for them, we do not recommend them for high-volume, production web sites. Many high-volume web sites place the HTTP server inside a DMZ, and run the web application server behind the DMZ. Built-in HTTP servers cannot support this configuration. Also, stand-alone, commercial HTTP servers provide more features and support high volumes and static content requests more efficiently . (See the next chapter for more on HTTP servers and their performance.)

General Object Pool Management

The JDBC data source standard we discussed earlier applies only to database connections. Sometimes you need a custom pool manager in your web application to control sharing of other objects, such as connections to a non-JDBC-compliant data repository or other sharable objects. For example, if your web application launches threads, you need a thread pool. The thread pool reduces overhead from repeatedly creating and destroying threads, and prevents some runaway conditions.

General Object Pool Management Tips

If you find yourself writing a custom pool manager, consider the following best practices.

Use Configurable Limits

Load the parameters for your thread pool from an external source, such as an XML file or resource bundle, during initialization. This allows the administrator to fine-tune the pools in your application during performance testing or deployment without making a code change. Key parameters include the minimum and maximum pool size , timeout values, growth values, and so on. (Some web applications build their own custom administration function to update these values on the fly.)

Never Wait Indefinitely Inside the Pool

The servlet requests a thread from the pool, but none are available. The pool manager decides to grow the pool by another five threads (the pool has not reached its maximum size yet). What happens to the servlet request while the pool grows? Do not allow it to wait indefinitely. Time out the request and/or throw a "soft" exception if the pool cannot obtain new resources in a very short period of time ( milliseconds , not seconds). It is better to return empty-handed than not return at all from a resource request. Avoid stalling the web site by leaving servlet threads in an indefinite wait state. (See the discussion on "frozen web sites" earlier in this chapter.)

Set Pool Maximums

To avoid runaway thread creation, set hard maximums for your thread pool. If your threads interact with a back-end system, they might stall if that system becomes nonresponsive. In this case, your thread pool might fill up with stalled threads waiting for a dead remote system. Creating more threads only makes the situation worse , and may lead to a system crash if you allow thread pool to create hundreds of threads. Instead, return an exception to the servlets requesting threads. Program the servlets to catch this exception and return the appropriate error page, if necessary. This is another example of making outages a normal part of your site's operation.

Set a Maximum Wait for Thread Execution

After retrieving the thread, take care when launching it. Again, you cannot wait indefinitely for a thread to return. Always manage the amount of time your servlet waits for a thread before continuing, particularly if your thread tries to access remote resources. Use a timeout on your threads. Instead of

 myThread.join(); 

use the join with a timeout parameter:

 myThread.join(500); 

(Note: This is just an example of a potential timeout value. Base your timeouts on your actual application needs.)

Again, whenever possible, make the timeout value externally configurable. Also, if you set a timeout, you may abandon threads over time. This is another reason to set an absolute maximum for your thread pool to avoid runaway thread acquisition.

Multiple Instances: Clones

Many larger Java web application server vendors provide an easy way to create and manage multiple application server instances (each running in a separate JVM) on your web site. These multiple JVMs may execute servlet applications, or EJB containers, or both. The IBM WebSphere Application Server, for example, calls these multiple JVMs clones ; other products call them instances. Clones may share the same machine, or install across multiple machines, or both. Figure 2.10 shows multiple clones within a server cluster.

Figure 2.10. Clones in both vertical and horizontal scaling

Clones play a useful role in the performance of your Java web site. For very large multiprocessor servers, clones allow you to take better advantage of the CPU and memory available on the server. Clones assist with large-server vertical scaling. As discussed in Chapter 1, a single JVM cannot take full advantage of the resources available on an extremely large server. For example, if you use a 24-way, 64GB RAM server machine, you cannot expect to get full utilization of this box with a single JVM. If the single JVM uses 50% of the CPU available, adding another cloned JVM might raise that to 80% or 90%.

Cloning also allows the administrator to manage application server instances spread across multiple machines. This gives the administrator flexibility to better allocate resources, as well as centralized control over the web applications executing on the server machines.

Cloning Performance Tips

As with any other feature, cloning requires careful use to avoid performance pitfalls. Let's discuss some cloning performance best practices. (See Web Site Topologies in Chapter 3 for more on clones and the best practices for their deployment.)

Too Many Clones, Too Little Resource

Cloning does not solve problems for overloaded servers. If your server machine uses 100% of the CPU capacity (or even close to 100%), do not add clones to your server . The CPU is saturated . Instead, add CPU capacity to your system, or tune your application. Do not increase the CPU burden by adding clones to the server.

Scale Your Resources as You Add Clones

If you add clones to your servers or web site, don't forget to add resources to support them. Each clone requires database connections, heap space, and network capacity. If you add clones, add the resources the clone needs to operate .