Applies To:
[ Zend Core V2.x ]
[ IBM System i ]
Preface
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.
Details
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 |
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:
|
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_pconnect |
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 |
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:
|
OS / DB |
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 |
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: http://www.ibm.com/eserver/iseries/support/estimator:
Take a look at chapter 6 - section 6.2 "PHP - Zend Core for I"
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
Comments