views:

24

answers:

2

I have a home page that has several independent dynamic parts. The parts consist of a list of recent news from the company, a site statistics panel, and the online status of certain employees. The recent news changes monthly, site statistics change daily, and online statuses change on a per minute bases. I would like to cache these panels so that the db is not hit on every page load.

Is using ob_start() then ob_get_contents() to cache these parts to a file the correct way to do this or is there a better method in PHP5 for doing this?

In asking this question I'm trying to answer these additional questions:

  • How can I determine the correct approach for caching this data without doing extensive benchmarking?
  • Does it make sense to cache these parts in different files and then join them together per requests or should I re-query the data and cache once per minute?

I'm looking for a rule of thumb for planning pages and for situations where doing testing is not cost effective (The client is not paying enough for it I mean).

Thanks!

A: 

No, output buffering has nothing to do with database caching.

But the rule of the thumb is: leave all these things alone until the moment you realize that site really need some performance improvements.
Then do some profiling.
And, finally, go eliminate the bottleneck. Most likely it will be not these database calls.

Col. Shrapnel
Output buffering can be useful for caching rendered HTML. You render it once with database access, store the rendered HTML in a flat file, and future requests hit that flat file w/o needing to hit the DB.
ceejayoz
I have been caching the final html renderings of tables produced from db queries with output buffering. I was planning to serialize arrays received from a query into a file. Point taken on the wait till disaster method though, that is my default approach currently.
Tim Santeford
@Tim that's not "wait for disaster" method. That's "repair that's broken, not something random" method.
Col. Shrapnel
@ceejayoz that's template responsibility anyway, and still has nothing to do with database. And it is also 1000 times better to implement `conditional get` caching instead of this one.
Col. Shrapnel
@Col. Shrapnel conditional get caching is something I forgot to consider but wouldn't that only work well for when you have control over the host's proxy servers? This particular site will be hosted by dreamhost.
Tim Santeford
@Tim conditional get is just HTTP headers and nothing more. And PHP is good with it. Though 99% of sites runs well without it.
Col. Shrapnel
I think I get your point, although better caching strategies are those that are designed into an applications architecture and not just bolted on after-the-fact. There is certainly a balancing act here, you don't want to invest in a lot of infrastructure that is not really needed (possibly your point), but it's prudent to consider growth and/or the appropriate use of resources such as the database (possibly his point).
JoeGeeky
+1  A: 

Although not the best rule-of-thumb... In the absence of any clear requirements, I would let your SLA (desired, predicted, expected, or known) guide your strategy as a starting point. Generally, we all know where the slow or less-reliable links are. These may be down-stream systems, slow network links, slow database queries, transformations, etc... Thinking of caching as one mitigation to resources not being available, falling below SLA, or hampering the users experience is at least one prudent line of thinking. At a minimum you will certainly have to do some back-of-the-napkin calculations, but even lower fidelity numbers are a good start.

JoeGeeky
+1 good response. I had not considered using caching as an alternative to down resources.
Tim Santeford