![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
If you are responsible for developing, delivering or tuning applications that are based on DB2® Universal Database® (DB2 UDB) 7.2 or later and WebSphere® Application Server Advanced Edition (4.0.1 or later) and which use session persistence, this article offers some advice on how to make those applications run faster.
First, we present a brief conceptual introduction to some of the key technical concepts, including HTTP sessions and session persistence. Then, we examine "page size" as a configuration parameter to make the persistence more efficient. This parameter can be directly configured from the Session Manager option in the WebSphere Application Server Console and is only available when using DB2 UDB with WebSphere Application Server. The support structure for this parameter is created from within the DB2 Command Line Processor.
Finally, we analyze and describe the impact of this parameter from a performance perspective. We illustrate the findings with the help of a session servlet and a typical servlet stress suite. We conclude with some best practices that help you deliver high performing applications.
This section contains a brief conceptual introduction of HTTP sessions, session persistence, and session caching.
HTTP sessions are used to maintain state information as an end user navigates a web-based application. A session, simply put, is a series of requests to a servlet from the same browser (user). This session allows the servlet engine to "personalize" the user experience by keeping track of the individual users during the course of navigation, including any transactions.
A few typical scenarios where sessions might be useful are as follows:
- In an online banking scenario, users log on to a banking site, and
details about their account or their authentication information can
tag along on their session object while they pay their bills or
perform other transactions.
- In an e-commerce scenario, sessions can be used to provide online shopping carts. All purchases are tracked using the user's session object.
Servlets distinguish users by unique session IDs. If the browser is cookie-enabled, the session ID can be stored as a cookie, or it can be sent to the servlet using URL rewriting. In URL rewriting, the session ID is appended to the URL of the servlet or the Java™ Server Page (JSP) file for which the user is making the request. This session ID arrives with each HTTP request.
WebSphere provides a Session Manager facility that supports the javax.servlet.http.HttpSession interface described in the Servlet API.
Figure 1 shows the Session Manager in WebSphere Application Server where cookies and the URL rewriting can be enabled.
Figure 1. Enabling cookies and URL rewriting with WebSphere Application Server Session Manager
WebSphere allows multiple application instances to share a common pool of session objects; this common pool is known as a session cluster. Persistence of this data to an external data store provides an efficient way to share the servlet state information across multiple machines that run the same application. This framework provides fault-tolerance and failover support for unplanned outages in the event of a system failure.
WebSphere Application Server provides the ability to persist servlet state data to any relational database. Of course, we focus our attention on DB2 UDB. If a virtual host in the cluster fails during the modification of a user's session object, then an update to the database does not occur. Still, the common pool of sessions continues to function; another virtual host will take over the processing and roll back any incomplete transactions, thus maintaining the integrity of the data. In the Servlet API, this cycle is maintained as follows:
- The getAttribute() method performs a SELECT on the database.
- The setAttribute() method performs an UPDATE on the database to
persist the changes to the session object, however, if the option
Multirow Sessions is enabled in WebSphere Application Server, then
setAttribute() amounts to an INSERT on the database.
- Finally, the invalidate() method performs a DELETE on the database. The invalidate() method can be called by the application to drop the session object, or it can be called by WebSphere, which drops sessions after a specified period of inactivity (the default is 30 minutes). Figure 2 shows how you can set the invalidation timeout period in WebSphere Application Server Session Manager.
Figure 2. Setting the invalidation time in WebSphere Application Server Session Manager
WebSphere session support keeps some of the most recently used sessions in memory so as to avoid multiple I/Os to the database. WebSphere compares the session's last access time field from the database to the last access time of the cached session and makes the decision if the session is still valid. You can speed up this process by using the database cache (buffer pool) in DB2, which keeps the most recently used queries in memory.
Maintaining servlet state data is an important design decision that impacts application performance. Making good decisions at this point can go a long way toward ensuring the best possible performance and scalability of your applications. The evaluation shows that tuning DB2 UDB and WebSphere Application Server for session persistence can improve overall application performance.
Our analysis is based on a set of test servlets that use 4KB, 10KB and 30KB session objects. Our goal is to evaluate the impact of the WebSphere 4.0.x page size parameter with DB2 UDB. These servlets are called repeatedly using a typical stress proxy tool. The key metric used here is requests per second and response time. We also monitor the performance from a database perspective using the DB2 UDB snapshot monitor facility.
The servlets used are simple examples that request a session and then generate a response that calls a custom session data object that is either 4KB, 10KB or 30KB in size. Sample code of the servlets and the object classes is available in the Appendix. A typical call to the servlet from a browser results in the output similar to Figure 3.
We do not use the browser to call the servlets. The stress proxy tool calls each of these three servlets 10000 times and produces mean values for each run.
Figure 3. Response from a test servlet that call large session objects
The session data objects we use are character arrays in Java. These objects are serialized before they are written out to DB2 UDB. Each character requires two bytes of space due to UNICODE representation. Thus, our objects are characterized as shown in Table 1.
Table 1. Sizes of session data objects
| Object | Number of characters | Number of bytes (approx) |
|---|---|---|
| 4KB object | 2000 | 4000 |
| 10KB object | 5000 | 10000 |
| 30KB object | 15000 | 30000 |
From this point on, our discussion focuses on how changing the WebSphere Application Server page size and the corresponding DB2 UDB page size brings about performance improvements for applications using sessions with data objects of size 4KB, 10KB, and 30KB.
The advantage of using three different object sizes is to monitor the effect of page size on a realistic simulation of the session persistence scenario.
Rows in DB2 UDB are physically stored in blocks called pages. We can adjust the size of these pages to fit the needs of our application data. Table spaces in DB2 UDB are logical layers between the database and the tables stored in that database. You create table spaces within a database, and you create tables within a table space. Each table space has an associated buffer pool. A buffer pool is a database object used to cache database pages in memory. If an object's data page is placed in the buffer pool, physical I/O access to disks can be avoided. Both the table space and buffer pool must have the same page size. The default value for the DB2 UDB table space and buffer pool page size is 4KB. However, we can change this value to better suit our needs. If the application uses session data that is more than 4KB in size, it would be more efficient to use a larger page size, up to a maximum of 32KB.
Figure 4 is an image of the Session Manager utility within the WebSphere Application Server Console. Here the WebSphere page size must be set to match the DB2 UDB page size to take advantage of the DB2 UDB buffer pool.
Figure 4. Configuring the database in WebSphere Application Server Session Manager
To use a different page size than 4KB, we must perform the following steps:
- Create a new DB2 UDB buffer pool that supports the desired page size.
- Create a table space with which the newly created buffer pool is associated with it.
- Select the desired page size from the WebSphere Application Server's Session Manager (DB2 row size).
- Type in the new table space name in the WebSphere Application Server's Session Manager (Table space name).
Figure 5 shows the DB2 SQL statements you can use to create an 8KB buffer pool and a table space that uses that buffer pool.
Figure 5. DB2 SQL statements for creating a buffer pool and table space
DB2 CREATE BUFFERPOOL SessionBP8K SIZE 250 PAGESIZE 8 K
DB2 CREATE REGULAR TABLESPACE SessionTS8K PAGESIZE 8 K
MANAGED BY
SYSTEM USING ('C:\IBM\DB2\SQLLIB\DB2\SessionTS8K.0')
EXTENTSIZE 16
OVERHEAD 14.06 PREFETCHSIZE 16 TRANSFERRATE 0.33
BUFFERPOOL SessionBP8K
Note: Some of these parameters such as TRANSFERRATE, etc. are subject to
change based on the environment used.
|
We created table spaces (and associated buffer pools) with page sizes of 8KB, 16KB, and 32KB and ran the stress test. The results are shown in the following tables:
Table 2. Results for 4KB page sizes
| 4KB object | 10KB object | 30KB object | |
|---|---|---|---|
| Average number of requests per second | 121.95 | 119.05 | 86.21 |
| Average response time (milliseconds) | 388 | 395 | 466 |
Table 3. Results for 8KB page sizes
| 4KB object | 10KB object | 30KB object | |
|---|---|---|---|
| Average number of requests per second | 133.58 | 121.89 | 87.72 |
| Average response time (milliseconds) | 329 | 382 | 462 |
Table 4. Results for 16KB page sizes
| 4KB object | 10KB object | 30KB object | |
|---|---|---|---|
| Average number of requests per second | 134.66 | 132.01 | 87.73 |
| Average response time (milliseconds) | 328 | 341 | 460 |
Table 5. Results for 32KB page sizes
| 4KB object | 10KB object | 30KB object | |
|---|---|---|---|
| Average number of requests per second | 138.89 | 134.52 | 98.28 |
| Average response time (milliseconds) | 326 | 339 | 415 |
To analyze these results, let us first look at the DB2's table called "sessions" where the session data information is stored. WebSphere Application Server creates a DB2 table called sessions in the table space specified to persist the session data. The sessions table contains various columns to store the session data information such as session ID, creation time, last access time, username, etc. Session data that is less than the page size is stored in the column named small, which is defined as a VARCHAR, which is efficiently buffered in DB2. As the session data increases in size it is put in the medium column (LONG VARCHAR) or the large column (BLOB). Figure 6 shows the description of the sessions table in DB2. By using a larger page size, we can ensure that most of the session data information is stored in the small column, thus improving overall performance by being able to use efficient VARCHAR buffering.
Figure 6. Description of sessions table in DB2, used to store session object data
In our experiment we notice that by increasing the page size from the default of 4KB to 8KB, we see an immediate improvement in performance for 4KB objects. This is because the larger size enables the 4KB object to fits in the small data column of the sessions table and has improved efficiency. For the same reasons, we see improvements in performance for 10KB and 30KB objects with the 16KB and 32KB page sizes, respectively.
As Figure 7 and Figure 8 illustrate, increasing the page size creates the following points of inflection:
- For 4KB data objects, the inflection point is at page size 8KB as the 4KB data now fits in the small column of the sessions table.
- For 10KB data objects, the inflection point is at page size 16KB as the 10KB data now fits in the small column of the sessions table.
- For 30KB data objects, the inflection point is at page size 32KB as the 30KB data now fits in the small column of the sessions table.
This is attributable to the fact that now even the large-size data -- a 30K data object -- can be stored in the small data column in the DB2 sessions table. The small column is of data type VARCHAR, which ensures better buffer pool usage and overall improved efficiency.
Figure 7. An increase in page size leads to improved throughput
Figure 8. An increase in page size leads to improved response time
By properly configuring DB2 and WebSphere Application Server parameters for session persistence, you can improve the efficiency and overall application performance of your applications. Page size is an important factor for the efficiency of session data storage. You can choose the page size that is optimal for your application by using the WebSphere Application Server Console.
In our scenarios, we were able to demonstrate following improvements in performance when the page size was adjusted to best suit the data size, as shown in Table 6.
Table 6. Percent improvement in throughput and response time with optimized page sizes
| Data size | % Improvement in Requests per Second (approx) | % Improvement in Response time |
|---|---|---|
| 4K object | 15 | 16 |
| 10K object | 14 | 14 |
| 30K object | 14 | 11 |
In conclusion, there is a definite reward for configuring the page sizes in WebSphere and DB2 to take advantage of DB2 buffer pools. This feature is only available when using WebSphere Application Server with DB2 UDB and is another example of tight integration of WebSphere Application Server with DB2 UDB.
The test environment used for the scenarios described in this article was:
| Processor: | P III 750 Megahertz |
|---|---|
| Memory: | 1 Gigabyte |
| Operating System: | MS Windows NT® 4 (SP4) |
| Database: | IBM DB2 7.2.2 (FP 4) |
| Application Server: | IBM WebSphere Application Server 4.0.1 |
| HTTP Server: | IBM HTTP Server 1.3.19 |
The authors recognize the help, guidance and expertise of Grant Hutchison, the DB2-WebSphere Integration Team, and many others at the IBM Toronto Software Lab.
The furnishing of this document does not imply giving license to any IBM patents. References in this document to IBM products, Programs, or Services do not imply that IBM intends to make these available in all countries in which IBM operates.
| Description | Name | Size | Download method |
|---|---|---|---|
| Code to create the servlets and session objects | persistencesamples.zip | 3KB | HTTP |
Information about download methods
Learn
- See the IBM DB2 web
site.
- See the IBM WebSphere web
site.
- Learn more about Information Management at
the developerWorks
Information Management zone. Find technical documentation, how-to
articles, education, downloads, product information, and more.
- Stay current with developerWorks technical events and webcasts.
- Follow developerWorks on
Twitter.
Get products and technologies
- Build your next
development project with IBM trial
software, available for download directly from
developerWorks.
Discuss
- Check out the developerWorks
blogs and get involved in the developerWorks
community.
Peter He is a Software Developer with the DB2 Integration Team at IBM Toronto Lab. Peter has been working extensively with DB2 and WebSphere technologies and is the architect of the IBM Video Central software based on Web Services architecture. He holds a Ph.D. from York University and is a DB2 Certified Solutions Expert.
Table of contents
Next steps from IBM
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
