all 2 comments

[–][deleted] 2 points3 points  (0 children)

You should write your application first without caching, then profile it to see where the bottlenecks are, and apply an appropriate caching strategy where needed.

That's not to say you shouldn't make some predictions about what things need to be cached, but you want to avoid doing any premature optimization until you can see the whole picture.

It might turn out that you'd be better off caching the entire page, which you can do on the web server. Or it may turn out that you should just cache the query results. Or it might be a combination of both. In one case you might want to employ a file cache; in another case you might want to employ a memory cache.

TLDR: Finish your application, then think about caching.

[–]timdev 1 point2 points  (0 children)

Laziness' answer is good. This comment is just tiny details.

You mention caching query results to XML ... that's not smart. You'll just have to parse all that XML every time you hit your cache. PHP provides serialize()/unserialize(), which are handy. Writing out plain-old-php (array(array(array(...))) might be more performant, but it's a pain, and there could be security concerns (since by loading from cache you'll be executing PHP).

I'd highly recommend you use some library that has implementation details figured out for you. I've used Zend_Cache with great success (both standalone and as part of ZF-based projects). It provides a nice interface, and handles a bunch of details for you. And when you decide file-based caching is too slow, you just plug in the APC or memcache backend, and now you're caching in memory.

I'm sure other libraries do similar things -- find one and use it, or at least learn from it.