While we’ve touched upon client side caching in our series on Web performance, we haven’t discussed how client caching has grown more rich and useful over the years. In the initial days of the Web and the HTTP/1.0 protocol, caching was mostly limited to a handful of headers, including Expires, If-Modified-Since, and Pragma: no-cache. Since then, client caching has evolved to embrace greater granularity. Some new technologies even permit the deployment of offline-aware, browser-based applications.
Browser Request Caching
The most common and oldest type of client-side caching on the client is browser request caching. Built into the HTTP protocol standard, browser request caching allows the server to control how often the browser requests new copies of files from the server. We discussed the major aspects of browser request caching in part 1 of our series. Over time, Webmasters have taken to using different headers to improve caching on their site, including:
Pragma: no-cache. This old directive is used mostly by HTTP/1.0 servers, and instructs a client that a specific response’s contents should never be cached. It is used for highly dynamic content that is apt to change from request to request.
Expires. Supported since HTTP/1.0, this header specifies an explicit expiration date for cached content. It can be superseded by the value of the Cache-Control header. For example, if Cache-Control: no-cache is sent in a response, this will take precedence over any value of the Expires header.
If-Modified-Since: Since the HTTP/1.0 protocol, clients have been able to use this header to request that the server only send data if the resource has been changed since the specified date. If there have been no changed, the server returns an HTTP 304 Not Modified response.
In our last article on performance tuning, we examined how to squeeze the most performance out of an Apache server. In this installment, we’ll take a look at how to apply some of these same principles to Microsoft’s Internet Information Server (IIS), which ships as part of Windows Server.
While its percentage of the Web server market share has declined in recent years relative to Apache, IIS still remains the second most deployed Web server on the Internet. Its deep integration with Windows and host of management utilities make it a great choice for anyone hosting Web content and applications in a Windows environment. With a little performance tuning (aided, of course, by load testing), an IIS machine can perform just as well as an equivalent Apache configuration under high load.
The Usual Suspects: Compression and Connection Management
Many of the techniques a team might use to enhance IIS performance are similar to the techniques used on Apache, as they involve configuration of the HTTP protocol.
In the previous installments of our Web performance series, we’ve examined how developers can employ Web server caching and application caching to speed up their Web applications. In this installment, we’ll see how caching entire data sets can increase platform efficiency.
What is Data Caching?
Database caching is a species of application caching that caches the result of one or more database queries in the application server’s memory. For our purposes, we use application caching to refer to caching any component in an application server’s memory, and data caching to refer to caching a collection of data for future querying and sorting.
There are two main approaches to data caching:
- Data set caching. Data returned from a database is stored in a data set, an in-memory representation of data that mimics the column/row structure of a relational database.
- In-memory databases. An in-memory database is a relational database that operates completely in a server’s RAM, as opposed to storing data to a hard drive. In-memory databases can be used for fast access to data previously retrieved from a traditional, disk-based RDBMS.
Let’s dig deeper into each of these.
As we’ve discussed previously, Web site optimization directly affects a company’s bottom line. A sudden traffic spike that swamps a website’s capacity can cost a company thousands or even tens of thousands of dollars per hour. Web servers and Web applications should be built and deployed from day one with performance at the forefront of everyone’s mind.
Web site administrators and web application developers have a host of tricks and techniques they can employ to deliver Web pages more quickly. From my experience, I’ve seen 1,000% performance improvement from simple web application optimization techniques. Caching is the #1 tuning trick in the web developers kit. Customers ask me weekly what I recommend for speeding up their app. I always start with “caching, caching, and more caching”. It’s like magic for a site.
A ViSolve white paper shows a return on investment of $61,000 for a $20,000 total cost of ownership of only two caching servers!
In this article we’ll look at how two different but related forms of caching are used to conserve server resources and reduce network latency; thus, greatly improving your customers’ experience with your site.
What is Caching?
Caching refers to any mechanism that stores previously retrieved content for future use. As I learned it in college back in the VAX/VMS operating systems class, it is temporarily putting something into memory that you will use again in order to avoid hitting the hard drive. Computer scientists today are less concerned about saving every byte like we were back then. Still, web applications are constantly re-using data and files; so why in the world would we want to make an expensive hit to the database? Hard drives can be 10,000 times slower than memory because they are mechanical and must move to the correct position and spin to the exact spot where data exists. Memory moves at the speed of electricity.
The goal of caching is to increase the speed of content delivery by reducing the amount of redundant work a server needs to perform. Putting a file in memory to re-use it can save millions of drive accesses; thus, the speed of getting the browser what the user needs is increased by magnitudes. Caching and performance go hand-in-hand. It’s a no-brainer.
Have you ever had a Krispy Kreme Burger? It’s definitely over the top. Too much of a good thing.
In the first installment of our series on web performance, we examined how Web servers and Web browsers implement caching, which stores critical pieces of information in memory or on a local hard drive for subsequent rapid retrieval. In this installment, we’ll look at how Web application environments can use application caching to reduce load and increase performance.