Conclusions:
1. The performance of each DB connection interface provides exceptional response time at very high
throughput. Each order processed consisted of ten web requests. As a result, the capacity ranges from
about 650 transactions per second up to about 870 transactions per second. Using Zend Platform will
provide even higher performance (refer to the section on Zend Platform).
2. The i5 PHP API Toolkit is networked enabled so provides the capability to run in a 3-tier environment,
ie, where the PHP application is running on web server deployed on a separate system from the backend
DB server. However, when running in a 2- tier environment, it is recommended to use the ibm_db2 PHP
extension to access DB2 locally given the optimized performance.
The i5 PHP API Toolkit provides a wealth of interfaces to integrate PHP pages with native i5 system
services. When standardizing on the use of the i5 toolkit API, the use of the SQL functions to access DB2
will provide very good performance. In addition to SQL functions, the toolkit provides a program call
interface to call existing programs. Calling existing programs using native DB IO may provide
significantly more performance.
3. The most compelling reason to use MySQL on IBM i is when you are deploying an application that is
written to the MySQL database.
Database - Persistent versus Non-Persistent Connections
If you're connecting to a DB2 database in your PHP application, you'll find that there are two alternative
connections - db2_connect which establishes a new connection each time and db2_pconnect which uses
persistent connections. The main advantage of using a persistent connection is that it avoids much of the
initialization and teardown normally associated with getting a connection to the database. When
db2_close() is called against a persistent connection, the call always returns TRUE, but the underlying
DB2 client connection remains open and waiting to serve the next matching db2_pconnect() request.
One main area of concern with persistent connections is in the area of commitment control. You need to
be very diligent when using persistent connections for transactions that require the use of commitment
control boundaries. In this case, DB2_AUTOCOMMIT_OFF is specified and the programmer controls
the commit points using db2_commit() statements. If not managed correctly, mixing managed
commitment control and persistent connections can result in unknown transaction states if errors occur
.
In the following table, we compare the performance of utilizing non-persistent connections in all cases
versus using a mix of persistent and non-persistent connections versus using persistent connections in all
cases.
IBM i 6.1 Performance Capabilities Reference - January/April/October 2008
©
Copyright IBM Corp. 2008
Chapter 6 - Web Server and WebSphere
90
OS / DB
i 5.4 / DB2
i 5.4 / DB2
i 5.4 / DB2
ZendCore Version
V2.5.2
V2.5.2
V2.5.2
Connect
db2_connect
Mixed
db2_pconnect
OPM
445
2161
4997
RT (ms)
2021
414
176
Total CPU
91
99
99
CPU - Zend/AP
9
33
62
CPU - DB
78
62
33
