Deployment Scenarios

There are a number of ways NSA HTTP can be deployed. We briefly describe two scenarios to highlight the most typical deployments.

The simplest scenario uses NSA HTTP and a conventional user-level web-server process co-located on a single system (Figure 1). In this topology, NSA HTTP increases server capacity by increasing the efficiency for processing static requests. NSA HTTP provides a fast path in the kernel that bypasses normal processing of static requests at the user level. This fast path entails having NSA HTTP parse each HTTP request to determine whether it can be served from the kernel. Requests that cannot be served from the kernel are passed to the user-level server process. Adding the fast path in the kernel, therefore, introduces additional parsing and processing to the path for requests served at the user level. This overhead is not significant and is more than compensated for by the increased efficiency when serving static requests.

Figure 1-1 Single System Web Server with NSA HTTP

A second typical deployment scenario uses NSA HTTP in a multi-server environment. High-traffic Web sites typically feature multiple servers that are in some cases specialized for particular purposes. A given set of servers, for example, may serve specific content such as images, advertisements, audio, or video. Dedicating servers to specific content types limits the total working set that must be delivered by any single server and allows the server's hardware configuration to be tailored to its content. One common approach to partitioning content, motivated by resource requirements, is to separate static and dynamic content.

In the multi-server scenario, the content is partitioned and NSA HTTP is deployed on only the web servers dedicated to serving static content, with a load balancer and/or web switch that routes user requests to the appropriate server (Figure 2). This approach is typically viable only when the content of a site has already been manually partitioned among a set of specialized servers.

Manually partitioning the content of a site requires not only distributing specific content types to the appropriate servers, but also modifying HTML pages that refer to the content to identify the server for each item delivered by a specialized server. Therefore, administrators may be reluctant, unwilling, or unable to manually partition content for a site after it is operational. Still, the second scenario is attractive for sites with content that is already partitioned.

Figure 1-2 Multiple Web Servers with Partitioned Content