HTTP Servers

Your HTTP servers play a critical role in the performance of the web site, as they handle large volumes of requests . HTTP serving is one of the older web technologies, and the popular HTTP servers enjoy the benefits of software maturity (stability, better performance, and improved usability). Web sites often improve performance by using the HTTP server directly to return static content, such as html, gif, and jpeg files. This allows these generally large pieces of content to be served earlier in the web site instead of forwarding requests on to the application servers. Knowing the relative number of requests for static content and dynamic content becomes important for sizing and configuring the HTTP servers. (Web sites often move static content to a caching proxy server, as discussed earlier, for even faster response to these requests.)

HTTP servers vary widely, from the extremely popular and open -source Apache web server to servers installed as standard components of software packages to commercial servers available for purchase. Refer to your documentation for parameters specific to your particular server. However, some basic performance settings remain fairly common across most implementations .

Threads or Processes (Listeners)

Different HTTP servers (sometimes even the same HTTP server brand running on different operating systems) use different models for handling large numbers of simultaneous requests. Some HTTP servers run as a single process and launch threads within the process to handle simultaneous requests. Others run as multiple, lightweight processes on the server, with each process handling a single user request. The HTTP server usually starts several threads or processes initially and opens more as needed to respond to incoming requests. We call these threads or processes listeners. An incoming request attaches to an available listener, which returns the information requested . After completing the request, the listener "listens," or waits, for the next request to arrive . HTTP servers typically respond very quickly to static content requests. Depending on the request and the data returned, an HTTP server on the right equipment may respond to hundreds or thousands of hits per second.

Your web site's configuration and workload determine the optimum settings for your HTTP server. If it receives only dynamic requests for the application server, you should define only slightly more HTTP listeners than the threads (processes) defined for your application server. If the HTTP server receives both static and dynamic requests, configure considerably more listeners. In general, for every dynamic page request, the web page receives several requests for static elements. Set the listener pool size for your HTTP server to support this ratio. As with every performance setting, just defining a lot of listeners is not always useful and often causes your server's throughput to decrease. Each thread or process competes with the others for machine resources, such as CPU or memory. Most HTTP servers use a default setting of 150 “200 listeners. The default makes a good starting point for performance testing. Try adjusting this number during your testing to find the optimal listener settings for your application.

Much as the JVM does with heapsize parameters, many HTTP servers also allow you to define minimum and maximum listener pool values. Other HTTP servers add a profusion of settings to vary the number of listeners between the minimum and maximum values. For example, on some HTTP servers, the listener pool shrinks to a predefined value during times of low usage. Be sure you understand the listener controls for your HTTP server.

Timeouts

Most HTTP servers enforce a timeout setting for requests. If the requested function does not return before the timeout period finishes, the HTTP server assumes the process is stalled and terminates the request. Occasionally, long-running server-side processes require you to raise this timeout value. Note, however, that browsers also time out long-running processes, so raising the HTTP server timeout value only helps if it remains lower than the browser timeout. Bear in mind, however, that extremely long-running processes usually spell disaster for high-volume web sites. If you find yourself increasing the timeout value, consider tuning the offending process instead.

If you're forced to support an unstable web application, consider shortening the default timeout value. This reduces the wait in the likely event that a request fails, and it prevents your web site from "freezing" due to thread unavailability. (See Chapter 2 for details on "frozen" web sites.)

Logging

The HTTP server's logging settings impact performance, particularly on high-volume web sites. Verbose logging requires more disk I/O to write the logs, and disk serialization negatively impacts performance. Some other logging functions, such as converting date strings from their default format, become very expensive if done frequently. Keep your logging format simple, and limit it to reporting severe errors. If you want to convert the date strings, consider using an external conversion process after generating the log.

The logs generated by HTTP servers typically contain the TCP/IP address of the requesting client. Some servers perform a reverse lookup to get a full name instead of just the numeric address. Performing this lookup on every request, again, takes precious processing time from your web site in order to create nicer logs. If you really want this information, post-process your logs to do the lookups at a later time.

Keep- Alive

As mentioned previously, HTTP is a connectionless protocol. Each request opens a TCP/IP socket from the browser to the server, completes a request, and then closes the socket. Since every page typically requires multiple HTTP requests for embedded elements, the protocol supports an extension for longer-lived connections. The HTTP server supports this extension through the keep-alive configuration settings. These settings tell the HTTP server whether or not to allow long connections, the maximum requests any browser may make on one long connection, and even the maximum time the connection may stay active. Consider adjusting these settings if your web pages require a much higher or lower number of HTTP requests per page to complete. Sometimes browsers do not close these connections cleanly, leaving the listener unavailable for other work until the timeout completes. Lowering the timeout makes the listener available more quickly.

Operating System Settings

Operating system settings also impact HTTP server performance. We'll mention just a couple of them here, but, as always, you need to consult your HTTP server's documentation for more details.

TCP/IP Timeouts

As mentioned above, browsers and HTTP servers communicate through TCP/IP sockets. Some operating systems provide settings to control the duration of the connection between machines. This optimization allows two machines in constant communication to avoid the overhead of continually setting up and breaking down a socket connection by extending the time the connection remains viable . If you set the timeout too high, the server might run out of connections if many different browsers try to send it requests.

File Descriptors

HTTP servers open many files during normal operation. Operating systems, however, typically limit the number of files open at any given time. Depending on your web site, consider increasing the available file descriptors.

SSL/HTTPS

Secure transmissions between the HTTP server and the browser use the HTTPS protocol instead of HTTP. The HTTPS protocol flows HTTP over the TCP/IP Secure Sockets Layer (SSL), which encrypts all the traffic between the client and the server. Adding more bits to the encryption key makes breaking the encryption key more difficult but increases the processing overhead when computing the keys. Beyond key computation, SSL adds overhead in key negotiation between the server and the client. As Figure 3.10 shows, key negotiation requires multiple network round trips to accomplish. The handshake requires multiple processing steps as well at each machine. Let's briefly review the basics of SSL setup.

Figure 3.10. A simplified version of the SSL handshake

First, the server gives its public key to the browser in a server certificate . This public key is part of an asymmetric public/private key pair delivered from the certifying authority (CA) . However, runtime usage of this key for every request requires too much overhead. Symmetric keys provide more security and speed, but these keys need secure exchange. In the SSL handshake, the public key is first sent to the server, which uses it to encrypt the rest of the handshake. The server then computes the symmetric key, and transmits this key back to the client encrypted using the public/private key pair. After this exchange of the keys, the conversation flows relatively quickly between the browser and the server. The initial exchange of keys is slow, so you want to keep the number of times this happens to a minimum. Configuring your load balancer for affinity routing reduces the SSL handshake overhead. Returning requests to a server with an existing SSL session for your browser saves time over moving between servers on each request to the web site.

As you might expect, SSL processing adds significant overhead to your HTTP server's processing. The HTTP server needs more CPU to manage the encryption and decryption algorithm, and each request takes longer to process. All these factors potentially impact the number of HTTP listeners supported by the server machine, as well as the overall number of listeners required by the web site. HTTP servers handling large SSL traffic volumes run best on a dedicated server machine. Otherwise, the CPU overhead tends to rob other applications (particularly application servers) of valuable processing cycles.

In general, use SSL discriminately. Certainly, we recommend encrypting sensitive information such as passwords, financial data, or other private information. However, a normal web site really only requires encryption for a small percentage of the site's content. For example, a shopping web site requires SSL encryption when taking the customer's credit card number, but not when showing them a selection of toasters. SSL encryption of large graphic elements is particularly expensive.

Plug-Ins

The application server receives web requests via an HTTP server. Most application servers provide a plug-in to connect with an existing HTTP server product. Using the HTTP server's own APIs, the plug-in allows dynamic requests to pass to the application server from the HTTP server. Figure 3.11 shows a typical plug-in at work.

Figure 3.11. Plug-in operation

The plug-in runs in the HTTP server's process, and its configuration potentially impacts the overall operation of the HTTP server, regardless of whether a given request passes to the application server. For example, some application servers' plug-ins perform security checks on every request. Likewise, plug-ins commonly grab incoming requests first before allowing the HTTP server to process them. The plug-in determines if the request goes to the application server and allows the HTTP server to process only those requests it cannot resolve (typically, the static requests). Of course, the plug-in processing increases the response time for static pages.

Sophisticated application servers often provide sophisticated plug-ins. As noted earlier, an application server supporting cloned instances may provide a smart plug-in to handle affinity routing and load distribution across these clones . These smart plug-ins often handle other tasks associated with the load balancer, such as failover. They may detect newly started application server instances and begin sending traffic to them. Regarding load distribution, sophisticated plug-ins frequently use distribution algorithms similar to those discussed earlier for load balancers. Plug-ins usually support round- robin distribution, and many support dynamic distribution based on feedback from the application server instances. Some include optimizations to prefer local clones (application server instances sharing the same box as the plug-in) to avoid expensive remote calls across the network.

As we mentioned, plug-ins sometimes support affinity routing to specific application server instances. Unlike HTTP servers, this affinity does not benefit SSL handshaking, but exists to provide faster access to HTTP session data. Overall performance generally benefits (sometimes significantly) if the user returns repeatedly to a cached copy of their HTTP session data. Particularly if the cluster uses a centralized HTTP session sharing scheme (such as a persistent HTTP session database), returning to the cached copy avoids a relatively expensive database retrieval of the user's state information. For example, plug-ins sometimes add a cookie to facilitate affinity routing. This allows the plug-in to track where it first routed this user at the start of his visit, and to return him to the same clone repeatedly until the visit is over.