PHP Page Caching

[mikesmith76]

Hi all,

I'm currently in the process of building a website with a dynamic navigation menu. This menu is a list of categories a user can click on to view items related to that category. Both the categories and the items are stored in a MySQL db. The items will be changing frequently, however the categories may not change for months at a time (if at all). The categories need to be in the database to link the items to them.

To actually build the navigation menu is going to take 2 db queries per page load, to deal with categories and any sub categories. This is obviously a complete waste of resources and I am looking at caching the generated menu and recreating it periodically to take into account any changes.

I'm thinking about creating my own caching class(es) to take care of this for me, however i'm unsure how to handle access to the page cache. How can i stop someone accessing the cache while it is being recreated? can the php function flock be relied upon to give an exclusive lock on a file? For those of you that have implemented similar solutions how did you resolve these issues?

Thanks for any help you can give

Regards
Mike

[steve0]

check out
http://turck-mmcache.sourceforge.net/index_old.html
or
http://eaccelerator.net/

[mikesmith76]

Just had a look at the two mentionned, they both seem to be "all or none" caching, i'm looking at selectively caching parts of a page. I'm also looking to create a custom caching system, for educational purposes as well as the application mentionned above. Does anyone on here implement caching on their site using their own code?

[speed]

Does anyone on here implement caching on their site using their own code?

Yes.

Within our directory script we build the category pages leaving markers where dynamic content such as ads go. This semi complete page is then stored in the database.

One query gets the page leaving just the dynamic content to be populated. You could store the data in the file system if you prefer.

Pages are dropped from the cache when their content changes in some way. The next time the page is viewed the page is rebuilt and cached, this lazy caching saves waiting for several thousand pages to rebuild.

The directory script tries to limit the number of pages that are dropped from the cache due to a change, it will try and just drop the changed page and it's parents leaving it's siblings cached. This is somewhat specific to the structure of a directory compared with what you are trying to do.

How can i stop someone accessing the cache while it is being recreated? can the php function flock be relied upon to give an exclusive lock on a file? For those of you that have implemented similar solutions how did you resolve these issues?

flock should be fine. You might want to benchmark some tests though because if you lock too much you could find it becomes slower under load than running the queries.

We chose to store the data in the database because it makes it easy to distribute to multiple front end web servers, as and when the need arises. It also saves worrying about flock etc as the database does that for you.

Also we don’t worry if a page is regenerated for the cache by 2 visitors looking at it at the same time, one will overwrite the other, yes it wastes some time but it saves a table lock thus allowing other pages to continue to be used, generated and cached in parallel.

mmcache and eaccelerator are basically the same product just eaccelerator is the continued development. There's an option to use its extensions to store blocks of data into its cache. However you still need your own code to create the page, build the data to cache, put the data in the cache and to restore and paint the cached data.

From memory I don’t think they offer persistent caching but rather after some time frame cached objects are deleted, therefore this might not be the best solution for caching pages.

Is it worth the effort to save 1 or 2 queries per page? Probably not. If you have that amount of traffic that saving 2 queries is important then maybe you should:

a) Look to see if you can optimise the database, maybe create a secondary table or index so that a single query can retrieve all the data.

b) Place a reverse proxy cache in front of apache, http://www.visolve.com/squid/whitepa...verseproxy.php

Be careful of over optimising.

[mikesmith76]

speed, thanks for the detailed reply. The website is under development at the moment and upon launch probably won't have many visitors. I know that it seems excessive to build a caching system to save on two queries per page load, and your probably right. However here is my reasoning.

We have our own dedicated server for hosting websites we develop. My thinking was if a large number of these sites all have a few queries running per page load it's not going to take long before we have a large amount of simultaneous database connections, and most of these may be pulling out unchanged data. Seems a bit of a waste of resources.

I agree about benchmarking my code before implementing anything, and i'm in the process of searching for some good benchmarking tools. What do you commonly use? I'm not looking for anything fancy, just finding out how long a chunk of code takes to execute so i can run comparisons.

once again thanks for your help

[speed]

I usually use ab to get a feel along with Zend Studio Pro.

If you are pulling any other data from the database then you will have the connection already therefore the 2 queries for the menu are probably not note worthy.

However if they are your only queries then it would be easiest to create a script to dump the entire site in plain .html to the public_html folder.

Then manually trigger rebuilds when you need it, saves the overhead of the code to maintain the cache at runtime and also as the files are plain HTML it removes the overheads associated with running PHP.

Sometimes though throwing a bigger server at the problem makes for a simpler system which is easier to maintain.

We have our own dedicated servers and virtually all our/client sites are database driven, shops, directories and so on, we’ve never had a problem with database connections.

[mikesmith76]

thanks again, guess i'll just develop the caching code for educational purposes :-)