Dynamic content caching is by far the most effective way to boost perfor-
mance, in the cases where it is applicable, because it eliminates both the com-
pilation and execution overhead of your application. In simple terms, content
caching means saving the results of your application, typically HTML con-
tent, 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 mat-
ters. 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, though–if 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 differ-
e n t p a g e t h a n r e a d _ a r t i c l e . p h p ? a r t i c l e _ i d = 7 & p a g e = 2 o r
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.

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 cach-
ing, 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 personal-
ized 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 50­80 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 50­80 percent of your page views, with-
out 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.