Summary for the DB2 Connect performance tests

Edit online

After performing performance tests on the DB2 Connect™ environment, we compiled a summary of our results and recommendations.

This chapter provides a short summary of our test results. Our test results and recommendations are specific to our environment. Parameters useful in our environment might be useful in other environments, but are dependent on application usage and system configuration. You will need to determine what works best for your environment. For our detailed test results information, see Results for the DB2 Connect performance tests.

The following are our summary results:

General
  • We identified the WLM settings on z/OS® as an important parameter for database performance.
  • Limiting the number of connections to DB2® on z/OS can be used to limit the load created from this source on DB2. This protects the database against load peaks from the workload and improves mainframe resource utilization.
  • The DB2 Connect server may sustain continuous 100% CPU utilization with improving throughput even while its connections to z/OS DB2 grow as much as 12X.

Connection concentration

We identified several prerequisites for the mode where connections were concentrated on the DB2 Connect system.
  • On the DB2 Connect system, the parameter, MAX_CONNECTIONS, must be at least 1 greater than MAXAGENTS.
  • On the z/OS system the DSNZPARM parameter, MAXDBATS, must be equal to or greater than MAXAGENTS.
  • On the WebSphere® Application Server level, the parameter, resultSetHoldability, must be set to 2.
  • The application must have only a small amount of long running transactions (ideally none) and all cursors must be closed after commit.
Trade workload
  • A DB2 Connect guest with 512 MB of main memory started swapping slightly with 400 Trade users. Our maximum number of Trade users of 700 was well supported with a DB2 Connect system with 1 GB of memory. An additional 1 GB of main memory provided no advantage. It seems that about 512 MB of main memory is needed for each 400 users. We did all further tests with 1 GB of main memory for the DB2 Connect system.
  • The DB2 Connect system with a single CPU was overloaded with 400 concurrent users with this workload. It is recommended that DB2 Connect be run with a minimum of two CPUs when a high volume of concurrent active clients are likely.
  • When controlling the load on the DB2 on z/OS created from 600 Trade users by scaling the numbers of active connections via DB2 Connect MAXAGENTS from 50 to 600, a factor of 12X, the load on the DB2 on z/OS only varied by a factor of 2X. This shows that DB2 Connect was a suitable tool to control the load on the DB2 database.
  • When the Trade 6 transactions are routed though DB2 Connect, throughput degrades up to 8%. This may be considered a small impact to achieve predictable, efficient utilization of mainframe DB2 resources while handling widely varying client access volumes.
IRWW workload
  • DB2 Connect memory size does not affect IRWW throughput in these scenarios. A memory size of 1 GB was selected for the remainder of the IRWW test cases.
  • The IRWW workload throughput is not affected by the number of CPUs. A single CPU for the DB2 Connect system would be sufficient for this type of workload, but for a better comparison with the Trade 6 results, we decided to use two CPUs on the DB2 Connect system for further runs.
  • For the think time values used, a MAXAGENTS value of 100 was sufficient for this workload. This demonstrates that limiting connections to DB2 on z/OS can be done without a degradation of the throughput, up to a certain load level.
  • We selected the SQLJ workload driver because, in our environment, it produces slightly higher throughput at lower CPU utilization than the JDBC driver.
  • The IRWW workload creates a significantly lower load on the system than the Trade workload. DB2 Connect has here a higher impact on throughput than in the Trade 6 workload case. Bypassing DB2 connect resulted in an improvement between 6% and 30%. It seems that WebSphere balances the request rate in a way that the pressure on DB2 Connect is lower.