8

I don't really have any experience with caching at all, so this may seem like a stupid question, but how do you know when to cache your data? I wasn't even able to find one site that talked about this, but it may just be my searching skills or maybe too many variables to consider?

I will most likely be using APC. Does anyone have any examples of what would be the least amount of data you would need in order to cache it? For example, let's say you have an array with 100 items and you use a foreach loop on it and perform some simple array manipulation, should you cache the result? How about if it had a 1000 items, 10000 items, etc.?

Should you be caching the results of your database query? What kind of queries should you be caching? I assume a simple select and maybe a couple joins statement to a mysql db doesn't need caching, or does it? Assuming the mysql query cache is turned on, does that mean you don't need to cache in the application layer, or should you still do it?

If you instantiate an object, should you cache it? How to determine whether it should be cached or not? So a general guide on what to cache would be nice, examples would also be really helpful, thanks.

Joker
  • 1,133
  • 7
  • 18
  • 22

2 Answers2

10

When you're looking at caching data that has been read from the database in APC/memcache/WinCache/redis/etc, you should be aware that it will not be updated when the database is updated unless you explicitly code to keep the database and cache in synch. Therefore, caching is most effective when the data from the database doesn't change often, but also requires a more complex and/or expensive query to retrieve that data from the database (otherwise, you may as well read it from the database when you need it)... so expensive join queries that return the same data records whenever they're run are prime candidates. And always test to see if queries are faster read from the database than from cache. Correct database indexing can vastly improve database access times, especially as most databases maintain their own internal cache as well, so don't use APC or equivalent to cache data unless the database overheads justify it.

You also need to be aware of space usage in the cache. Most caches are a fixed size and you don't want to overfill them... so don't use them to store large volumes of data. Use the apc.php script available with APC to monitor cache usage (though make sure that it's not publicly accessible to anybody and everybody that accesses your site.... bad security).

When holding objects in cache, the object will be serialized() when it's stored, and unserialized() when it's retrieved, so there is an overhead. Objects with resource attributes will lose that resource; so don't store your database access objects.

It's sensible only to use cache to store information that is accessed by many/all users, rather than user-specific data. For user session information, stick with normal PHP sessions.

Mark Baker
  • 209,507
  • 32
  • 346
  • 385
  • 4
    @Joker Just as a little addon, Incase you don't already know, APC provides 2 type of cache, an opcode cache used by php internally to 'make it faster', and the user cache which you can use to store data. The user cache is part you are going to need here. (apologies if this is teaching people how to suck eggs - but hopefully it might useful to others who come across this question) – James Butler Feb 02 '11 at 12:27
  • Yea, I'm aware of the opcode cache which just works automatically if you have apc enabled. When you say you should test to see if queries are faster read from the database or cache, how would I go about testing this? And when should I be caching just regular data? For instance my foreach loop example. – Joker Feb 02 '11 at 17:27
  • @Joker - The way to test is to actually try it (using both methods) and measure the times... there's no absolute math that can tell you in advance, although using EXPLAIN on your database queries might give a few hints. Remember that you should always ensure best indexes on your database anyway. Nor is there any "hard and fast" rule for your loop example... it's something that has to be assessed on a case by case basis. All I can say is "don't cache just for the sake of caching", only do so when there is a real, measurable benefit. – Mark Baker Feb 02 '11 at 18:48
  • I was actually wondering how exactly to measure the times. For example, do you simply run microtime before and after and find the difference? – Joker Feb 02 '11 at 23:12
  • 1
    @Joker - that would be one approach, and I do use that myself... but I prefer to use Apache Benchmarking, which allows me to simulate concurrent accesses, and provides a much more comprehensive set of time statistics. (http://httpd.apache.org/docs/2.0/programs/ab.html) – Mark Baker Feb 02 '11 at 23:15
0

The simple answer is that you cache data when things get slow. Obviously for any medium to large sized application, you need to do much more planning than just a wait and see approach. But for the vast majority of websites out there, the question to ask yourself is "Are you happy with the load time". Of course if you are obsessive about load time, like myself, you are going to want to try to make it even faster regardless.

Next, you have to identify what specifically is the cause of the slowness. You assumed that your application code was the source but its worth examining if there are other external factors such as large page file size, excessive requests, no gzip, etc. Use a site like http://tools.pingdom.com/ or an extension like yslow as a start for that. (quick tip make sure keepalives and gzip are working).

Assuming the problem is the duration of execution of your application code, you are going to want to profile your code with something like xdebug (http://www.xdebug.org/) and view the output with kcachegrind or wincachegrind. That will let you know what parts of your code are taking long to run. From there you will make decisions on what to cache and how to cache it (or make improvements in the logic of your code).

There are so many possibilities for what the problem could be and the associated solutions, that it is not worth me guessing. So, once you identify the problem you may want to post a new question related to solving that specific problem. I will say that if not used properly, the mysql query cache can be counter productive. Also, I generally avoid the APC user cache in favor of memcached.

Sameer Parwani
  • 309
  • 1
  • 7