Optimizing Your Web Server
May 23, 2001

by Don MacVittie

You want your Web server to handle all the demands of your users quickly enough so that 1 in 10 of them is not clicking away before your page loads.

So what are you to do? Optimize it. There are two different types of optimizations that will help you meet your users' needs -- generic and Web-server specific. This article concentrates on the generic ones, but don't ignore the ones specific to your Web server. There are plenty of references out there to help you with your brand of Web server, and you will get an added performance boost if you use them.

Throughout this article, it is presumed you have a high-speed Internet connection. When it comes right down to it, if you do not have one, then optimizing your server's performance should not be an issue.

The five types of generic optimizations are as follows:

• Hardware
• Operating System
• Web Server
• Development
• Graphics

Some of the options discussed will have potentially negative side effects, and some (particularly in the hardware arena) will have an associated cost.

Hardware

• Memory - First and foremost, do you have enough memory? Today you should be running 128-256 Mb per CPU on your machine. The system can handle additional processes and threads before it starts swapping, provided there's more memory. Swapping in modern computer architectures is relatively fast but still much slower than plain old memory access.
• CPU sizing and count - Is your machine too slow? Does it lack sufficient CPUs? Your Web server will be running a lot of processes to service the needs of your users; therefore, a dual or quad processor box is almost mandatory (if you can afford it). Remember that the CPU speed and number determine how fast the request gets recognized and serviced -- don't skimp.
• Hard drive speed - This is often the most overlooked hardware issue on a Web server. If your average access time is 12 milliseconds, and you are hitting 23 files to load a Web page, you could significantly increase your server's first response time by getting 8-millisecond drives. However, shorter access time means higher costs for the drives. Decide how much you're willing to invest.
• Upstream connection - Another neglected area is your provider's upstream connection and its saturation. Many companies will sell you bandwidth and not tell you the connection to their provider is so overloaded that if you use all the bandwidth you bought, users will time out because the packets can't be sent on fast enough.
• Connectivity with other servers - If you're relying on the Internet to provide images or links from remote servers, that is probably slowing you down more than anything else. Your own servers on your local network should not be a problem from a bandwidth perspective (assuming your LAN is 100 Mb or faster).

Operating System

• SMP operating systems - Is your operating system symmetric multiprocessing (SMP) enabled? It's not uncommon for some people to install multi-CPU machines and put a non-SMP build of Windows NT Server or Linux onto them. SMP is an option -- you must get an SMP version of the OS if you are running either of these operating systems. Failure to do so will result in only one CPU being utilized. Most operating systems are starting to recognize SMP on install, but don't count on yours doing so. When in doubt, check.
• Swap space - It is likely that you will eventually run out of conventional memory. As the amount of memory a machine can use effectively has grown, so has the relative size of the applications that run on it. Thus, you need adequate swap space. A good rule of thumb (assuming your memory is sized as previously suggested) is to make your hard drive swap space four times the physical memory size. You can go with more, but if you need a long-term solution, consider getting additional memory.
• Disk optimization/defragmentation - Use your disk optimizer tool whenever you have a huge change -- particularly if there is a lot of deleting or adding of files going on, or your disks are at more than 60 percent capacity. If you let your disk get too fragmented, then your Web server will slow down.
• Reverse DNS - Turn it off because it slows down your Web server. Reverse DNS is used to look up the domain name of users accessing your system. If you need this information, use reverse DNS manually for the few users you're interested in. Note that some Web servers must also have an option turned off in their log file configuration sections.
• Listen queue - This is the number of connections waiting to be processed by the server. The larger the listen queue, the more connections your server can handle. However, increasing it will not always improve performance. If your server is bogged down due to other issues when you have it set to 128 connections, imagine how slow it will be if you double the number of connections. Be aware that the listen queue length is normally set in two places -- the operating system network services and the Web server administration pages. Changing one will not impact the other's setting. Some flavors of UNIX require that you rebuild the kernel to increase the listen queue length.

Web Server

• Log files - Reduce the amount written to log files. The speed at which a machine writes to a hard drive is slower than the speed at which it does almost anything else. Turn off logging for everything you don't actively review. If your security personnel are in a different group than you are, pare logging down with their help. They are looking at the logs for different information than you probably are.
  • Web server cache - This cache holds the most frequently accessed pages as a function of time. As long as your cache has enough room for your core pages, and there's no dynamic data on those pages, your site will appear to be faster because the server will not regenerate them -- it will get them from the cache.
• Keep-alive time - This value is how long a connection is left "hanging" without receiving a response. This should be based on the time it takes to download your pages at the slowest connection rate. Most Web servers ship with this value set very high. Do some experimentation to determine the best values for your pages. Setting them for too short a period will cause your performance to degrade because the connection must be rebuilt several times -- for the page and for each image on the page. During this process, the connection is torn down during each download.
• Connection pooling - This option keeps a number of sessions open and distributes them as users need them. It speeds the connection time, which increases apparent performance. Even though the server isn't bigger or running faster, the user feels as if performance has improved. Each individual file that must be downloaded to load a page (including your images and your HTML) creates a separate connection in many Web servers. Connection pooling saves your server the time spent building a connection for each one of these files.

Development

• Know your development platform - Look at the differences in CGI, API calls, server-side scripts, and servlets. CGI has the slowest performance of these options. API calls are the fastest, but they are very tied to your Web server. Server-side scripting (including ASP and JSP technology) has fast access, and JSP technology is portable between many different servers. A note about ASP and JSP development -- you get better performance if you precompile them. If a page containing script (ASP or JSP technology) is not in the Web server's cache, then it will have to compile the script before returning any data to the user. Servlets are faster than CGI, but they do not (without additional software) match the performance of server-side scripts that are precompiled.
• Spread out the work - Invest in dedicated application and database servers if you can afford to do so, and performance of your Web front end is important. Even if it is not used much, a database server running on the same machine as your Web server uses memory, CPU time, and disk space that you could be dedicating to your Web interface. Early on, it's probably fine if you put your Web server on one machine and your application and database servers together on another. When you get to high volume, you can split your application and database servers apart.

Graphics

• One source for graphics - Put graphics in a single directory. The purpose of an images directory is that you only download the image once. If you spread images all over, the Web server will not know that the file is the same one it downloaded two seconds ago (because the image URL is different), and it will download the image again.
• Smaller is better - Cut down the sizes of your images. Don't save an image with more colors than it needs. Trim borders so the image fits exactly in the file. Find unique ways to portray your images with fewer colors rather than try to make everything as colorful as possible.
• Try different formats - Use different formats to check sizes. Try out your images in PNG, GIF, and JPG formats, and see what you get for size and viewable purposes. For most images there will not be noticeable differences between the look of the image in the three formats, but there will be huge size differences.
• Reuse common images - Do this whenever possible. This goes back to the point about putting these images in a common directory. If you are using an image as a horizontal divider, use it whenever you need such a divider. Then you'll only download it at most once per page access, which will save you and your user some processing time.