Web server considerations

Even though the web server is a mature technology, it can still be tuned to get better performance, especially on large websites. This section covers the common performance considerations for all the web servers, and is operating system independent.

Listeners for threads or processes

If the web server receives dynamic requests for the Application server only, the number of HTTP listeners must be only slightly more than the number of threads that are being defined in the Application Server. In WebSphere Commerce, where static content (that is, image files such as GIF and JPG format) is being served by the web server instead of the file serving servlet, more listeners must be configured to achieve optimal performance.

The following parameters control the number of threads and processes in the configuration file httpd.conf for IBM HTTP:
  • ThreadLimit
  • ServerLimit
  • StartServers
  • MaxClients
  • MinSpareThreads
  • MaxSpareThreads
  • ThreadsPerChild
  • MaxRequestsPerChild
For more information about how to change these parameters, see IBM HTTP Server Performance Tuning.

Image distribution

Static images are stored on the web server and served from the web server as associated pages are accessed. For implementations that have many images, distributing these images over multiple directories is recommended, to reduce operating system scan time, as the web server serves the images. Based on our experience, no more than 50,000 images should be placed in one image directory.


Web servers allow different levels of logging for different sets of information. Even though this logging is useful to diagnose problems, it has significant performance impact on high volume websites. To ensure better performance, keep your logging format simple and limit it to reporting server errors.

In IBM HTTP, the LogFormat parameter controls how much information is dumped to the log files. For more information about how to change these parameters, see IBM HTTP Server Performance Tuning.


In the HTTP protocol, each request creates a socket connection to the server and sends a request. When the server responds, it creates another socket connect to respond to the client. This concept is simple to understand, but slow from the performance perspective. It would be ideal if the same connection could be used for both the request and the response. This is where the keep-alive function is used, to allow the server to manage long connections. The maximum requests that a browser can make on one long connection and the maximum time the connection may stay active are both configurable parameters.

Keep-alive is on, by default, for most of the web servers. The settings for parameters that are related to keep-alive depend on the website traffic characteristics. The maximum number of keep-alive connections and keep-alive timeout values need to be tuned in such a way that the trade-off between performance (avoiding creation of socket connections) and resources (the keep-alive connection cannot be reused for another connection until timeout) is balanced.

There are three parameters that control the number of socket connections:
  • KeepAlive
  • MaxKeepAliveRequests
  • KeepAliveTimeout
For more information about how to change these parameters, see IBM HTTP Server Performance Tuning.