Category list

The Top 20 List of Performance Development Considerations

Table 10-1 lists the top 20 rock-solid performance development considerations this chapter covers.

Table 10-1: Top 20 WebSphere Application Performance Considerations
Consideration	Targeted Tier
Avoid constant use of large session objects	Web tier
Invalidate HTTP sessions when they aren't required	Web tier
Use the init() servlet method if doGet() and doPost() aren't required	Web tier
Use <jsp: usebean ()> carefully	Web tier
Don't use the single-threaded model with servlets	Web tier
Reuse EJB homes where possible	Business tier
Consider Pass-by-Reference rather than Pass-by-Value	Business tier
Use a multithreaded logger instead of system.out.println()	Business tier
Use container threading services and avoid manually spawning threads	Business tier
Avoid lazy initialization of objects	Business tier
Avoid overusing Java niceties	Business tier
Avoid stateful EJBs where possible	Business tier
Use constants	Business tier
Assume remote objects, but write for local	Business tier
Use Abstraction	Business tier
Use WebSphere data sources	Data tier
Release JDBC resources when you've finished with them	Data tier
Use container-managed persistence only for high-read database access	Data tier
Use Data Access Objects for general database access	Data tier
Use prepared SQL statements where possible	Data tier

Let's now take a look at each consideration in more detail. Considerations appear under the appropriate tier.

Web Tier Performance

The Web tier refers to all Web containers, Web servers, and components. This includes Java components such as

JavaServer Pages (JSP) pages
Servlets
Standard classes and beans
Session Manager settings

Avoid Constant Use of Large Session Objects

As you've learned in previous chapters, sessions are a key element of any Web-based WebSphere application environment. It's possible to overuse sessions by filling them up with unnecessary information, not releasing unwanted elements after use, or using them for incorrect purposes. The effect is exaggerated when session persistence is used to achieve additional levels of redundancy.

Essentially, in the case of persisting the session object because accessing the session object requires serialization and deserialization for each update and read, respectively (to and from the session persistence layer), the J2EE application incurs significant overhead if sessions become too large. This impact is further realized if you use persistent sessions, in which you persist sessions to a database in order to gain availability.

To summarize,

Don't use sessions for storing large amounts of data for all users.
Try to keep session object sizes at around 4KB for 95 percent of all session objects. This allows for some large sessions, which may be required to store specific data (e.g., 100KB of data to store an uploaded text file).
Don't load everything into a session object. Only load the specific information you need in your session at any one time. Too often I've seen situations in which environments load large amounts of data into session objects, only to need very specific amounts of data.
Consider using a database to store information specific to user sessions if you find that you need to constantly go over the 4KB session object size. Performance will degrade as you go above 4KB to 6KB for session object size , depending on overall system load.

Performance and scalability benefit:	1
Implementation complexity:	3

Invalidate HTTP Sessions When They Aren't Required

HTTP sessions are often used in Web applications. One of the common implementation errors that developers make is not cleaning up sessions that are no longer required. This is a side effect of the thought that because you don't need to manage memory in Java (unlike in C, C++, and so on), you don't need to clear off unused objects.

Because WebSphere can maintain only a certain number of sessions at any one time in memory (a configurable counter), and the fact that there's a finite amount of memory available per application Java Virtual Machine (JVM), you'll want to ensure that you provide your JVM and other application threads the maximum amount of memory available or required by them. By also not invalidating the HTTP sessions forcefully , the JVM garbage collection will spend more time clearing out heap space for other application threads, which impacts over-all JVM performance.

To summarize,

Ensure that your users are provided with a "log off" function that calls the invalidate() method.
Carefully model your users' online and pause times. You maybe able to decrease the period until WebSphere times out and ultimately forces all timed-out sessions to be invalidated. The default WebSphere setting is 30 minutes (1,800 seconds).

Performance and scalability benefit:	3
Implementation complexity:	2

Use the init() Servlet Method if doGet() and doPost() Aren't Required

Basic servlets consist of the init() , doGet() , and doPost() methods , which are used for different purposes when a servlet is called. The init() method is called each time a call to initialize a servlet is made, whereas the doGet() and doPost() methods are only called when those types of HTTP transactions are requested through the HTTP headers in a user request.

Quite often, a servlet isn't required to perform any function based on input. For this reason, there's no need to use a doGet() method call ”this will incur overhead that isn't required. Consider placing heavy or expensive transactions in the init() method instead of in the doGet() and doPost() methods. A classic example is to place bindings to data sources in the init() method, which will alleviate a rebind on each doGet() or doPost() method call. This will increase performance within your application.

To summarize, question the use of doGet() and doPost() method usage in servlets if the servlets aren't expecting any input but are required to return information.

Performance and scalability benefit:	3
Implementation complexity:	2

Use <jsp: usebean ()> Carefully

This JSP tag allows developers to directly call a JavaBean from within the JSP code. Quite often, developers use this approach in JSP pages to fill small variables or values into JSP output such as simple integers (e.g., account balances ).

This tag, however, will create a new instance of the specific JavaBean if the JavaBean object doesn't already exist. Creating the new bean is an expensive JVM operation and, unless required, it should be used only to obtain a reference to an existing Java object.

Performance and scalability benefit:	3
Implementation complexity:	2

Don't Use the Single-Threaded Model with Servlets

A design approach exists with servlets that allows the servlets to be developed using a single-threaded model. This approach is sometimes used to ensure the protection of specific variables within a servlet's context; however, it does introduce a performance and scalability implication by limiting the number of servlet threads that can be running concurrently.

If specific variables need to be managed per client thread, consider using the session object for small variables or other forms of data storage, such as memory caches and/or databases.