J2EE Performace Tips
Sometimes
the performance aspects of a system are left to the end of the project.
Developers just don't have time to consider response times when speed of
delivery and functionality are the pressing goals. Performance bottlenecks must
be systematically identified and solved, which is no light task. The later in
the development life cycle you address them, the more expensive they become to
fix.
Small
optimizations (like turning logging down) can yield huge gains, whereas others
can have minuscule effects. The key to tackling bottlenecks is to prioritize
and focus on the areas of your code that will yield the biggest return for your
time investment. Focus on frequently used parts of the code, the parts critical
to your business. Gather accurate performance metrics and use repeatable test
cases to validate against your performance targets.
Performance Patterns and Techniques
You can scale your system to satisfy an increased load by using vertical and
horizontal scaling techniques (software and hardware), but not always.
Sometimes you can't use these techniques because either the budget is tight,
time is limited, or your system has inherent architectural limitations. In lieu
of adding more hardware, distributing your code, or adding more servers, you
can use the following server-side strategies to improve the performance of a
single J2EE/EJB application.
Database I/O Optimization
· Poor DBMS performance can arise from a
mismatch between the data-model, entity-bean design, and its usage. If your
most frequent user request joins 10 different tables and returns five entities
of which you use only one, then this is a design flaw. Align your DBMS access
to support your usage patterns. Write a query to return only the one piece of
data that you need.
· Search queries that use finders can take a
long time to run. Not only do they execute the finder query, but they also make
subsequent calls to the DBMS to load entity beans. It's more efficient to call
the DBMS with one bulk query than it is to issue a series of smaller requests.
Consolidate your search queries into a single JDBC call using a
DataAccessObject (DAO) or FastLaneReader (Marinescu/J2EE Blueprints).
· If your query results are large, however, you
may encounter problems when you try loading it all into memory in one hit. If
the client paginates the results, consider restricting the number of rows
returned to a total closer to your page size. You can always fetch more rows on
demand.
· Use built-in database features that may help
reduce query times, such as stored procedures, indexes, views, and table
caches.
Caching
· Within a given user transaction, the same
data may be requested multiple times. Try to reduce the number of redundant
reads. Either pass the information around as method parameters or consider
caching it on the session or thread context. Data that changes infrequently,
such as meta data or configuration data, is good for caching. You can load the
cache once at startup or on demand.
· Place your server caches strategically inside
your facades to make them transparent to the caller.
Transaction Control
· Long-lived transactions can lead to
connection timeouts, sharp memory increases, and DBMS lock contention. Your
session beans control transactions. Break up extremely long-lived transactions
into multiple shorter, more-reliable chunks.
· Chaining together many short-lived
transactions can also be slow. Widen your transaction boundaries. Increase
throughput and efficiency by manipulating the length of your transaction so it
performs many operations at once rather than one at a time.
· Establish general-purpose session bean
controllers to control your transactions. These can be independent of your
business logic. Use your beans to adjust the number of records processed in one
transaction so that you get optimum throughput for your request.
Threading
· Batch processes written with EJBs can run
very slowly because developers often build single-threaded batch jobs without
considering transactions. A process that executes inside one very long-lived
transaction (that could take hours or days) is fragile. If something goes
wrong, the entire job gets rolled back and you have to start again from
scratch. If your job executes as many small transactions chained together
inside a loop, then your job will be more reliable. The throughput will be low,
however.
· The container controls server-side threads.
Application code cannot create its own threads inside the EJB container, so it
cannot take advantage of threading directly. Typically, a container-managed
thread pool dispatches and services incoming server requests. This model works
well for session-oriented usage. The container load balances across competing
requests.
However, for batch processes, the goal is to achieve high throughput so the job
finishes as quickly as possible. Parallel processing can aid this. Spawn
threads outside the container and divvy up the load into small units of work
that are capable of being executed concurrently. Use threads to spread the
load. Don't spawn more threads than the server can handle. Keep the number of
client threads to fewer than the containers thread pool limit.
· Aggressive threading can reveal locking
issues and non-thread-safe code inside the server. Structure your components so
that they are thread-safe and can work concurrently, avoiding DBMS contention.
Divide your units of work up so that they operate over different data sets.
Deferred Processing
· How real-time are your requirements? Not
every component has to respond in real-time. If your on-line response time is
slow, reduce the amount of work performed during the request and defer
expensive or non-essential functions to later. You can store work temporarily
in holding tables or execute it asynchronously using JMS.
· Components that don't have strict real-time
requirements, such as data-extraction programs, collation and sorting routines,
file import/export, etc., can be performed off-line as batch processes.
Database I/O Optimization Implementation—Pure JDBC for Read-only
Access
Entity beans provide an abstraction layer between the higher-level business
components and the database. When a developer makes a call to a method on a
bean, he or she doesn't see what happens under the covers because it's
transparent. The developer can assemble large objects or data structures using
many entity calls. He or she can be oblivious to the expensive low-level
database I/O taking place. One way to alleviate this bottleneck is to replace
your critical sections with specialized pieces of pure JDBC code that are
optimized for the task. DataAccessObjects (DAOs) and FastLaneReaders
(Marinescu/J2EE Blueprints) are common techniques for accelerating reads. These
patterns give you fine-grained control over your queries for efficient read
access. A DAO can be used to consolidate many DBMS requests made by an entity
bean (finder + loads) into a single JDBC call. DAOs are useful for supporting
search screens or requests over data that span multiple beans and/or database
tables.
The
following are recommended practices for DAO:
- Use your DAO to
query for data directly from the DBMS rather than via your entity beans.
Session beans and other components can call your DAO directly.
- Design your DAO
so that it can be tailored to return only what you need.
- Design your DAO
so that it can limit the number of rows returned.
- Use finally
clauses to ensure that all JDBC resources are closed when you're finished
with them. This ensures that you don't hog or consume connections and
cursors.
- Query against
DBMS views to make your DAOs more reusable and portable. If you need to
make a change to a query, make a change to the view instead.
With
a DAO you can take advantage directly of the features provided by the JDBC API,
including:
- PreparedStatements
to pre-compile frequently executed SQL statements
- Batch methods on
the Statement class (addBatch() and exectuteBatch()) to batch up multiple
SQL calls into one hit to the database
- Row limiting
(The Statement and ResultSet classes provide methods (setMaxRows() and
setFetchSize()) to limit the number of rows returned and set hints for
ResultSet fetch sizes.)
See
Listing 1: A Simple DAO
for executing SQL against a view and limiting the number of rows returned in a
ResultSet.
As
part of your DAO design, you must decide in which form the data should be
returned and how it should be converted. In some cases, you may want to return
loosely typed collections such as Lists or Maps, and in other cases you may
want to immediately convert ResultSet data into strongly typed Java objects
relevant to your system. One way to handle this at the DAO level is to use a
helper ResultSetConverter interface. This interface is responsible for
converting RowSets into strongly typed application object types or collections.
The DAO uses it to automatically convert ResultSet data into your target
object(s):
public interface ResultSetConverter {
public Object toObject(ResultSet rs) throws Exception;
}
Create
a simple ResultSet to Map Converter class by implementing the ResultSetConverter
interface. Inside the toObject() method, pull the data from the result set and
place it into a map of column name/value pairs. The map is returned to the DAO
to be passed back to the DAO caller:
class MapConverter implements ResultSetConverter {
public Object toObject(ResultSet rs) throws Exception {
Map map = new HashMap();
ResultSetMetaData meta = rs.getMetaData();
// Load ResultSet into map by column name
int numberOfColumns = meta.getColumnCount();
for (int i = 1; i <= numberOfColumns; ++i) {
String name = meta.getColumnName(i);
Object value = rs.getObject(i);
// place into map
map.put(name, value);
}
return map;
}
}
To
use your DAO and converter, acquire a DAO instance and invoke the query()
method to execute your SQL. Use the rowLimit parameter to limit the number of
rows returned and pass in the converter class for the DAO to use.
DAO dao = DAO.get();
// Create our own converter for getting the first column as a String
ResultSetConverter myConverter = new ResultSetConverter() {
public Object toObject(ResultSet rs) throws Exception {
return rs.getString(1);
}
};
// Execute a query against a VIEW,
limit the number of rows returned to 10 and use myConverter to convert the results
List data = dao.query("myView", 10, myConverter);
// Do something with the data, ship to the JSP etc.
The J2EE Performance-tuning Trade-off
Experienced practitioners know that when addressing J2EE application
performance issues, there are no silver bullets. Performance tuning is a
trade-off between architecture concerns, such as flexibility and
maintainability. Performance increases are won by combining different
techniques, patterns, and strategies.
And
if all else fails, you can hope that that extra-fast machine you ordered turns
up sooner rather than later. :)
Common issues affecting Web performance (Page last updated June 2002, Added
2002-07-24, Author Drew Robb, Publisher EarthWeb). Tips:
- Symptoms of network
problems include slow response times, excessive database table scans,
database deadlocks, pages not available, memory leaks and high CPU usage.
- Causes of performance
problems can include the application design, incorrect database tuning,
internal and external network bottlenecks, undersized or non-performing
hardware or Web and application server configuration errors.
- Root causes of performance
problems come equally from four main areas: databases, Web servers,
application servers and the network, with each area typically causing
about a quarter of the problems.
- The most common database
problems are insufficient indexing, fragmented databases, out-of-date
statistics and faulty application design. Solutions include tuning the
index, compacting the database, updating the database and rewriting the
application so that the database server controls the query process.
- The most common network
problems are undersized, misconfigured or incompatible routers, switches,
firewalls and load balancers, and inadequate bandwidth somewhere along he
communication route.
- The most common application
server problems are poor cache management, unoptimized database queries,
incorrect software configuration and poor concurrent handling of client
requests.
- The most common web server
problems are poor design algorithms, incorrect configurations, poorly
written code, memory problems and overloaded CPUs.
- Having a testing
environment that mirrors the expected real-world environment is very
important in achieving good performance.
- The deployed system needs
to be tested and continually monitored.
Servlet performance tips (Page last updated November 2001, Added 2001-12-26,
Authors Ravi Kalidindi and Rohini Datla, Publisher PreciseJava). Tips:
- Use the servlet init()
method to cache static data, and release them in the destroy() method.
- Use StringBuffer rather than
using + operator when you concatenate multiple strings.
- Use the print() method
rather than the println() method.
- Use a ServletOutputStream
rather than a PrintWriter to send binary data.
- Initialize the PrintWriter
with the optimal size for pages you write.
- Flush the data in sections
so that the user can see partial pages more quickly.
- Minimize the synchronized
block in the service method.
- Implement the
getLastModified() method to use the browser cache and the server cache.
- Use the application server's
caching facility.
- Session mechanisms from
fastest to slowest are: HttpSession, Hidden fields, Cookies, URL
rewriting, the persistency mechanism.
- Remove HttpSession objects
explicitly in your program whenever you finish the session.
- Set the session time-out
value as low as possible.
- Use transient variables to
reduce serialization overheads.
- Disable the servlet auto
reloading feature.
- Tune the thread pool size.
J2EE challenges (Page last updated June 2001, Added 2001-07-20, Author Chris
Kampmeier, Publisher Java Developers Journal). Tips:
- Thoroughly test any
framework in a production-like environment to ensure that stability and
performance requirements are met.
- Each component should be
thoroughly reviewed and tested for its performance and security
characteristics.
- Using the underlying EJB
container to manage complex aspects such as transactions, security, and
remote communication comes with the price of additional processing
overhead.
- To ensure good performance
use experienced J2EE builders and use proven design patterns.
- Consider the impact of
session size on performance.
- Avoid the following common
mistakes: Failure to close JDBC result sets, statements, and connections;
Failure to remove unused stateful session beans; Failure to invalidate
HttpSession.
- Performance requirements
include: the required response times for end users; the perceived steady
state and peak user loads; the average and peak amount of data transferred
per Web request; the expected growth in user load over the next 12 months.
- Note that peak user loads
are the number of concurrent sessions being managed by the application
server, not the number of possible users using the system.
- Applications that perform
very little work can typically handle many users for a given amount of
hardware, but can scale poorly as they spend a large percentage of time
waiting for shared resources.
- Applications that perform a
great number of computations tend to require much more hardware per user,
but can scale much better than those performing a small number of
computations.
J2EE Application servers (Page last updated April 2001, Added 2001-04-20,
Authors Christopher G. Chelliah and Sudhakar Ramakrishnan, Publisher Java
Developers Journal). Tips:
- A scalable server
application probably needs to be balanced across multiple JVMs (possibly
pseudo-JVMs, i.e. multiple logical JVMs running in the same process).
- Performance of an
application server hinges on caching, load balancing, fault tolerance, and
clustering.
- Application server caching
should include web-page caches and data access caches. Other caches
include caching servers which "guard" the application server,
intercepting requests and either returning those that do not need to go to
the server, or rejecting or delaying those that may overload the app
server.
- Application servers should
use connection pooling and database caching to minimize connection
overheads and round-trips.
- Using one thread per user
can become a bottleneck if there are a large number of concurrent users.
Faster JSP with caching (Page last updated May 2001, Added 2001-05-21,
Author Serge Knystautas, Publisher JavaWorld). Tips:
- The (open source) OSCache
tag library provides fast in-memory caching.
- Cache pages or page
sections for a set length of time, rather than update the page (section)
with each request.
- Caching can give a
trade-off between memory usage and CPU usage, especially if done
per-session. This trade-off must be balanced correctly for optimal
performance.
Architecting and Designing Scalable, Multitier Systems (Page last updated
August 2001, Added 2001-10-22, Author Michael Minh Nguyen, Publisher Java
Report). Tips:
- 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 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 front-end).
- You can use invisible
applets in a browser to validate data on the client.
