Zend Platform on IBM I provides many benefits including monitoring and advanced debugging. One of the more confusing issues that customers face with Zend Platform on IBM i is the impact on development machines. Most will try out Zend Platform in a development environment or on a development LPAR. Once installed, you can hear the developers in a terrifying SHRIEK, what happened to PHP? In a word: caching. Everything is OK! This is a good thing and a little understanding will help tremendously! One of the many key features of Zend Platform is caching. You are familiar with caching, right? If not, check out the Wikipedia definition and send me a note for more details. In a nutshell, Zend Platform caches PHP scripts and content in a byte-code format to improve performance. This is an extremely useful feature, especially when you start exploring frameworks like Zend Framework or Cake. These frameworks are built on an OO model that includes or requires a significant number of standard libraries to achieve the uniformity that makes it so powerful. The action of executing the include function from a cached vs. non-cached script can really improve Web application performance.
Zend Platform has many dials and controls which affect caching on the IBM i. We are going to explore how a few of them work and shed some light on their purpose. But first, let us address the issue of I change my script, but the only way I can get the output to change is to restart the Zend Stack! Zend Platform for i5 comes installed with many performance features turned on as this helps the overall system performance. It is one of the reasons that Zend Platform has a minimal load on the standard IBM i at V5R4 or 6.1. DISCLAIMER: Performance tuning tends to be more of an art form than science. This article is intended to give perspective and not be the definitive authority on how i5 shops should manage performance. Proper research should be done well before implementing changes to production servers. The Zend Platform User Guide contains a great deal of information on how these functions work. Zend also provides a Zend Platform for System Administrators training course that can shed a lot more light on the equation.
QUICK TWEAK FOR MAXIMUM CLARITY
For the development environment we recommend turning off as much caching as you can tolerate. As you become more familiar with tuning your applications you will get more comfortable with what controls make sense for your organization. But to solve the initial pain point where scripts do not appear to be changing, log in to the Zend Platform Admin Interface. The login screen requests a user name and password. The credentials are unique to ZP and are not to be confused with your i5 credentials.
Once logged on to the Admin Interface, you should be presented with the dashboard. That will be an article for a different day. Select the Performance tab and then the Tuning subtab. On the Tuning page click the Advanced Options arrow. The very first box you see is most likely checked.
The title of this box might be a little confusing. Some negative logic may be in order to interpret this value. When unchecked, Zend Platform will examine the time stamp of each PHP script to see if the cached value matches the value of the script on the host server. If the values are the same, the cached script is used to facilitate the request. If the timestamps are different, ZP will purge the old copy from the cache and bring in a fresh copy of the script. This is what we call a compromise in performance. Keep in mind that while ZP needs to do a file I/O to get the time stamp, it is not a full I/O that swaps the entire script unless there is a change. So having this option checked will improve performance. But in a development environment the slight impact on performance is well worth it! As there are several levels of caching options, this is the first and most effective method for eliminating those shrieks from the developers and, in most cases, will be all you need to adjust. Please note that you need to restart Apache after changing this setting.
Now that we have alleviated the pain and suffering in the development group, let us look at some of the remaining Performance features of Zend Platform. These include Code Acceleration, Dynamic Content Caching and Code Compression.
Code Acceleration is a very neat feature that addresses several concerns regarding PHP performance that are both real and perceived. Code Acceleration is simply the process of executing the cached, pre-compiled, byte-code of the PHP script rather than interpreting the script on each call. Most i5 shops do not even need to be concerned about this since a majority of the transaction processing may never require this level of performance. However, some processes will benefit tremendously, such as frequently accessed pages and high volume transactions.
When Zend Platform is installed Code Acceleration immediately goes to work pre-compiling PHP scripts and optimizing them into byte code. This byte code executes the scripts without needing the parser each time the script is used. Access to the controls for Code Acceleration can be found on the same desktop as described above. These controls allow you to define which and how many files to accelerate, and how much to accelerate them.
DYNAMIC CONTENT CACHING
Dynamic Content Caching is a method by which the output of the PHP script is held in memory and used to facilitate multiple requests. This type of caching is very useful for static content that does not change frequently. A product specification page or company intranet might be a good example. Heavy business transaction processing and database queries would not be a good candidate for this type of caching.
You can control what types of files are cached via the Zend Platform Administrative Interface. Caching can be applied in a very granular method all the way down to a specific file or directory of files. This allows dynamic content to accelerate like static content. Just in case there is a need to refresh and purge all cached content, there is a button in the Zend Platform Administrative Interface that will dump the cache. This will allow Zend Platform to start caching all over again with fresh content from the server.
Code Compression is much more of a network benefit than server centric. This solution compresses the content generated on the server and then sends it across the network to the browser. Once it reaches its destination the browser can then uncompress and display the content. This is an ideal solution for folks who support remote users who have less than perfect Internet Service or slow speed lines. It is also handy for websites with a large amount of static content, as the compression feature can appear to accelerate the performance of the website. Code compression is turned off by default, and can be turned on selectively.
Each of these features can provide a very powerful performance boost to PHP based applications. For most organizations doing transaction processing with 100 users or less there may not seem to be a need for improvement. The initial settings are tuned so that, just like when the IBM i is turned on for the first time, folks rarely look at the performance features. That does not mean there is not an opportunity to improve, juts that you should be aware of the opportunities and the risks. Please research any changes to performance settings thoroughly before changing the settings in your production environment to avoid having a potentially negative experience cloud all the good things that performance tuning and Zend Platform can do.