With the launch of CacheRight 3.0 last week, Port80 Software delivers enhanced cache control for Microsoft IIS servers and your Web users/visitors. The new version has an updated GUI and a new BlockByPath rule to make cache control easier to manage, and the entire filter has been redesigned for better server-side CPU and memory utilization, leveraging the work done to tune httpZip 3.6 for high-speed ISAPI filter performance over the past six months.
Cache control is not to be confused directly with caching itself, which is generally a special high-speed storage mechanism that can be either a reserved section of main memory or an independent high-speed storage device (two types of caching are commonly used in personal computers: memory caching and disk caching-- read more on caching here). Cache control is also different from caching in ASP.NET or PHP, Web development technologies that focus on the pre-generation of DB queries so dynamic pages load faster for browsers.
Cache control is about making a cache smarter on the Web, essentially turning browsers and proxy servers on the Net into your own content distribution network. The idea is to send less data, less often by making sure repeat visitors and Internet caches from the AOLs of the world (any proxy servers) do not re-validate static, unmodified content like an image (GIF, JPEG, PNG, Bitmap, whatever), CSS style sheets, JavaScript, a video, a PDF, an .exe, etc. While this can be controlled manually in Microsoft IIS Web servers, there is no developer “easy access”: developers and designers know what is fresh and what does not change on a site, not the admin -- and this method works every time with every cache, unlike the popular and quite sketchy reliance on the Last-Modified value). Also, IIS does not yet provide a mechanism for developers or admins to manage cache control centrally for a Web server and its virtual servers or Web sites, so CacheRight makes sense for Web professionals with standards, budget and speed in mind...
Once you know what content you would like to cache control, using CacheRight is straightforward: write a rule, save the rules file, request resource and examine headers to see if the right Expiration-based cache control headers were applied (the Expires: header and other headers for caches). Browsers and proxy caches then rely on this data to decide whether to bug your Web server for new content and to avoid 304s at the Web server – this means your Web server answers higher priority requests, and repeat visitors see your Web site or application as faster every time they use it as images and non-changing files pop quickly from their CPU, from the browser’s cache – or a closer proxy server.
The hard part is thinking of your Web sites and applications globally and then determining a good cache control policy. This will help you to craft CacheRight rules that reflect the cache control policies you want to enforce.
The first step is to categorize your objects (files) by MIME type and/or location (path), and decide how long each category of object should remain fresh in browser and/or proxy caches. Log file analysis tools will help here. This might be very simple (one or two policy statements) or quite complex (many policy statements), depending on your requirements.
Your cache control policies might be as simple as a statement that says "cache all images as long as possible in both browser and proxy caches, and don't cache anything that is not an image." Usually, there is a little more variation than this…
Once you know the cache control policies you want to implement, you can write the actual CacheRight rules that will enforce those policies. Here is a CacheRight sample rules file so you can see the syntax… The evaluation guide overall is a good read before testing CacheRight.
Do not let the sample rules file’s length scare you! Most sites end up with 10-20 rules for the whole site -- your rules set will vary, depending on how granular you want to control cache freshness and how often your content changes on your Web site/app.
Compression is usually an easier IIS performance technology to start with, as you can just plug in httpZip and get good results with its safe defaults (ZipEnable, like CacheRight, requires you to know what files you want to compress, controlled with that IIS 6 compression tool by file extension). Cache control often has a bigger impact on site speed, however, because the process of checking whether files without expiration-based cache control headers are fresh. While the user waits, your Web server answers 304 Not-Modified to each of these requests that are essentially asking the server, “Hey, I have this file in my IE or Firefox cache. Is it still good?” Why make users wait for this information? Why make your server answer needless requests for content you already served? If we at Port80 did not use cache control, our homepage would generate 64 image requests from each visitor each time they accessed the home page, and we would be forcing our users/visitors to wait longer for content they already have locally and still need to deal with these repeat requests under load when we could serve new visitors the files they need -- in priority. Test your site and ours for the impact of cache control with the Cache Check tool online right now...
Try out cache control, the best-kept secret of fast sites, and let Port80 Software know where we can help with the technology.
Best regards,
Port80