WebSphere - Application Server & Database Performance Tuning

Author: Michael S. Pallos
Contributed by: Candle Corporation

Optimization of the production runtime environment boosts the performance of WebSphere Application Server applications, allowing organizations to harness the full potential of their hardware and software investments. Performance tuning of the network and database interfaces are two of the most important elements of the optimization process. This white paper explores best practices for performance tuning as it relates to the persistence layer of WebSphere Application Server and a database management system (DBMS).

---

Organizations running WebSphere Application Server AE are most likely using three databases: the WebSphere Application Server configuration repository, the session persistence repository, and the application data repository. If, however, an enterprise runs the single edition version of WebSphere Application Server, it is running only two database images: one for session persistence and another for application data. 

The configuration repository, when running the single edition version, is contained in a single XML configuration file. Multiple repositories increase the number of database connections and require organizations to optimize each connection independently. The interface between WebSphere Application Server and the DBMS(s) is critical, since this connection can either act as a bottleneck or facilitate high throughput.

Best Practices

An exploration of best practices in the following areas will provide a road map for the vital task of optimizing the storage and retrieval of persistence data:

1. Database connection pooling

2. Prepared statement cache

3. Session persistence

4. Enterprise JavaBeans

5. Java database connectivity

6. Application monitoring

We explore the first three areas in this article and will review the balance in Part 2 of the series.

Connection Pooling

Whenever an application uses a database resource, a connection must be established, maintained, and then released when the operation is complete. These processes consume time and IT resources. The complexity of accessing data from Web applications often imposes a strain on the system. Web applications are more taxing on the system for several reasons. Specifically, Web users:

• Connect to and disconnect from the database more often than users of non-Web applications

• Normally have shorter interaction times, making the database connection the longest component in the transaction

• Participate in unpredictable usage patterns, placing more demands on the database connection

WebSphere Application Server provides connection pooling to address some of the challenges of database access. Connection pooling is the process of creating a predefined number of database connections to a single data source. This process allows multiple users to share connections without requiring each user to incur the overhead of connecting and disconnecting from the database. Connection pooling can speed up application processing significantly.

When a user makes a request to a data source, WebSphere Application Server examines the connection pool for an existing resource connection. If one exists, it is provided to the user. The system then processes the database request. Once processing is complete, the connection resource is released from the user and placed back into the connection pool.

IBM used Sun Microsystems’ JDBC 2.0 Option Pack API to incorporate connection pooling. The system administrator sets the connection pool thresholds, which are easily configured using the WebSphere software administrator tools.

According to IBM’s DB2 UDB/WebSphere Performance Tuning Guide, best practices for connection pooling that will allow an application to achieve optimum performance include the following:

• Use the same method to both obtain and close the connection. This approach allows the connection resource to be released efficiently to the connection pool.

• Minimize the number of Java Naming and Directory Interface(JNDI) lookups, an expensive process in application performance. The JNDI expense is incurred by the out-of-process network call required for each JNDI lookup. To limit JNDI lookups, the developer should create a separate method to handle these calls. Once created, the separate method can be  called from the servlets init() method or from an EJB’s ejbActive() method.

• Do not declare connections as static objects. If a connection is declared as static, then it is possible to have the same connection used on different threads at the same time. This creates a problem for the connection pool and for the database.

• Do not close connections in the finalize method. As discussed earlier, connections should be opened and closed using the same method. There is, however, a school of thought that promotes closing everything in the finalize method, ensuring one location for complete closure. The finalize method is not called until the object is garbage-collected, since that is when all finalized methods are called. Closing connections in the finalize method can lead to a delay in releasing the connection and should be avoided.

• If you open a connection, close the connection. Closing a connection is not absolutely required, since WebSphere Application Server will implicitly close the connection after the connection has timed out. (It has a default value of 30 minutes.) An explicit close, however, expedites the process and follows good application development practices. More specifically, according to the DB2 UDB/WebSphere Performance Tuning Guide, “It is very important that ResultSet, Statement, Prepared Statement, and Connection objects get closed properly in an application. If connections are not closed properly, users may experience long waits for connections to time out, and delay return of the connection to the freepool.”

• Do not manage data access in container-managed persistence (CMP) beans. Developers should create CMP beans with the understanding that the container is going to handle the persistence. If one wishes to assume responsibility for persistence, then bean-managed persistence (BMP) should be used. Incorporating BMP processes in CMP beans slows performance.

Prepared Statement Cache

WebSphere Application Server applications may access a database using JDBC via a SQL callable statement, SQL statement call, or SQL prepared statement call. A callable statement removes the need for the SQL compilation process entirely by making a stored procedure call. A statement call is a class that can execute an arbitrary string that is passed to it. The SQL statement is compiled prior to execution, which is a slow process. Applications that repeatedly execute the same SQL statement can decrease processing time by using a prepared statement. A prepared statement redefines a statement call by separating the compilation process and adding substitution variables. This approach allows the application to prepare the statement once (via compilation) and reuse it at execution multiple times by leveraging different variables.

As a best practice, use prepared statements instead of a SQL statement call for applications that repeatedly execute the same SQL statements.

Session Persistence

Many applications, based on their size and activity level, find the use of memory local session cache on a local application server acceptable for session processing. As the application grows, however, so does its complexity. Such growth may require the incorporation of fault tolerance and redundancy, or the establishment of server clusters. As an application grows, the system administrator may also wish to achieve a higher level of control over the environment. Any or all of these requirements may render in-memory use on a local machine inadequate, requiring the use of session persistence to a database.

In order for data to be persisted to a database, the data must first be serialized. Serialization is the process of writing information to the database or disk, or flattening it out to be transferred over the wire. To serialize data, you must implement the Java interface java.io.Serializable. Persistent session management does not impact the API. Applications that may require session persistence, therefore, should include java.io.serializable in the code. When the application then scales using session persistence, the code will not require modification.

Once session persistence has been implemented, the session manager will keep the most recent 1,000 sessions in cache memory (this number is configurable) and persist the rest. This process allows the session manager to reduce the number of database accesses required for processing, thereby reducing memory requirements.

Following are several best practices to consider when planning for session persistence.

• Enable session persistence. Consider making Java objects held by HttpSession serializable,  even if the application currently operates with local session management. This approach will equip the application should the Web site grow to a size that requires persistence session management. The practice of preparing for growth makes the transition from local to persistent session management transparent to the application.

• Reduce session size. Reducing session size becomes particularly important when leveraging persistence sessions. The larger the session, the longer the write to the database, which, in turn, requires more disk i/o. According to Database System Concepts (McGraw-Hill), “disk access takes tens of milliseconds, whereas memory access takes a tenth of a microsecond.”  When developing sessions, place easily retrieved information in the application and not in the session. Also, remove stale or old data from the session. According to the DB2UDB/ WebSphere Performance Tuning Guide, “The best performance will be realized with session objects that are less than 2K. Once the objects start to exceed 4–5K in size, a significant decrease in performance can be expected.”

• Release HttpSession when finished.  WebSphere Application Server will release the session once the session has expired, but this can take up to 30 minutes when using the default configuration parameter. Explicitly release the HttpSession, forcing an immediate release of memory and garbage collection.

• Choose persistence options. IBM offers extensive guidelines for choosing persistence options in the DB2UDB/WebSphere Performance Tuning Guide.

• Avoid creating HttpSessions by JSP by default. Java Server Pages (JSP), according to the J2EE specification, create HttpSession objects by default. In the event you are not going to use the HttpSession object, processing requirements would be reduced by not creating the object. To prevent the default HttpSession object from being created, add %@page session=”false “% to the JSP.

• Tune the cache size. The default setting provides for 1,000 session objects to be cached.  Reducing the number of session objects in turn reduces the amount of required memory for session cache.

• Add additional application server clones. To implement vertical scaling, WebSphere Application Server allows the administrator to create multiple instances, or clones, of the application server. This process spreads the requirement for memory across multiple JVMs, thereby reducing the burden of a particular instance. You can also achieve horizontal scaling by adding additional physical hardware resources (servers) to the WebSphere Application Server configuration and implementing WebSphere Application Server clustering. Attempt vertical scaling first to save on purchasing additional hardware, followed by horizontal scaling, with the exception of standard baseline redundancy, which typically supports two physical hardware servers for failover.

• Tune multi-row persistence management. Multi-row session support allows session information obtained from multiple JSPs and servlets to be stored in the session database using multiple rows.

• Tune the session timeout interval. The WebSphere Application Server default setting for a session time-out is 30 minutes. Depending on the type of Web site being tuned, this number may be too high. At the same time, you must avoid setting the number too low, as it could frustrate users. Ensure that users have ample time to complete online forms. Users who invest a significant amount of time in completing an online document and then discover their session has timed out when they select Submit may not return to the site or recommend it to others.

PERFORMANCE TUNING

Enterprise JavaBeans 

The EJB specification is the foundation for Java 2 Enterprise Edition (J2EE), offering component services such as distributed transactions, security, and life-cycle management. There are two types of EJBs – session beans and entity beans (J2EE 1.3 also includes message-driven beans). A session bean instance belongs to a specific user and maintains the user’s state as he or she interacts with the Web site. User status information, however, is lost in the event of a catastrophic system failure. A shopping cart utilized by an online shopper exemplifies the use of a session bean.

As the user progresses through the Web site, he or she can add and remove items from the cart – the session bean. Once the user makes a purchase or chooses to leave the Web site without completing a purchase, the user’s interaction with the site is terminated and the session bean is destroyed.

An entity bean represents data – typically a row in a database – and can be shared among multiple users. Continuing with the shopping cart example, if the user makes a purchase, the data will persist to a database via an entity bean. Should the transaction require the creation of an invoice, an entity bean would be created containing the user’s data. Because it is persisted to the database, entity bean data will survive a system crash.

EJBs offer many advantages, including the ability to leverage distributed objects and transactional services. These advantages, however, come at a price – increased complexity. EJBs that are architected or incorporated incorrectly can have an adverse impact on application processing. Proper EJB utilization and optimization, conversely, reduces processing cycles, which, in turn increases application performance and enhances the end-user experience.

EJB best practices that optimize the storage and retrieval of persistence data include the following:

• Use the appropriate isolation level. Isolation levels are used to restrict access to a resource to which other concurrent transactions have access. They allow users to lock down or isolate shared database resources to four levels of granularity:

1. Read Uncommitted: The transaction can read uncommitted data from other transactions. Uncommitted transactions yield the lowest overhead since the container is doing the least amount of work. Imagine, for instance, that a user reads the database and retrieves certain values. Another user then starts a BEGIN WORK transaction and inserts values into the database. If the first user performs another database read before the second user has executed a COMMIT WORK or ROLLBACK command, he or she will read the uncommitted data that has been temporarily inserted into the database. The scenario just described is also known as a “dirty read.”
   
   

2. Read Committed: The transaction can read committed data only. If we repeat the scenario described above with a transaction state set to Read Committed, a user performing a read on a database containing data from a BEGIN WORK that has not been COMMITTED will not be able to access the uncommitted data. The user can only read committed data. A Read Committed is more restrictive than a Read Uncommitted isolation level, requiring the system to work harder. A Read Committed status, therefore, has a greater impact on processing than a Read Uncommitted status.
   
   

3. Repeatable Read: The transaction is guaranteed to read back the same data on each successive read. A Repeatable Read is more restrictive than a Read Committed, having an even greater impact on processing.
   
   

4. Serializable: All transactions are serialized or completely isolated from each other. A Serializable transaction is the most restrictive isolation level, and has the greatest impact on processing. An EJB that uses a serialized transaction isolation level is guaranteed to achieve consistent results from the database since the database is locked from other users, essentially creating single-threaded processing. While rookie developers are often tempted to incorporate the serializable isolation level to ensure data integrity, it has major constraints. Although results are guaranteed, all concurrent users are locked out of the database, which slows down the application. To optimize performance for data access, developers must fully understand the difference between the four isolation levels and their indicated uses.

• Carefully define access intent. The access intent attribute contains one of two states: (1) read and (2) update, with the default setting being update. For methods that are going to be READ ONLY, setting access intent to READ will increase data access performance. Under such conditions, the database is accessed with intent to read – and not update – thus removing unnecessary database locking.

Java Database Connectivity

JDBC provides a standard library for accessing relational data, allowing users to develop SQL calls using the Java Application Programming Interface (API). The JDBC driver is responsible for the data access communication interface with the database management system (DBMS).

Selecting the appropriate driver is fundamental to improving performance. According to Sun Microsystems, there are four categories of JDBC drivers (Types 1–4), and more than 177 models.

• Type 1 – JDBC–Open Database Connectivity (ODBC) bridge: A Type 1 driver provides JDBC access to one or more ODBC drivers. Type 1 drivers assist companies that already possess a large ODBC population with the JDBC educational process. Type 1 drivers are slow, however, because they require JDBC-ODBC translation. As such, they are not well suited for large enterprises.

• Type 2 – Partial Java driver: A Type 2 driver converts the calls made from the JDBC API to the receiving machine’s API for a specific database (DB2, Oracle, Sybase, SQL Server, etc.). A Type 2 driver contains compiled code for the backend system. Type 2 drivers process more quickly than Type 1 drivers. The code must be compiled, however, for every operating system on which the application runs. In Windows NT and z/OS development, organizations may wish to develop with a Type 4 driver and then transition to a Type 2 driver for production.

• Type 3 – Pure Java driver for database middleware: A Type 3 driver provides connectivity to many different databases, translating JDBC calls into the middleware vendor’s protocol and then into the database-specific protocol via the middleware server. A Type 3 driver is often faster than Type 1 and 2 drivers, and is useful if an organization wishes to connect to multiple database types. Database-specific code, however, must reside on the middle tier. If the application is going to run on different operating systems, a Type 4 driver may be more appropriate.

• Type 4 – Direct-to-database Java driver: A Type 4 driver converts JDBC calls into packets that are transferred over the network in the database’s proprietary format, allowing a direct call from the client to the database without a middle tier. Type 4 drivers often offer better performance than Type 1 or 2 drivers; do not require additional code on client or server machines; and can be downloaded dynamically. Type 4 drivers, however, are not optimized for the operating system and are unable to take advantage of operating system features. Users also need a different driver for each different database.

When developing on multiple platforms, many aspects of testing can be simplified by using a Type 4 driver. A Type 2 driver can be incorporated after system testing and production is completed. According to Sun Microsystems and IBM, Type 2 JDBC drivers offer the best performance when incorporating distributed transactions and catalog databases.

When selecting a driver, developers should also consider the JDBC API levels that it supports. Currently, there are two JDBC API levels. While JDBC 1.0 is the default, WebSphere requires JDBC 2.0. The JDBC API best practice is to incorporate version 2.0.

Application Development and Monitoring

WebSphere Application Server development and monitoring tools can offer insight into potential application bottleneck areas that require additional attention to achieve optimal performance. An ideal development tool identifies workflow analysis down to the method and thread level, offering real-time and historical information. Monitoring tools should also be able to report results on all elements contained within the application. These elements include the end user’s perspective through WebSphere Application Server, DBMS, transport layers, connection layer, and, if incorporated, any legacy system components.

Three best practices to consider when selecting and/or deploying monitoring capabilities follow:

• Select a development tool that delivers granular, real-time information. During development, a tool can help to identify and/or eliminate memory leaks, bottlenecks, and optimization. Development tools should offer granularity to the method level and thread level, SQL calls, and heap insight. The tool should also provide the ability to look into the application during execution and deliver sufficient analysis to allow developers to proactively address problems.

• Select monitoring tools that assist with the early stages of the development phase. Monitoring tools should be capable of capturing the complete end-to-end scenario, including the end-user experience, latency time, and the performance and availability of systems external to WebSphere Application Server, such as CICS, DB2, WebSphere MQ, and B2B.

Pure Java monitoring tools are excellent for initial development. However, many WebSphere Application Server applications incorporate external Java components to complete application processing. A desirable monitoring tool not only reports on the Java pieces of the application, but the entire application portfolio. If a highly productive Java application is executing on a machine that is underutilized, the operating system monitoring agent can then report the problem to the Java developer or operations personnel.

• Select a solution that offers both development and monitoring tools. (One choice could be the Candle PathWAI solution suite.) This strategy simplifies training, development, and production rollout.

Conclusion

The WebSphere Application Server provides an exceptional framework for running distributed Internet applications. Organizations can achieve service-level requirements by optimizing WebSphere software configuration. Best practices serve as a definitive road map for this critical process. Incorporating best practices for connection pooling, prepared statement cache, and session persistence creates an environment in which organizations are empowered to reduce costs associated with hardware and software, while simultaneously enhancing the user experience with faster Internet processing. In the second installment of this series, I will explore strategies for leveraging Enterprise JavaBeans, JDBC, and application monitoring.

Today’s developers face unprecedented pressure to create WebSphere applications that roll out rapidly and flawlessly, and adhere to business service–level requirements for processing and end-user experience. Once deployed, the challenges begin anew, as developers, system administrators, and operations work to optimize the production runtime environment for their WebSphere Application Server implementations.

Best practices for tuning WebSphere Application Server persistence layers, performance, and database interfaces represent the most direct and hazard-free path to optimizing WebSphere Application Server implementations.

References:

• Alur, N., Lau, A., Lindquest, S., and Varghese, M. (2002). “Websphere Application Server and DB2 UDB Performance.” DB2 UDB/ WebSphere Performance Tuning Guide. IBM Redbooks.

• Erickson, D., Lauzon, S., and Modjeski, M. (2001, August). WebSphere Connection Pooling:

• Silberschatz, A., Korth, H., and Sudarshan, S. (2002). Database System Concepts (4th ed.). McGraw-Hill Higher Education.

• Java 2 Platform, Standard Edition,v1.3.1 API Specifications: 
http://java.sun.com/j2se/1.3/ocs/api/

• JDBC Data Access API, JDBC 2.0 Optional Package API:
http://java.sun.com/products/jdbc/index.html

• Endrei, M., Cluning, R., Daomanee, W., Heyward, J., Iyengar, A., Mauny, I., et al. (2002). IBM WebSphere V4.0 Advanced Edition Handbook. IBM.

• Hutchison, G. (2002). DB2/WebSphere Integration:

• Monson-Haefel, R. (2000). Enterprise JavaBeans. O’Reilly & Associates.