24.1. Caching PHP-Nuke

As in How to accelerate PHP-Nuke, we ask ourselves the following questions:

• Does your index.php, or the other parts of your PHP-Nuke change more often than, say, once in 15 minutes? Maybe not, if you are not logged in.

• Do you really need to see a change the very moment you hit the reload button of your browser? For me, if this change is the number of private messages I got, then I might be interested to see the *real* number. But then again, why not the number as of 5 minutes ago? How important is current content for you? How current is current enough for you? 1 minute, 5 minutes, or even 15 minutes?

If you think a little about it, you will realize that maybe it is not absolutely necessary that your PHP-Nuke does all these conections to the database, querying all that data that most probably did not change the last x minutes, each time you display a page.

Various tests on optimizing PHP (see, for example, Optimizing PHP) have shown that the biggest time savings in execution time are not achieved through elaborate algorithmic optimization, but rather with an old, well-known technique: caching! The idea behind caching is to avoid repeated execution of the PHP code, by storing the HTML output in a file, as jpcache (Section 24.1.1) and Cache-Lite (Section 24.1.2) do, or in shared memory, as Turck MMCache (Section 24.1.3) does. Optimizers, such as the commercial Zend Performance Suite and the free Turck MMCache, transform the PHP code in an intermediate form, an "opcode" , which they cache - Figure 24-2 shows the way these optimizers work. In the following we will examine them in more detail.

Know what you cache and why!

If you try to cache the whole index.php page even for registered users, you shouldn't be surprised of the errors and you shouldn't blame it on cache. The cache will just cache what you tell it to, for the time intervall you tell it to. Now, suppose that your users get different output on your index.php page, depending on your settings as an administrator (blocks, modules etc.) and their settings as users. Also suppose that you use a caching mechanism, like the ones we will describe later in this chapter, to cache the whole index.php page. Then we can easily imagine a situation where your user A will not get to see what he should see, but what user B was viewing a few minutes ago. In other words, all users will see user's B cached index.php page, with all the wrong links in it, like "Your Account" with user's B data in the link etc. For this reason, it is absolutely necessary to know what you cache and why you cache it!

	What to cache for registered users
	If you want to cache content when it is viewed by registered users too, it will make more sense to cache only individual modules or blocks which (see Caching strategy with PHP-Nuke) take much time to build their content and their content is independent of the user viewing it.