IBM Power Systems Performance Capabilities Reference IBM i operating system Version 6.1


Applies To:

[ Zend Core V2.x ]
[ IBM System i ]



This article includes information about PHP performance with Zend Core and IBM System i.
IBM Power Systems Performance Capabilities Reference IBM i operating system Version 6.1(Chapter 6)


6.2 PHP - Zend Core for i

This section discusses the different performance aspects of running PHP transaction based applications using Zend Core for i, including DB access considerations, utilization of RPG program call, and the benefits of using Zend Platform.


Zend Core for i

Zend Core for i delivers a rapid development and production PHP foundation for applications using PHP running on i with IBM DB2 for i or MySQL databases. Zend Core for i includes the capability for Web servers to communicate with DB2 and MySQL databases. It is easy to install, and is bundled with Apache 2, PHP 5, and PHP extensions such as ibm_db2.

The PHP application used for this study is a DVD store application that simulates users logging into an online catalog, browsing the catalog, and making DVD purchases. The entire system configuration is a two-tier model with tier one executing the driver that emulates the activities of Web users. Tier two comprises the Web application server that intercepts the requests and sends database transactions to a DB2 for i or MySQL server, configured on the same machine.



System Configuration

The hardware setup used for this study comprised a driver machine, and a separate system that hosted both the web and database server. The driver machine emulated Web users of an online DVD store generating HTTP requests. These HTTP requests were routed to the Web server that contained the DVD store application logic. The Web server processed the HTTP requests from the Web browsers and maintained persistent connections to the database server jobs. This allowed the connection handle to be preserved after the transaction completed; future incoming transactions re-use the same connection handle. The web and database server was a 2 processor partition on an IBM System i Model 9406-570 server (POWER5 2.2 Ghz) with 2GB of storage. Both IBM i 5.4 and 6.1 were used in the measurements, but for this workload there was minimal difference between the two versions.


Database and Workload Description

The workload used simulates an Online Transaction Processing (OLTP) environment. A driver simulates users logging in and browsing the catalog of available products via simple search queries. Returning customers are presented with their online purchase transactions history, while new users may register to create customer accounts. Users may select items they would like to purchase and proceed to check out or continue to view available products. In this workload, the browse-buy ratio is 5:1. In total, for a given order (business transaction) there are 10 web requests consisting of login, initiate shopping, five product browse requests, shopping cart update, checkout, and product purchase. This is a transaction oriented workload, utilizing commit processing to insure data integrity. In up to 2% of the orders, rollbacks occur due to insufficient product quantities. Restocking is done once every 30 seconds to replenish the product quantities to control the number of rollbacks.


Performance Characterization

The metrics used to characterize the performance of the workload were the following:

  • Throughput - Orders Per Minute (OPM). Each order actually consists of 10 web requests to complete the order.
  • Order response time (RT) in milliseconds
  • Total CPU - Total system processor utilization
  • CPU Zend/AP - CPU for the Zend Core / Apache component.
  • CPU DB - CPU for the DB component


Database Access

The following four methods were used to access the backend database for the DVD Store application. In the first three cases, SQL requests were issued directly from the PHP pages. In the fourth case, the i5 PHP API toolkit program call interface was used to call RPG programs to issue i5 native DB IO.

For all the environments, the same presentation logic was used:


  • ibm_db2 extension shipped with Zend Core for i that provides the SQL interface to DB2 for i.
  • mysqli extension that provides the SQL interface to MySQL databases. In this case the  MySQL InnoDB and MyISAM storage engines were used.
  • i5 PHP API Toolkit SQL functions included with Zend Core for i that provide an SQL interface to DB2 for i.
  • i5 PHP API Toolkit classes included with Zend Core for i that provide a program call interface.


When using ibm_db2, there are two ways to connect to DB2. If empty strings are passed for userid and password on the connect, the database access occurs within the same job that the PHP script is executing in.
If a specific userid and password are used, database access occurs via a QSQSRVR job, which is called server mode processing. In all tests using ibm_db2, server mode processing was used. This may have a minimal performance impact due to management of QSQSRVR jobs, but does prevent the apache job servicing the php request from not responding if a DB error occurs. When using ibm_db2 and the i5 toolkit (SQL functions), the accepted practice of using prepare and execute was utilized. In addition stored procedures were utilized for processing the purchase transactions. For MySQL, prepared statements were not utilized because of performance overhead. Finally, in the case of the i5 PHP API toolkit and ibm_db2, persistent connections were used. Persistent connection provides dramatic performance gains versus using non-persistent connections. This is discussed in more detail in the next section.


In the following table, we compare the performance of the different DB access methods:

OS / DB i 5.4 / DB2

MySQL 5.0 i 5.4

i5.4 / DB2 i5.4 / DB2
ZendCore Version V2.5.2 V2.5.2 V2.5.2 V2.5.2
Connect db2_pconnect mysqli i5_pconnect i5_pconnect i5_pconnect
       SQL function Pgm Call Function
OPM 4997 3935 3920 5240
RT (ms) 176 225 227 169
Total CPU 99 98 99 98
CPU - Zend/AP 62 49 63 88
CPU - DB 33 47 33 7


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:


i 5.4 / DB2

i 5.4 / DB2

i 5.4 / DB2

ZendCore Version












RT (ms)




Total CPU




CPU - Zend/AP










1. As stated earlier, persistent connections can dramatically improve overall performance. When using persistent connections for all transactions, the DB CPU utilization is significantly less than when using non-persistent connections.
2. For any transactions that run with autocommit turned on, use persistent connections. If the transaction requires that autocommit be turned off, use of non-persistent connections may be sufficient for pages that don't have heavy usage. However, if a page is heavily used, use of persistent connections may be required to achieve acceptable performance. In this case, you will need a well designed transaction that handles error processing to ensure no commits are left outstanding.


Database - Isolation Levels

Because the transaction isolation level determines how data is locked and isolated from other processes while the data is being accessed, you should select an isolation level that balances the requirements of concurrency and data integrity. DB2_I5_TXN_SERIALIZABLE is the most restrictive and protected transaction isolation level, and it incurs significant overhead. Many workloads do not require this level of isolation protection. We did limited testing comparing the performance of using DB2_I5_TXN_READ_COMMITTED versus DB2_I5_TXN_READ_UNCOMMITTED isolation levels. With this workload, running under DB2_I5_TXN_READ_COMMITTED reduced the overall capacity by about 5%. However a given application might never update the underlying data or run with other concurrent updaters and DB2_I5_TXN_READ_UNCOMMITTED may be sufficient. Therefore, review your isolation level requirements and adjust them appropriately.


Zend Platform

Zend Platform for i is the production environment that ensures PHP applications are always available, fast, reliable and scalable on the i platform. Zend Platform provides caching and optimization of compiled PHP code, which provides significant performance improvement and scalability.


Other features of Zend Platform that brings additional value, include:

  • 5020 Bridge - API for accessing 5250 data streams which allows Web front ends to be createdfor existing applications.
  • PHP Intelligence - provides monitoring of PHP applications and captures all the information needed to pinpoint the root cause of problems and performance bottlenecks.
  • Online debugging and immediate error resolution with Zend Studio for i
  • PHP/Java integration bridge

By automatically caching and optimizing the compiled PHP code, application response time and system capacity improves dramatically. The best part for this is that no changes are required to the take advantage of this optimization.

In the measurements included below, the default Zend Platform settings were used:


i 6.1 / DB2 i 6.1/MySQL 5.0
Zend Version V2.5.2 V2.5.2/Platform V2.5.2 V2.5.2
Connect db2_pconnect db2_pconnect mysqli mysqli
OPM 5041 6795 3974 4610
RT (ms) 176 129 224 191
Total CPU 98 95 98 96
CPU - Zend/AP 62 44 49 31
CPU - DB 31 46 47 62
1. In both cases above, the overall system capacity improved significantly when using Zend Platform, by about 15-35% for this workload. With each order consisting of 10 web requests, processing 6795 orders per minute translates into about 1132 transactions per second.
2. Zend Platform will reduce the amount of processing in the Zend Core component since the PHP code is compiled once and reused. In both of the above cases, the amount of processing done in Zend Core on a per transaction basis was dramatically reduced by a factor of about 1.9X.


PHP System Sizing

The IBM Systems Workload Estimator (a.k.a., the Estimator or WLE) is a web-based sizing tool for IBM Power Systems, System i, System p, and System x. You can use this tool to size a new system, to size an upgrade to an existing system, or to size a consolidation of several systems. The Estimator allows measurement input to best reflect your current workload and provides a variety of built-in workloads to reflect your emerging application requirements.


Currently, a new built-in workload is being developed to allow the sizing of PHP workloads on Power Systems running IBM I, This built-in is expected to be available November 2008.  

To access WLE use the following URL:


IBM has included PHP performance chapter in the Performance Capabilities Reference PDF 
Take a look at chapter 6 - section 6.2 "PHP - Zend Core for I"
IBM also added PHP sizing to Workload Estimator (WLE) 


Excerpt: IBM Power Systems Performance Capabilities

Original Post Date: 2009-10-23 14:09:18

External Links:

Performance Capabilities Reference PDF
Workload Estimator (WLE)
Workload Estimator

Alternative Description:

IBM Power Systems Performance Capabilities

Tags: BM Power Systems,i5,i5/OS,IBM,IBM i V6,performance,Performance Capabilities,WLE,Workload Estimator,Zend Core,Zend Core,Zend Core for i,Zend Platform,oldKB