Caching Testing

[UPDATED NOTE Aug 25th, 1:44pm CST: We have disabled caching due to a long list of unintended consequences that we are researching how to overcome, one by one.]

Starting today, we’re testing a new way of serving up our site by employing “caching” on our web server.

The end goal is to improve speed by 2x-5x without throwing more server hardware at the challenge.

So far, MSIE browsing users are having a much better experience than those of us using FireFox for our browser (hint, click on TOOLS, OPTIONS, PRIVACY and clear your browser cache for a better experience till we solve this).

Caching defined in simple terms: “Web documents retrieved may be stored (cached) for a time so that they can be conveniently accessed if further requests are made for them. The issue of whether the most up-to-date copy of the file is retrieved is handled by the caching program which initially makes a brief check and compares the date of the file at its original location with that of the copy in the cache. If the date of the cached file is the same as the original, then the cached copy is used.” Source

If by Friday of this week, the user experience doesn’t improve or return to closer to normal, we’ll shut down the experiment.

One upside to caching is that it speeds up web serving performance tremendously.

One big downside is that our site is no longer “live” in real-time for anything and it may take 24 hours for anything to show up or occur once changed, for all users viewing the site.

We apologize in advance for anyone who experiencing any unintended consequences to our testing. Unfortunately, after all the prep that we did to introduce this caching service, …there was no other way to see how it really worked under pressure than to put it to the test.

Somehow, we are going to work to create a happy medium between our collective needs for speed and updating content in near-real time.

If you’re an Apache caching expert or have worked with PHP and MySQL, we’re very open to learn from any tips or suggestions you might have when it comes to turning on caching in a custom CMS built on the L.A.M.P. environment.

Before trying caching, we were exploring dumping large amounts of hardware at the new or evolving webserver speed end-outcome: LUDICROUS SPEED (yes, movie reference to “Space Balls”) and real-time updating (under an hour for everything) …but all of our nerd tech friends encouraged us to push through our reluctance to make caching work as a smart alternative for the short-term. Long-term, we are already allocating for increases in server hardware before 2005 is over.

Public comments welcome on caching in general. Private comments about bad user experiences also welcome so that we can improve or identify problem patterns that should get our top attention. Thanks!

Leave a comment

Please read our comment policy before commenting.