- 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.
