Use of caching for a large site...?

[vaaaska]

I started to post this into Coding and I realized it might not fly as I have no code...it's here...otherwise. Please move it if I'm off.

I'm trying to wrap my brain around caching. The best method I know of is to create hard files that will be called into action as needed (assuming the server setup allows this). What I'm not so sure about is how well this works caching a huge site (let's say 5,000 pages with plenty of traffic).

Is there another way to cache other than creating all these 'temp' files?
Is there some magical number where it doesn't make sense (and it should probably just be done with straight up html pages)?
Is there a best practices method for naming conventions with cached files?
As a backup to caching, is there some other method for achieving the same thing (besides just querying the database)? And in PHP4 (not 5).

I've read plenty of tutorials regarding caching, but per the usual they only go so far. Might there be a good book that could help me through on this one?

I guess I have another question...is caching really even necessary given that servers are getting faster and more powerful and I should just let the database get called a mess of times every time a page is called and hope it doesn't buckle?

Sorry, I shouldn't post this in this state, but I'm going to anyway. 😉

Merci...v

[bubblenut]

There are a number of ways at looking at the problem of caching. They tend to fall into two broad categories. Output caching (what you appear to be talking about here) and Object caching.

With Output caching you render the output and then cache this as a chunk (or several smaller chunks, depends how modular your design is). This is usually done with flat files as the output can be quite large. Generally too large to cache in memory. This is not allways the case, if there is an output module which is highly changeable, small and often used then it is sometimes wise to cache this in memory (an example which I have personal experience with are 10 ten charts on a music retail site). In terms of convention for cache files, I don't really know. I would say that having the name of the item being cached in the name is essential. Smarty does this with what looks like an md5 hash string. The only thing difficult with output caching of whole pages is it becomes very difficult to know when elements within a page have changed since it was cached if there are many, unrelated modules within the page. I have the birth of an idea for a "cach-stack" stored which is then traversed when an item is changed so that all caches involved are cleared. This is more related to object caching though really. What a nice link into the next paragraph 😉

Object caching, although the name suggests it, is not solely related to objects. The term is used to define structured "chunks" of data which have some meaning, prehapse a product or a blog entry. As retrieving the data is usually one of the most significant bottleknecks it is often wise on high load sites to cache some of these objects in memory. There are a number of tools which achieve this, some transparently and some with a little effort by yourself. MySQL query caching can be a great benifit and requires no code changes. Basically, when a query is run it, and it's resultset is put into a cache, if it's already in there it get's moved to the top of the stack. This means that uncommen and user affected (I mean search boxes, I'm not suggesting you allow users to enter SQL directly) queries drop off the cache very quickly while more common queries (that top 20 chart on every page) get served incredibly fast.Another option is a technology called memcached developed by danga (the people who created live journal), there is a PECL module for it which makes life a little easier. This is a distributed cache and is therefore all the more usefull if you've got multiple servers although still very relevant if you only have the one. It's basically shared memory, you add an object into memcache with a key and then you can retrieve it at a later date. Kind of like a stripped down database. Very simple concept but very usefull. The really great thing about memcached is the distributed part. Where I work we have 12 webservers (about 25 machines in the web cluster in total but let's just stick with the actual webservers). Let's say we have 2Gb of RAM on each machine, 1Gb of which we'd like to set aside for caching. If we set up a caching model which is not distributes we have seperate 1Gb caches each storing pretty much the same data. If, on the other hand, we use a distributed model, all of a sudden we have 12Gb of space available in memory. We have so much room that not only can we cache almost our entire product catalogue natively as serialized PHP objects bu we can also start playing around with output caching modules left right and center in memory!

In short, I like caching, I think caching's very cool and I think everyone should take the time to develop a caching model which suits their needs best.

[bubblenut]

Just another quick point, with regard to caching on disk in a multi-server setup. Look into mounting drives accross the network. If NFS isn't up to the job for you then why not check out AOE, it cuts out the entire TCP/IP part of the stack so it's blinding quick and secure too (can't be routed over the net though obviously).

[edit]
HAHA! Found it, vblade. Allows you to expose drives on a standard linux box rather than buying one of those bloody expensive units.

[vaaaska]

Thanks for this!

I have more to say but I'm not sure how to say it. I need to do some reading. And I might send you a PM...I'm feeling woefullly incompetent trying to talk about ideas on this one.

A link -> http://blog.wevel.com/2005/10/zendphp_confere_5.html

[bubblenut]

Feel free to IM me. I'm only on ICQ, no AIM I'm afraid.

With regards to the guy's comment on "mid-air" collisions, remember that that is only relevant for objects which are changed frequently, from different locations and the content is critical. In most cases the data is only changed backend and therefore a simple drop of the cache item will suffice (and will be less load than a more exhaustive sollution). For example, a product can only be changed from the backend, therefore, so long as you drop the cache entry when you update the product you can be sure that the site will be up to date because the very next hit will populate the cache (or you can just set the cache when you've updated, depends on the setup). The point about "round-trip" collisions is an interesting one. Although, I guess, either the return time on your query or your traffic load is going to have to be damned high to get any kind of appreciable return from building in a sollution to it. At least, when you take into account the extra memcache hits needed for it. Memcache hits are quick but they're not free, it's still an I/O call, and one over the network at that.

Vaaska, thank you for bringing up this topic. I hadn't really put down any of the thoughts I've been having about caching recently and this has really helped me focus a couple of them.

[vaaaska]

Hey Bub...I can't send you a note because you have too many messages stored. 😉

[vaaaska]

I think caching structural chunks and templates is somewhat simple, however, how might one deal with plugins on a site? A plugin, used in many blogging and cms packages, loosely defined as some operation that calls on the database to compose a list of 10 most recent articles, etc.

In many cms packages it is becoming more common to drop these plugins into place.

(I'm sticking to a sort of lowest common denominator scenario here...php4, mysql4, general user base that doesn't have access to altering server/php settings, etc).

And so I wonder, is/are there an acceptable number of queries to the database that are allowable even if the main components of a site are cached? I think the answer is 'it's all relative', but I'm tossing this out there anyways.

Apparently, from what I've read, MySQL4 is not very good with query caching. If you update the database is clears out the cache. I guess that's not really so bad actually but it could seriously degrade a busy site (with users udpating content).

Is a site that is truy 100% cached possible? Bad question...

In a broader sense, how might a dev realistically strategize a caching schema? All I can see are tutorials and reasons for doing so, but nothing that says 'this is ok and this is not ok' sort of thing.

Opens the door...

[bubblenut]

You were right in your first statement. It's all relative. You have to think about what is the best model for your situation. If you're building a CMS and want to make caching available to module developers I would be inclined to give the module developers an interface into the caching class itself. If you start trying to second guess what they want you'll soon be caught out. Only they know what levels are acceptable.

With regard to setting somthing up on PHP4 and MySQL4 with no config changes, look into the two smarty caching sollutions. For simple, fast, file based caching, use Cache_Lite, I'd only use Cache if you have a very good reason for using a different persistence layer.

MySQL4's query caching is very quick, but yes, caches do get dropped when tables are changed. They have to be. Note though, only cached queries which are related to the table that was changed will be dropped. For example, if you have a query which uses only table A and it's cached, if you change table B the query will not be dropped. If you have multiple server (I know, you don't, but anyway) and you're using MySQL replication, you can force this by stopping replication during high load times.

100% cached possible? What do you mean? Do you mean that every piece of data retrieval is cached, the results of every algorithm are cached, or what? Caching isn't a panacea for a slow site, it should be used prudently where it's needed. To attempt to cache everything is missing the point. If you have a process which is lightning fast to run, then caching it is just going to be added another layer of overhead.

[vaaaska]

bubblenut wrote:

If you have a process which is lightning fast to run, then caching it is just going to be added another layer of overhead.

I think that in most cases it's not simply the case of one process but the combination of many processes that result in speed issues.

As I stated, '100% cached possible' is a bad question (but I left it in to make a point). What I'm getting at is how can one plan:

In a broader sense, how might a dev realistically strategize a caching schema? All I can see are tutorials and reasons for doing so, but nothing that says 'this is ok and this is not ok' sort of thing.

As best as I can tell one has to have a site fall apart before it's possible to go after the problems. Fair enough...

[bubblenut]

vaaaska wrote:

As best as I can tell one has to have a site fall apart before it's possible to go after the problems. Fair enough...

You can make educated guesses, what I was trying to get accross is that you have to do it in the context of your situation.If, for example, I know that I will be showing the last ten articles on the first page of a blogging site I have a few things to think about.

Home complicated is the query? Does it span many tables which could be changed frequently or does it just use the "article" table? How different is the representation of the data in the application from that in the database? Could the caching be handled at the database level?

How complicated is the rendering of the markup? Is it just data taken straight from the database and pushed into a template or is there more going on? Should I be caching the rendered markup? If I should be caching the rendered markup should I be caching it as several items (one for each article) or as one whole item?
Here you need to think about where else this data is going to be used and how often compared to the highest load areas. The article data may be used in many different places and in many different ways around the site (and should therefore be object cached), however, it may be the case that 95% of traffic is on the front page and therefore it may be prudent to output cache the full list of aticles as show on that front page even though that's the only place it's used.

[vaaaska]

Thanks Bub for all of this. It does seem context is most everything...