I would love to say that all PHP applications execute flawlessly. The reality is that even the best RPG application will occasionally throw an escape message so why should PHP be any different? In my years with Zend I have seen a number of issues both large and small. Here I will discuss a handful of those problems I had distilled into a presentation called “Interesting Stories with PHP and IBM i.” In the first slide of the presentation I jokingly refer to the fact that I have changed the names of the players to protect the innocent. I will try to focus only on issues with clean resolutions in both Zend Server and Zend Server CE.
Typically, we can break the types of issues we see into three categories: Performance, Configuration, and Coding. Ironically, the support team at Zend is really only in a position to address configuration issues. But sometimes they’ll take a swing at “basic” performance issues when possible.
Let’s attack Performance issues
One customer complaining about performance was able to see immediate improvement simply by clipping the PHP log file. You see, each time PHP generates an error or warning, a process has to go to the ROOT file system of the IFS, open a file, write a record, and close the file. Because of the superior features of IBM i these types of accesses to the file system tend to be slightly expensive in performance. Have you ever opened a very large file via WRKLNK and seen the system take a long time to process the request? A quick improvement is to rename the php.log file in /usr/local/zendserver/var/logs. I usually change it to something with a time stamp like php-20121031.log. Don’t worry about the file. When Zend Server needs to write the next message it will automatically create a new file. This has no affect on the messages in the Event Monitor of the full Zend Server product and can even be automated via a CL program. Depending on the usage of the applications and frequency of messages a weekly process or monthly might do nicely. Some folks are so busy that they turn the log files daily.
Many other performance issues actually occur because folks have busy machines and need to tune the workload accordingly. One customer complained to me once that his Zend Framework application ran faster on his Linux machine than on IBM i. while this is not an unrealistic scenario I asked him how many users he had on his IBM i and how many he had on the Linux box. He indicated about 5,000 user on the IBM I and only 2 user on the Linux machine. I told him that when he gets to 5,000 user on the Linux server to take some fresh readings on performance and get back to me. But seriously, companies should compare apples to apples as IBM i has a very special value proposition when running PHP workload.
The environment around PHP on IBM i is centered on three subsystems, QHTTPSVR, ZENDSVR and QSYSWRK. When troubleshooting performance problems it is always a good idea to check into things like memory pooling and also a new feature of IBM i called “workload partitioning”. Memory pooling is a method of organizing the memory on your IBM i by subsystem so that a “runaway” process in one subsystem does not steal RAM from the other subsystems. Workload partitioning gives you similar controls for processor management between subsystems. Managing memory and processor between subsystems is an entire discussion on its own so I will not go into it here. Hopefully this mention of the concept will be enough to raise awareness that can dramatically influence performance of the web applications running natively on IBM i.
What version of the OS are you running? I had one customer who was so concerned about the performance of their PHP applications that they had scheduled a hardware upgrade. In preparation for the hardware upgrade they upgraded the OS to IBM i 7.1. This jump from V5R4 to i7.1 added major enhancements to the query optimizer and tools for diagnosing bottlenecks in SQL requests. Within 24 hours of installing i7.1 they had the PHP applications jumping through hoops and postponed the hardware upgrade. Certainly IBM would not mind if you throw hardware at a problem, but it is usually not the ONLY answer. Like voting in Chicago, install PTFs early and often! There are amazing things coming through the Technology Refresh process and you can’t get that on V5R4!
Cache is King!
Another trick for improving performance is to use Caching whenever possible. Caching can done at three major levels: script cache, data cache and page cache. While all three are built in to the full Zend Server product, the script and data cache are also available in the Community Edition. We’ll talk about the script cache first and then dig into the data cache as both of these can have a VERY significant impact on PHP workload on IBM i
The script cache in Zend Server is part of the Zend Optimizer. Let’s take a look at the process of running a PHP script and then see how the Optimizer can impact it. When a user requests a PHP script by clicking a link or typing a URL request into a browser a request is sent to Zend Server. At that point, Apache and Zend Server work together to retrieve the PHP script out of the root file system of the IFS. As I indicated earlier, this can be a relatively expensive process when looking at performance. Once the script is pulled into Zend Server, the code is scanned and common routines are replaced with high performance routines. This is the optimization step and happens for every script that the PHP stack touches. Then the optimized code is “parsed” and turned into op-code. It is this op-code that gets executed by Zend Server PHP to create the response for the end user. When the script completes, the code is thrown away and the process starts all over again for the next PHP request. Imagine a page getting requested frequently, you can start to see how the constant reprocessing of the script could become a waste of time. So here comes the op-code cache. In the Zend Server admin interface the controls for the op-code cache can be found under Server Setup à Components à Zend Optimizer+. The default factory setting for this value is 2 seconds but many companies will increase that to a very significant value as they rarely make changes during the day. If a change to a production script needs to be brought into Zend Server, an administrator need only click the “clear” hyper-link next to the component listing and the op-code cache will immediately get dumped and start rebuilding.
Just like we did for the op-code cache, there is also a data cache. The idea behind the data cache is for frequently access lists of data to be stored in memory. The data cache will intercept the request for data that is stored in the cache and serve it directly out of memory rather than going to DB2. Think of some fairly common lists of information that rarely change. Lists like the number of warehouses in a company along with their descriptions. Some ERP systems use a Warehouse code almost everywhere. The data cache is VERY granular in that is can be used to cache each element in an application separately. This delivers a lot of power as each element can have its own expiration interval. Static content like the states of the union could be cached for 8 hours while more dynamic numbers like YTD sales could be cached for 15 minutes.
Lastly is the full page cache feature of the full Zend Server. The page cache takes the entire output of a given page request and serves it out of memory. This is great for company intranet applications where the content rarely changes but is accessed by many folks throughout the business day. There are many features available to the full page cache such as individual page or application cache intervals, dynamic controls based upon session, cookie or method state. Also, while the data cache obviously requires coding to take advantage of its performance enhancing goodness, the page and script caches do not require code enhancements. This means you can download and install open source applications like Drupal and Joomla to run your company intranet and start caching pages almost instantly.
Performance is always more about art form than science, but a wise assessment of the application can yield opportunities for improvement that can save hours of CPU capacity over the course of a business day.