Caching can be the best thing that ever happened to your site – or the worst. That’s because whether it works is all in the details – and there are so many details. Whether on database servers, websites, proxy servers, apps or in browsers, we asked you for your best practices or top tips on how to cache effectively and fix caching problems. Here’s the best advice we got.
If you have more caching tips and tricks, fill us in or tweet them to us using #CachingFixes, and we’ll include them in a future article.
There are so many great Web performance tools and resources available now. If you’re just getting started, check out PageSpeed from Google. Also consider skipping a server framework and using static content for your site in combination with a static site generator. By combining long-caching of static assets with a cache-busting system, we reduced subsequent load time on our site by more than 500 percent.
-Elias D., senior Web developer, Code42
Move Static Files to a CDN
As with any website which has seen a dramatic rise in growth over the years, we have also had to deal with exponentially-increasing server costs. The way we’ve kept our costs under control, however, is by moving all of our static files to a CDN, or Content Delivery Network. Because most of our images, CSS files and scripts are all now served by a CDN, resources are saved on the actual Web server hosting our site. This means that the server is more robust, and able to withstand more concurrent connections.
But there are other wins associated with moving your static files to a CDN: speed. CDNs typically have data centers located around the world, and, by detecting where your visitors are, they will serve your content from the data center mode nearest to them. This results in faster downloads, better website performance, and more satisfied visitors.
-Tom Churm, owner/creator, onlineclock.net.
Look for Bottlenecks
The best tip I have for people working with optimization and caching is learning how to look for bottlenecks. Caching the right thing makes applications faster; caching blindly causes problems. The easiest way I’ve found is using NewRelic and looking at the stack traces. Look for slow pages, queries, anything and figure out what is causing them. Then figure out if and how you can cache around that bottleneck.
-Kevin Ohashi, founder of Review Signal
Put Your Cache in the Right Place
It matters where you put your cache. Caching – as in the use of DRAM or flash to accelerate IO – should live closest to the application making use of it. For top performance it would be configured on the server, but then it can’t easily be shared across multiple servers. Each server could need its own cache and that can get expensive. And because of distributed cache synchronization and consistency challenges, traditional server-side cache has usually only been leveraged as read cache.
Today, however, there are newer caching solutions that either place caching in the “network” between servers and storage to enable sharing expensive cache resources transparently, or that leverage techniques like RDMA to virtually pool and synchronize server-side cache across server clusters. These types of shared or distributed caching solutions also offer significant write caching benefits because they ensure the data is always consistent for all users.
Caching in storage systems is important too, especially as a way to drastically improve the price-to-performance ratio of the storage array. For example, a small amount of flash (5 percent perhaps) on the array side can provide great performance combined with slower disks than might otherwise be required. And these slower disks are both cheaper and can have far greater capacities. Together, the whole “hybrid” array can be cheaper than one filled with high-speed spinning disk, and offer better targeted performance and higher total capacity.
-Mike Matchett, Sr. analyst and consultant for Taneja Group
Have a Way to Expire the Cache on Demand
Whatever caching mechanism you use, make sure you have some means to expire the cache on demand (so if you accidentally push out bad data, you can replace it quickly). In the past we used a Content Delivery Network (CDN) service that would cache our software downloads around the globe. The problem was they would take up to 24 hours to propagate a change. That meant if there was an issue with one of our files, it would take a day for all our users to get the change.
We found a lot of variability in this area; some providers would take 24 hours, some six hours, some one hour. It took us a long time to find a CDN provider that would propagate our changes on demand across the network. We ended up switching CDN providers to one that pushes out changes on demand (effectively minutes, rather than hours). Depending on the size and scope of your business, 24 hours may be a good trade-off for price, but for us it wasn’t worth it.
-Dan Santoni, Inspyder Software Inc.
Caching can be a tricky business that often requires a dose of creativity and experimentation. Of course, a little advice can’t hurt either. Do you have more caching tips and tricks? Fill us in, and we’ll include them in a future article.`