Filed under: IIS & HTTP, Web Speed and Performance
Tags: http compression
A good place to turn in order to speed up your site is the server software and hardware itself.
Starting with software, it is fairly unlikely that Web administrators are going to quickly dump IIS for Apache or Apache for IIS, even when security, ease of use, or performance is cited as a reason to leave one camp for another. Put simply, the Web server and its associated operating system are often so intertwined with the Web site(s) that migration becomes an onerous and even risky task.
When it comes to hardware, carefully consider the main tasks that the server(s) performs:
In the case of a static Web site, it is primarily to marshal network connections and to copy files from disk to network. To accelerate such a site, you want to focus on building a Web server with very fast disk and network subsystems, as well as enough memory to handle simultaneous requests. You may, in fact, choose to get very aggressive in adding memory to your system and try to cache all the heavily used objects in memory in order to avoid disk access altogether.
Interestingly, processor speed is not nearly as important as you might think in a site serving static files; it does help, but the disk will often prove to be a bigger bottleneck.
When the site is serving dynamic as well as static pages, obviously processor speed becomes more important; but even in this case, having a fast drive or dual NICs can still be more important. On the other hand, the combination of a lot of dynamic page generation with other processor-intensive responsibilities like SSL and/or HTTP compression makes it more likely that the CPU is the resource in need of enhancing.
In other words, what the server does will dictate how it can most effectively be beefed up.
Making it Work
Even if you don’t have it in your budget to customize your server hardware or software, there might be some changes you can make fairly cheaply.
For example, you might consider tuning your operating system’s TCP/IP settings for the most efficient use of those underlying TCP/IP resources on which HTTP is dependent. This might be a matter of adjusting the TCP receive window to a size best suited to your application and your server’s network connection, or making sure that TCP features that can be toggled, such as delayed ACKs or TCP_NODELAY, are used or not used, depending again on the characteristics of the application and the network environment, or simply making sure your box is not suffering from port exhaustion due to excessive TIME_WAIT times or other causes.
However, before twisting the knobs on your network characteristics, both in the Web server and on the operating system, make sure to set up realistic load tests to verify that your improvements don’t actually slow down users or cause excessive retransmits on your network. In other words, don’t try these types of fixes unless you understand how to measure their value.
HTTP compression on IIS is easy to enable with tools such as httpZip or ZipEnable and requires no client-side configuration to obtain benefits, making it a very smart way to get extra performance and a better user experience.
/P80No Comments »