How do I choose what and when to cache data with ob_start rather than query the database?

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 pe开发者_如何学Gor 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).

---

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.

---

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.