I've recently had a problem with a rather large operation (that could probably be optimised considerably, but nevermind), where by if the cached result of the operation expired, several web server threads would attempt the operation, causing some major headaches for our database and web servers. This is something I've come across before, and is commonly(?) known as a Cache Stampede. This is bad, this post describes the basics of what I've done to deal with it.

His example uses a Zend_Cache interface to Memecache, but it could be applied in other places too. His method uses a binary semaphore to check and see if there's a "lock" and sleep for a bit before checking again. Sample code is included showing how to create this system and how to refresh the data with a new expiration on a cache miss.

I just had an epiphany. I've talked about pre-caching content before and the benefits thereof before. But this is the first time I realized not only that there are benefits, but that doing it is BETTER than caching inline. Let me sum up... no, there is to much. Let me explain.

He gives an example of how a typical application might cache - when it finds a "miss" for the data it's trying to pull. A simple cache is easy, but what happens if it uses a configuration value that could change (like the username/password in his second example). Pre-caching would eliminate the risk since the setting would be known to be valid when the cache is generated.

I placed this entry under 'programming' but it might as well have been placed under 'rants' really. I've been programming PHP for over six years now. It's still definitely my language of choice because of it's speed, ease of use, ease of deployment and last but not least: because of the huge community with all of it's advantages. However there's one thing that's really bugging me lately: PHP is seriously suffering from what a friend of mine called 'the Apache syndrome'. Apache 2.x has been released a long, long time ago. Yet, tons of servers are still running 1.3.x and they probably will continue to do so for years to come.

While this isn't all that serious for a webserver (as long as it serves it's stuff and the server doesn't break it's fine) I believe the case is different with PHP.

He goes on to say that PHP is loosing out on the "coolness factor" to Ruby on Rails, and that most PHP developers out there just aren't taking advantage of the new features/better performance that PHP5 has to offer.]]> Tue, 21 Feb 2006 07:22:18 -0600