tags:

views:

738

answers:

7
+3  Q: 

PHP page caching

Right now each time the page is loaded the php script is run regenerating the page. For pages like search this is fine, because most searches are different, but for other pages such as the index this is virtually the same for each hit, yet generates a large number of queries and is quite a long script.

The problem is some parts of the page do change on a per-user basis, such as the "You are logged in as..." section, so simply saving the generated pages would still result in 10,000`s of nearly identical pages.

So what I want to do is implement a 2 pass system: The first pass generates a PHP file, with all of the common stuff (eg news items), hardcoded. the database then has a cache table to link these with the pages (eg "index.php page=1 style=default"), the database also stores an uptodate field, which if false causes the first pass to rerun the next time the page is viewed.

The 2nd pass fills in the minor details, such as how long ago something(?) was, and mutable items like "You are logged in as...".

However I'm not sure on a efficient implementation, that supports both cached and non-cached (e.g., search) pages, without alot of code and several queries.

The 2nd pass on this generated file(?)

A: 

You want to save the results to a file and use logic like this to pull them back out:

if filename exists
    include filename
else
    generate results
    render to html (as string)
    write to file
    output string or include file
endif

To be clear, you don't need two passes because you can save parts of the page and leave the rest dynamic.

Oli
+3  A: 

For server side caching use something like Cache_Lite (and let someone else worry about file locking, expiry dates, file corruption)

Ken
+4  A: 

I recommend to don't reinvent the wheel... there are some template engines that support caching, like Smarty

Jochen Hilgers
I don't see how this fullfills any of my needs, since the cache a-seems to be defined by a lifetime, this has no relevance on my site and b-doesn't allow commonly changing parts (eg user name) to be updated for each request, without rebuilding the entire page...
Fire Lancer
+5  A: 

I second Ken's rec of PEAR's Cache_Lite library, you can use it to easily cache either parts of pages or entire pages.

If you're running your own server(s), I'd strongly recommend memcached instead. It's much faster since it runs entirely in memory and is used extensively by a lot of high-volume sites. It's a very easy, stable, trouble-free daemon to run. In terms of your PHP code, you'd use it much the same way as Cache_Lite, to cache various page sections or full pages (or other arbitrary blobs of data), and it's very easy to use since PHP has a memcache interface built in.

For super high-traffic full-page caching, take a look at doing Varnish or Squid as a caching reverse proxy server. (Pages that get served by Varnish are going to come out easily 100x faster than anything that hits the PHP interpreter.)

Keep in mind with caching, you really only need to cache things that are being frequently accessed. Sometimes it can be a trap to develop a really sophisticated caching strategy when you don't really need it. For a page like your home page that's getting hit several times a second, you definitely want to optimize it for speed; for a page that gets maybe a few hits an hour, like a month-old blog post, it's a bad idea to cache it, you only waste your time and make things more complicated and bug-prone.

joelhardi
A: 

I would recommend using existing caching mechanism. Depending on what you really need, You might be looking for APC, memcached, various template caching libs... It easier/faster to tune written/tested code to please your need than to write everything from scratch. (usually, although there might be situations when you don't have a choisce)

f13o
A: 

As always with this type of question, my response is:

  • Why do you need the caching?
  • Is your application consuming too much IO on your database?
  • What metrics have you run?

Your are talking about adding an extra level of complexity to your app so you need to be very sure that you actually need it.

You might actually benefit from using the built-in MySQL query cache, if the database is the contention point in your system. The other option is too use Memcache.

Toby Hede
A: 

@tobyhede, wouldn't fit as a comment/

The main concern is with reducing the load on the server, since I'm on shared hosting and at this point can't afford to upgrade, but the site is using a sizeable portion of the servers CPU + putting a fair load on the mysql server.

So basicly minimising how much has to be done for each page request, and not regenerating stuff like the news items on the index all the time seems a good start, compared to say search which is a far less static page.

I actauly considered hard codeing the news items as plain html, but then that means maintinng them in several places (since they may be used for searhces + the comments are on a page dedicated to that news item (ie news.php), etc)

Fire Lancer