17.7 More Performance Tips

I list many performance tips for servlets and JSPs at http://www.JavaPerformanceTuning.com/tips/j2ee_srvlt.shtml. Here's a summary of tips we haven't covered yet.

Turn security checks off

Security checks consume CPU resources. You will get better performance if you can turn security checking off.

Optimize the servlet-loading mechanism

Try to optimize the servlet-loading mechanism (for example, by listing the servlet first in loading configurations).

Avoid reverse DNS lookups

Avoid reverse DNS lookups (e.g., ServletRequest.getRemoteHost( )). These lookups take significant time and block the thread. Instead, log the raw IP addresses and use a separate process to execute reverse DNS lookups to supplement the logs.

Precompile JSPs

Precompile your JSPs to avoid giving the first user a slow experience. Either run the page once before making it public (which compiles it), or use the application server's features to precompile the servlet.

Make the servlet event-driven

The Servlet 2.3 specification adds application and session events. Event-driven applications can often be scaled more easily than process-driven applications. Try to make your servlet event-driven.

Servlet filters mean overhead

Servlet filters provide a standardized technique for wrapping servlet calls. However, they have some overhead, which translates to a reduction in performance.

Separate UI logic from business logic

Separate the UI controller logic from the servlet business logic, and let the controllers be mobile so they can execute on the client, if possible.

Validate data at the client

Validate data as close to the data-entry point as possible, preferably on the client. This reduces the network and server load. Business workflow rules should be on the server (or further back than the frontend). You could use invisible applets in a browser to validate data on the client, but the extra time required to download the applet may make this unusable.

Use Keep-Alive for static sites

HTTP 1.1's Keep-Alive feature gives a higher throughput for static sites, but may be extra overhead for dynamic sites.

Increase server listen queues

Increase server listen queues for high-load or high-latency servers. The listen queue is a TCP/IP-level queue for incoming socket accepts and is set with the second argument to the ServerSocket constructor (if you are explicitly creating a server socket). The application server must expose the parameter as a configuration option for you to adjust this.

Disable auto-reloading

Disable the JSP auto-reloading feature. Auto-reloading is a development feature of many application servers that repeatedly reloads servlets and JSPs. Turn this feature off for performance tests and deployed systems.

Tune pool size

Tune pools in the application server (see Chapter 18 for details).

Access data efficiently

Transform your data to minimize the costs of searching it. If your dataset is small enough, read it all into memory or use an in-memory database (keeping the primary copy on disk for recovery). An in-memory database avoids overhead in several ways: it eliminates passing data in from a separate process, reduces memory allocation by avoiding data copies as it passes between processes and layers, eliminates the need for data conversion, and enables fine-tuned sorting and filtering.

Precalculation expedites some results by making the database data more efficient to access (by ordering it in advance, for example), or by setting up extra data in advance, generated from the main data, to simplify result calculations.