Section 14.8. Using ZPS (Zend Performance Suite)

14.8. Using ZPS (Zend Performance Suite)

ZPS is a commercial product from Zend.com. ZPS provides tools for

Automatic Optimization. By using the Zend Optimizer (http://www.zend.com/store/products/zend-optimizer.php), you can improve your performance by 20 percent without making any code changes.
Compiled-code Caching. By using the Zend Performance Suite's Acceleration module (http://www.zend.com/store/products/zend-performance-suite.php), you improve performance by 50300 percent, and sometimes even more for most applications.
Content-Caching. When using the Zend Performance Suite's Content-Caching module, you can receive an enormous performance boostand literally reduce the execution overhead of your application to zero. Performance boost of 10,000 percent (100 times faster) are not uncommon with this practice.
Content Compression. Although being slightly different from all the aforementioned methods, compressing your content (typically the HTML parts of it) can result in your application appearing to perform faster and be more responsive because pages will take less time to transmit over the wire.

14.8.1. Automatic Optimization

To understand Automatic Optimization, you first should understand the execution architecture of PHP and the Zend Engine. Consider the following example:

 <?php $i = 5; $i++; ?>

How does PHP execute it? In practice, PHP employs a two-stage execution architecture. The first stage is compiling the source code into intermediate code, and the second stage is executing the intermediate code. What does intermediate code look like? If you are familiar with Assembly, intermediate code would look slightly familiar. It consists of relatively simple operations, which have a result and up to two operands. For instance, the intermediate code for the previous example is going to look more or less like this:

`1`	`ASSIGN($i, 5)`
`2`	`T1 = $I`
`3`	`INC($i)`

First, 5 is assigned to $i, then to the value of $i before the increment is retained in T1, and finally $i is incremented. But waitno one is using T1 _;isn't it a waste of time retaining it? The answer is yes, and this is exactly where Automatic Optimization comes into the picture.

The Zend Optimizer (a part of the Zend Performance Suite, but also available for free from Zend.com) works by analyzing your application's intermediate code, and replacing inefficient patterns with more efficient patterns that do the same thing. In our case, it would detect that post-increment is not really necessary, and replace it with pre-increment. In other words, it would get rid of Line 2, and the resultant code would look like this:

`1`	`ASSIGN($i, 5)`
`2`	`INC($i)`

Note that using the Zend Optimizer does not make any changes to your source code; the process happens in memory, and only operates on compiled, intermediate code. The biggest issue with automatic optimization is that typically it cannot yield more than 20 percent performance improvement, and in many cases, even much less. For that reason, automatic optimization should typically be complemented by additional performance improvement measures, such as compiled code caching.

14.8.2. Compiled Code Caching

The Zend Performance Suite's Acceleration module, which performs compiled code caching, is the simplest and often the most effective way to speed up your application. To understand what Acceleration does, we first need to go back to the execution architecture of the Zend Engine. In the previous section, you saw how the engine first compiles your PHP files into in-memory representations (intermediate code), and then executes. But then what? What happens when the engine is finished executing some piece of intermediate code?

The answer is almost nothing. That is, nothing special happens with the intermediate code; it simply becomes unallocated and destroyed. The next time the same script will be accessed, it will be compiled again into intermediate code before it's executed. This approach has several advantagesit features perfect isolation across different requests, low memory footprint, and perfect cross-platform compatibility. However, when using PHP to power a popular web site with millions of page views a day, repetitive compilation can become a bottleneck.

In order to boost performance, the ZPSs Acceleration module caches compiled intermediate code for repeated use. When installed, the ZPS replaces the compilation procedure of the Zend Engine with a modified one; the first time each file is accessed, the regular compiler is invoked. However, before the resultant intermediate code is passed to the execution engine, it is saved into shared memory for repeated later use. Once in shared memory, it is passed on to the execution engine, which runs it as if it was in regular memory. Later, accesses to the same file will no longer require the compilation stage, and will move directly to the execution stage. It's important to know that the ZPS saves each file separately, even if it is included from another file. That means that common include files (such as PEAR, or your own library files) are only kept in memory once, and are used by any piece of code that needs them.

Typical benefits from using the ZPS's acceleration module range between a 50300 percent performance increase. The results depend primarily on the nature of your application. Applications with longer execution overhead (for example, applications that spend most of their time waiting for the database to respond) benefit less from the nullification of the compilation overhead. On the other hand, applications that use a lot of files but have relatively short execution overhead (for example, OO applications with one class per file) can experience dramatic performance increase. Furthermore, the Zend Optimizer automatically detects the presence of the Zend Performance Suite, and performs more aggressive and time-consuming optimizations, which would otherwise make little sense to perform. The fact that the each file only has to be optimized once and then used many times, combined with the additional optimizations, further increases performance.

The ZPS Accelerator typically requires little configuration, if any. The default settings fit most web sites. However, you may want to increase the amount of available memory or the maximum number of accelerated files, for which you can use the ZPS Console (or Settings) tab (see Figure 14.12).

Figure 14.12. Zend Performance Suite Console.

14.8.3. Dynamic Content Caching

Dynamic content caching is by far the most effective way to boost performance, in the cases where it is applicable, because it eliminates both the compilation and execution overhead of your application. In simple terms, content caching means saving the results of your application, typically HTML content, and then sending it out as-is again when another request comes along that asks for the same page. With dynamic content caching, improvement ratios of 10,000 percent (100 times better performance) are not uncommon. The downside is that it's not applicable for all PHP pages.

First, you have to become familiar with the concept behind caching dynamic content. Imagine a news site, such as cnn.com. Is there any reason for CNN to generate this page from a database each time a user accesses it? Wouldn't it be a better idea to create the page once, and then use it for some time? Even if a web page needs to be updated up to the minute (which cnn.com does), on a web site with thousands of requests per second, one minute can mean tens of thousands of requests, which can be served off the cache.

You need to follow two steps to take advantage of content caching:

You must realize which parts of your application can take advantage of it.
You need to define the content caching dependencies for each of your pages.

Realizing which pages can be content cached can be more challenging than you think. For example, while cnn.com's front page appears to be a perfect candidate for content caching, things like personalization can complicate matters. When it comes to determining which pages of your application can use content caching, there's no replacement for knowing the semantics of your application inside out.

That said, you can use these guidelines when trying to decide whether a certain page can benefit from content caching:

Is this page likely to render in exactly the same way across long periods of time? If the answer is yes, it may be a good candidate for content caching. Note that the meaning of "long" is relative in this context; as previously illustrated, one minute can be considered a long time, and an hour an eternity.
Does this page render differently for different users? If the answer is yes, typically this page is not a good candidate for content caching. This is a rule of the thumb, thoughif the number of users accessing the page is small enough and yet you expect them to access this page repeatedly, it may still benefit from content caching.
Does this page render in exactly the same way over long periods of time, but has a small personalized portion inside it? If so, this page is likely to be a good candidate for partial-page or exclusive caching.

Once you find a page you wish to content cache, you need to define several things (see Figure 14.13):

The page's TTL, or Time To Live. The TTL is the maximum period of time during which a cached copy of the page will be used. After that time, the cached copy is discarded, the page is executed over again, and a new cached copy is generated.
The page's dependencies. Almost all pages depend on GET input. That is, read_article.php?article_id=7 is likely to create a completely different page than read_article.php?article_id=7&page=2 or read_article.php?article_id=5. In addition, many pages may depend on cookie variables (such as whether the user is logged in or not), server/browser variables (such as the browser type or the preferred language) or session variables.

Figure 14.13. Defining caching conditions in the Zend Performance Suite.

In some cases, full-page caching for all the different permutations of a given page is impractical. In such cases, you still might be able to use two methods in order to benefit from dynamic content caching. One is partial caching, and the other is exclusive caching.

Partial caching allows the use of content caching in pages that cannot be fully cached. For example, if your page has a personalized header and footer but the bulk of the content looks the same for all users, you can use the ZPS's partial caching API functions to save the cacheable parts but let the personalized parts of the page execute normally. The result would be eliminating the overhead involved with the bulk of the page, without harming personalization. The drawback of this method is that it involves changes to your application's code, which many developers prefer to avoid.

The other alternative, exclusive caching, has to do with statistics. On many web sites that offer personalization, it turns out that many of the users don't actually log in, personalize, and view the page in its default settings. Typical ratings range between 5080 percent of the users who don't bother to log in. If your web site adheres to these statistics, exclusive caching may be for you. With exclusive caching, instead of caching only the parts of the page that look the same for all users, the page is cached in its entirety. The trick is that the cached copy is only used if the user is not logged in and the default web page is requested. If the ZPS detects that the user is logged in, it executes the page normally, without using any cached data. By using this method, you can achieve ''perfect'' content caching for 5080 percent of your page views, without making any modifications to your code. Figure 14.3 shows an example for exclusive caching settings; with these settings, the page is served off the cache only if the Logged_In cookie is not present.

14.8.4. Content Compression

Compression of HTTP pages is one of the best-kept secrets of the web. Few people know that, but literally all the major browsers today are capable of working with compressed content, decompress it on-the-fly, and show it as if it was uncompressed. If properly implemented, the use of content compression can result in the reduction of around 90 percent of your HTTP traffic, while both saving bandwidth and improving the experience of users over slow links.

Unlike other types of performance boosting, content compression actually demands more of the server. Because compression is an expensive operation, in terms of overhead, it doesn't always make sense to use it in conjunction with PHP applications. Sometimes, especially if most of your users access your application over fast links, the overhead involved with compression will most probably result in an overall decrease of performance; the time it takes to compress the page will be longer than the time saved sending the data.

However, the Zend Performance Suite provides a unique solution that combines the power of dynamic content caching with that of content compression. The ZPS allows you to enable content compression selectively, only for the pages that are served off the cache (see Figure 14.14). When using this feature, the ZPS keeps two copies for each cached page: one that is plain text, and one that is compressed. The ZPS automatically detects whether the connecting browser is capable of understanding compressed content, and serves the correct copy accordingly. That way, the overhead involved in on-the-fly compression is avoided, and you can enjoy the benefits of content compression without incurring the penalty of increased CPU utilization.