Performance Evaluation of New Methods of Automatic Redirection for Load Balancing of Apache Servers Distributed in the Internet

(1)

Performance Evaluation of New Methods of Automatic Redirection for

Load Balancing of Apache Servers Distributed in the Internet

Kripakaran Suryanarayanan and Kenneth J. Christensen

Department of Computer Science and Engineering

University of South Florida

Tampa, Florida 33620

{ksuryana, christen}@csee.usf.edu

Abstract

An overloaded web server will lose incoming requests resulting in a “404 error” appearing at a client browser. Front-end application-level switches can redirect requests to less loaded servers. However, there exist no native methods within common web servers to automatically redirect requests for reducing load. We develop and evaluate changes to the open source Apache HTTP server to automatically redirect requests during periods of high load to a pre-specified overload server. We call the modified server “Red-Apache”. To reduce the double round-trip times of HTTP 301 redirection, a new “server tag” substitution method of redirection at a client browser is investigated. Server tag enables single round-trip redirection and is implemented by a JavaScript function in a returned page. Using the AB and SURGE benchmarks, we show that Red-Apache and server tag outperform the original Apache server and HTTP redirection, respectively.

1. Introduction

The growth of the World Wide Web is imposing considerable strain on both networks and servers. Investigating methods of organizing multiple server machines into both local and distributed clusters is an area of current research and development. These methods focus on balancing incoming requests among multiple servers. The result is a reduced load on individual server machines and thus improved response times as seen by users. Redirection of requests from an overloaded server to a less loaded server is one method of balancing load. The mechanisms and policies for such redirection are open areas for research.

The Apache Project [1] is a collaborative software development effort aimed at creating a robust, commercial-grade, feature rich, and freely available

source code implementation of an HTTP (web) server. Apache accounts for more than 55% of all web domains on the Internet [9]. Front-end devices, such as application-level switches and specialized load-balancing routers, can be used to redirect requests between Apache servers in both local and distributed clusters. There exist no native methods (i.e., within the Apache server software) for redirection between widely distributed servers. Distributed Packet Rewriting (DPR) [4] is one recently developed method of native redirection in a local cluster of Apache servers. DPR is further reviewed in Section 2 and is shown to be not scalable to geographically distributed servers.

Redirection between distributed servers can be accomplished via the native HTTP 301 and 302 mechanisms. This mechanism requires a double network round-trip of request/redirect/request/response packets. For geographically distant servers, this double round-trip can appear to a user as a sluggish or slow response time for a requested page.

In this paper we develop a native redirection mechanism (using a simple threshold policy) within the open source Apache software. This native redirection mechanism uses HTTP 301. We also explore faster redirection methods based on a new “server tag”. The development and investigation of the best policies to be used for redirection are beyond the scope of this paper. Research on redirection policies includes recent work by Dahlin [8] on using stale load information.

The remainder of this paper is organized as follows. Section 2 describes existing redirection mechanisms. Section 3 describes the new redirection mechanism that we implement in the Apache as “Red-Apache”. Section 4 describes the server tag concept and its implementation. Red-Apache and server tag are evaluated in Section 5. Section 6 presents the conclusions and is followed by a list of references and an appendix with Red-Apache source code.

(2)

2. Existing Redirection Mechanisms

Redirection of requests can occur at several levels. Redirection mechanisms can be implemented in the client, network, specialized front-end switches or routers, or in the servers. The HTTP protocol includes built-in redirection capabilities that can be used by switches, routers, and servers.

In client-based redirection, a client independently selects the “best” server based on load or response time information acquired via probing. Portable Java code can be used to implement these mechanisms. A dynamic protocol is employed to find the best server for a document. For example, Crovella [7] uses client probes to a set of servers, each of which may have a replica of the document, and chooses the first to reply as the source of the document. Client-based redirection has the disadvantage of generating significant amounts of redundant overhead (probe) traffic in the Internet.

Using DNS, a single host-name alias is used for a distributed web site containing many servers, each with a unique IP address. The authoritative DNS server for the domain maintains a one-to-many mapping of the server name to the IP address of each of the servers [6]. When clients send name resolution queries, the name-server returns each of the address in a round-robin fashion. Clients are served by one of the servers and the round-robin name resolution may result in balancing the load among the servers. Local caching by DNS servers makes the load less than perfectly balanced among the servers. Another problem with round robin DNS schemes is that as DNS servers know nothing about network topology, server availability or server capacity, users might be connected to a distant, unavailable, or overloaded server.

In anycasting an IP anycast address is used to define a group of servers that provide the same service. A sender desiring to communicate with only one of the servers sends datagrams with the IP anycast address in the destination address field. The datagram is then routed using anycast-aware routers to at least one of the servers identified by the anycast address [3]. Anycasting requires infrastructure changes in the Internet making implementation difficult.

In both application-level switching and server-based redirection, only one logical IP address is advertised for a local or distributed web site and incoming client requests all go to one of the switches or servers in a the distributed web site. The target switch or server can then re-route the request to a less loaded server. Distributed Packet Rewriting (DPR) [4] is a server-based redirection mechanism that uses a re-routing method to enable load balancing within a local cluster. The re-routing creates a “dog-leg” route (i.e., the original target server remains as part of the route for the duration of a connection). This dog-leg routing makes DPR poorly suited for

geographically distributed web sites.

HTTP provides two redirection codes HTTP 301 and HTTP 302. In HTTP 301 the requested resource is assigned a new permanent URI and any future references to this resource uses one of the returned URI’s. In HTTP 302 the requested resource is temporarily under a different URI. This response is only cacheable if indicated by a cache-control or expires header field [10] .

3. Adding Redirection to Apache

The source code for Apache is freely available, enabling one to make changes to the code to increase its functionality or improve its performance [11]. We used Apache 1.3.9 for Linux.

3.1 Automatic redirection implementation

In the Apache server, the MaxClients directive sets the limit on the number of simultaneous requests that can be supported. A maximum of MaxClients child server processes will be created. Any connection attempts over the MaxClients limit will normally be queued, up to a number based on the ListenBackLog directive. Once a child process is freed at the end of a current request, the next queued connection will then be serviced. Requests arriving that exceed ListenBackLog are discarded (and thus result in a “404 error” at the client).

Queued requests result in a delay of response and, potentially, in a loss of requests if the queue overflows. To reduce this delay and minimize loss, we propose an automatic redirection to a second mirrored “overflow server”. To do this we change the Apache software such that any request over the MaxClients value will result in an HTTP 301 redirection to an overflow server (which is a mirror of the first server in content). Thus, no queueing of requests is allowed; all excess (over MaxClients) requests are redirected to the overflow server. The overflow server need not be a local server, it can be geographically distant. This new automatically redirecting Apache server is named Red-Apache (for “Redirect Apache”). Figure 1 shows the basic operation and flows of Red-Apache. A client sends a request to a Red-Apache target server (1). If the target server is overloaded, then an automatic redirect via an HTTP 301 (2) is sent back to the client. This HTTP 301 causes the client browser to automatically resend the request (3) to an overflow server. The overflow server then sends (4) the client the requested item as a response. The overflow server need not be a Red-Apache server, or even an Apache sever for that matter. The appendix contains source code for the module http_protocol.c that implements Red-Apache.

(3)

Client Target server Overflow server Internet Reques t Response Request (1 ) HTTP 301 (2) Request (3) Response (4) Running Red-Apache software

Figure 1 - Automatic redirection with Red-Apache For a redirected request, the total time to response is a double Round Trip Time (RTT) plus one response transfer time. For efficiency, it is important that the response transfer time is much larger than RTT. For low speed connections, or for overloaded servers, the transfer time of even a small object will easily exceed an RTT. Thus, redirecting requests from an overloaded target server to an overflow server can result in a performance improvement. Methods to reduce the double RTT are addressed later in this paper.

HTTP response codes, more specifically, codes 301 and 302 are returned in many modules of Apache. The various core modules and the ways by which a request is handled is as follows (from Apache source code):

• http_main.c: Simple http daemon for answering WWW file requests.

• http_config.c: Contains general command loop and functions, which do bookkeeping for the Apache configuration tasks (modules and configuration vectors).

• http_core.c: Provides support for basic server operations, including options and commands that control the operation of other modules.

• http_request.c: Handles the main line of request processing, once a request has been read in (finding the right per-directory configuration, building it if necessary, and calling all the module dispatch functions in the right order). • http_protocol.c: Routines that directly

communicate with the client.

The core ensures that correct information is available to the modules at the right time by matching requests to the appropriate virtual server and directory information before invoking the various functions in the modules. The most important of such information is a small set of character strings describing attributes of the object being requested, including its URI, filename, content-type and content-encoding. Other commonly used data items are tables giving the MIME headers on the client’s original request, MIME headers to be sent back with the response

(which modules can add to at will), and environment variables for any subprocesses which are spawned off in the course of servicing the request. These tables are manipulated using the ap_table_get and ap_table_setroutines. This, and other information, is packaged in a request_rec, defined in httpd.h.

Most Apache servers are configured to handle a maximum number of connections somewhere between 100 and 150. We keep track of the request number and when it exceeds the previously specified maximum number of connections we make use of the status variable in the request_rec to send a HTTP 301 response code to the client. With the HTTP 301 response code we send the location of redirection, the URL of the overflow server, to the client. We send this as part of any routine, which directly communicates with the client.

4. A “Server Tag” for Fast Redirection

To reduce the double RTT of HTTP redirection we introduce the concept of a “server tag”. A server tag is the URL of an overflow server that is substituted into the anchor tags of the target server. This substitution occurs at the client and is implemented via a JavaScript function (in the header of each returned web page from server to client). Figure 2 shows the flow of requests and responses for server tag. The overloaded target server responds to a request (1) with the complete response (2) that contains a JavaScript function to replace the URL of the overload server with the URL of the overflow server for subsequent requests (3). The subsequent requests are responded to (4) by the overflow server.

Client Target server Overflow server Internet Reques t Response Request (1 ) Responsewith

tag (2)

Request (3) Response (4) Software support for Server Tag

Client Target server Overflow server Internet Reques t Response Request (1 ) Responsewith

tag (2)

Request (3) Response (4) Software support for Server Tag

Figure 2 - Redirection using server tag

Figure 3 shows the server tag JavaScript function for the Netscape browser. The server tag concept can be implemented for Microsoft Internet Explorer with,

document.links(i).href = target

instead of

document.links[i].href = target.

The JavaScript function is implemented in the header section of the web page and searches for <a href>

(4)

statements within the web page. It replaces the server name provided in the<a href>with a new server name. For the function of Figure 3, all instances of

http://www1.mega.com will be replaced by

http://www2.mega.combefore the page is displayed by the browser. In this example,http://www2.mega.comis the URL for the overflow server.

function checkbrowser() {

if (navigator.appName == “Netscape”) {

var target = “http://www1.mega.com”; var overflow = “http://www2.mega.com”; for (i=0; i<=document.links.length; i++) { if (document.links[i].href == target) document.links[i].href = overflow; } } }

Figure 3 - JavaScript implementing server tag

5. Performance Evaluation

We evaluated (i) the performance of Red-Apache (compared to original Apache) and (ii) the performance of server tag compared to HTTP 301 redirection. We used the SURGE and AB benchmarks.

5.1 The SURGE benchmark

The SURGE workload generator, described and available from [2], mimics a set of real users accessing a server. A SURGE User Equivalent (UE) is a process that alternates between requests and being idle (modeling user viewing of the requested Web pages). A single workload generator (i.e., a single PC) can mimic multiple UE by using multiple threads - one for each UE. SURGE uses a heavy-tailed distribution for file sizes. Empirical results from studies of Web servers and user requests are used to establish a baseline for:

• Server file size distribution - based on a heavy tail distribution.

• Request size distribution - the distribution of requests to files, which is not the same as the distribution of files.

• Relative file popularity - the relative number of requests made to individual files; follows a Zipf distribution.

• Embedded file references - the number of embedded references in a requested file which result in off time different in nature from user idle times.

• Temporal locality of reference - temporal distribution of files (important for evaluating caching policies)

• OFF times - distribution of off, or idle, times. SURGE exercises servers in a manner significantly different from other web server benchmarks - largely due to the heavy tail distribution used for file sizes - resulting in a higher CPU utilization of the server [2].

The performance of Red-Apache and server tag is measured for the mean number of requests honored per second by the server (i.e., responses per second) by varying the following parameters:

• Number of UE’s accessing the server • Number of files in the server • File popularity

The last parameter changes the shape of the Zipf distribution of file popularity. Making the most popular file accessed more times in total skews the request to the most popular file. Generally, the most popular file is a small file, the least popular the large “heavy tail” files so increasing the popularity value causes the server to transfer more small files.

5.2 The Apache Benchmark (AB)

The Apache Benchmark (AB) is part of the latest Apache distribution, and is based on a tool called Zeusbench [14]. AB measures the data throughput (in bytes/second) when repeatedly downloading a file within a specified size range. We specified a file size of 60 KBytes. The following parameters were specified:

• Number of requests to perform

• Number of concurrent processes for the same For our experiments, we made all requests to be concurrent. We measured the performance of Red-Apache and server tag for the total number of requests completed by the server for the duration of the test.

5.3 Testbed for performance evaluation

Our testbed had four machines. The target server was a 200-Mhz Pentium II PC with 64-Mbyte RAM running Linux 2.2.12-20 kernel and Apache 1.3.9. The overflow server was a 133-Mhz Pentium PC with 32 Mbytes RAM also running Linux 2.2.12-20 kernel and Apache 1.3.9. The client machines (running the SURGE or AB workload generator) were a 233-Mhz ThinkPad 600 laptop running Linux 2.2.10 kernel and a Pentium 200 MHz PC with the same configuration as the ThinkPad. At the client we used the text-mode Lynx browser. We used both PPP (a dial-up 28.8 kbps connection) and a 10-Mbps switched Ethernet LAN. The ThinkPad client was used for dial-in and the 200 MHz PC for the LAN experiments. Every experiment was run for a minimum of 10 times, and the average value was taken.

(5)

5.4 Description of experiments

Eight experiments were defined to measure the performance of Red-Apache (versus the original “plain” Apache) and the server tag mechanism (versus HTTP 301). The experiments measure performance for both dial-in and LAN-based clients. The Red-Apache experiments (experiments 1 through 3, and 5 through 7) use the SURGE and AB benchmarks to measure improvements in response rate. The server tag experiments (experiments 4 and 8) measure improvement in response rate as mean number of responses per second. In the case of the server tag implementation, our client generated requests to the target server, which modifies the links and then the subsequent requests were sent to the overflow server. For server tag versus HTTP 301 performance evaluation, we used the Lynx browser for measurement purposes (i.e. for timing of requests). The following parameters were changed for the server tag implementation.

• Number of requests for the document • File sizes (in the server)

Experiments 1 through 4 are for dial-in clients and experiments 5 through 8 for LAN based clients. For the SURGE benchmark the control variable is the number of UE’s. For the AB benchmark, the control variable is the number of concurrent requests. To measure server tag we wrote a program that generated as many concurrent requests as we wanted from Lynx. We time the response using the timeb structure of ftime.h. All the requests from the Lynx browser are sent at the same time causing the server to get heavily loaded. All experiments were run until steady state was achieved.

5.4.1 Experiment #1. For SURGE we varied the number of UE’s from 60 to 90 in increments of 10. The number of files in the server was fixed at 5000 and the total number of requests for the most popular document in the server was varied as 10,000, 30,000, and 50,000 .

5.4.2 Experiment #2. Same as experiment 1 except the total number of requests was fixed at 50,000 and number of files was varied as 500, 3000, 5000. The values in experiment 1 and 2 were chosen as a representative range of high load to low load. The upper value of number of files as 5000 and total number of requests as 50,000 is the maximum size that our file server could handle before crashing. Server crashes were due to number of files, total popularity and the number of UE’s.

5.4.3 Experiment #3. For AB the number of concurrent requests to the server were 75, 90, 100, 120, and 125. More than 125 concurrent requests caused server failure.

5.4.4 Experiment #4. To compare server tag and HTTP 301, request to response time was measured. The number of concurrent requests was 50, 60, and 70. File sizes of 6 Kbytes, 10 Kbytes, 20 Kbytes, and 60 Kbytes were used. These values were chosen because of several web studies [8].

5.4.5 Experiment #5. Same as experiment #1 except the range of UE’s was increased from 110 to 140 to reflect the greater throughput capability of the LAN.

5.4.6 Experiment #6. Same as experiment #2 except range of UE’s was increased from 110 to 140 to reflect the greater throughput capability of the LAN.

5.4.7 Experiment #7. Same as experiment #3 except the number of concurrent requests to the server was 280, 320, 380, 420, and 480.

5.4.8 Experiment #8. Same as experiment #4 except the number of concurrent requests was varied as 200, 300, 400, and 500.

5.5 Experiment results

Figure 4 shows the results for experiment #1 and Figure 5 for experiment #2. In Figure 4, a1 through a3 are file popularities 10,000, 30,000, and 50,000 for the Apache server. Series ra1 through ra3 are the same for Red-Apache. In Figure 5, a1 through a3 are number of files as 500, 3000, and 5000 for Apache server. Series ra1 through ra3 are the same for Red-Apache. A larger popularity value results in a greater response rate (i.e., a3 and ra3 are greater than a1 and ra1) due to the more popular files being relatively small files. Equally, an increase in the number of files results in more small files being requested (since more files are small than are large). It can also be seen that there is an average increase of 8% and 6% in the number of requests honored per second by Red Apache as compared to the original Apache server.

Figure 4 - Results for experiment #1

1 1.2 1.4 1.6 1.8 2 60 70 80 90 Number of UEs R esp o n se s p er se co n d a1 ra2 a2 ra3 a3 ra1

(6)

Figure 5 - Results for experiment #2

Table 1 shows Apache results, Table 2 shows Red-Apache results for experiment #3. It can be seen that there is an increase of 14% in the number of requests honored by Red-Apache compared to original Apache server. That is, Red-Apache is “catching” and redirecting requests that would normally be dropped by the original Apache.

Table 1 - Results for Apache (without redirection)

Requests Completed 75 64 90 69 100 77 120 82 125 91

Table 2 - Results for Red-Apache

Requests Completed HTTP 301 requests

75 68 3

90 81 22

100 99 24

120 106 30

125 109 31

Figure 6 shows the results for experiment #4. Series ht1 through ht4 are file sizes 6 Kbytes, 10 Kbytes, 20 Kbytes, and 60 Kbytes for HTTP redirect. Series st1 through st4 are the same for server tag. In all cases, the “st” series (solid line) is on top of the “ht” series (dotted line). It can be seen that there is an average increase of 10% in the number of requests honored per second by the server tag mechanism as compared to HTTP 301. Again, and not surprisingly, smaller file sizes result in a greater response rate.

Figure 6 - Results for Experiment #4

Figure 7 shows the results for experiment #5 and Figure 8 for experiment #6. Series a1 through a3 are file popularities 10,000, 30,000, and 50,000 for Apache server. Series ra1 through ra3 are the same for Red-Apache. In Figure 8, a1 through a3 are the number of files as 1000, 3000, and 5000 for Apache server. Series ra1 through ra3 are for Red-Apache. It can be seen that there is an increase of 23% in both cases in the number of requests honored per second by Red Apache as compared to the original Apache server. For the LAN experiments, the Red-Apache showed greater improvements over original Apache as the number of UE’s increased. This is because the relative time for a response is shorter in a LAN than in a dial-up connection; the same absolute improvement will have a larger relative gain.

Table 3 shows Apache results, Table 4 Red-Apache results for experiment #7. It can be seen that there is an increase of 18% in the number of requests honored by Red Apache compared to original Apache server.

1 1.2 1.4 1.6 1.8 2 60 70 80 90 Number of UEs R esp o n se s p er se co n d ra3 ra2, a2 ra1, a1 a3 0 5 10 15 20 25 30 110 120 130 140 Number of UEs R esp o n se s p er se co n d ra3 a2 ra2 a3 a1, ra1 0 0.2 0.4 0.6 0.8 1 1.2 50 60 70 Number of Clients R esp o n se s p er se co n d st4, ht4 st3, ht3 Y st2, ht2 st1, ht1

(7)

Figure 8 - Results for Experiment #6 Table 3 - Results for Apache (without redirection)

Requests Completed 280 221 320 255 380 294 420 318 480 349

Table 4 - Results for Red Apache

Requests Completed HTTP 301 requests

280 257 47

320 286 68

380 334 105

420 384 156

480 437 177

Figure 9 shows the results for experiment #8 where ht1 through ht4 are file sizes 6 Kbytes, 10 Kbytes, 20 Kbytes, and 60 Kbytes for HTTP redirection and st1 through st4 are the same for server tag. The average increase in the number of requests honored is 9%.

5.6 Observations regarding CPU utilization

When we checked for CPU utilization using Linux system tools, such as the top command, we found that there was very little CPU utilization. Since our CPU utilization measurement was done at a one second interval, we were not able to get the actual load at the CPU level at a time scale of interest to our overflow behaviors.

6. Summary

This paper has proposed, developed, and evaluated two new redirection mechanisms for web servers distributed in the Internet. Red-Apache adds automatic HTTP 301 redirection to the open source Apache server. Red-Apache does automatic redirection to a pre-specified overload server if the number of requests exceeds MaxClients. Server tag is a means of redirecting clients so that the double round trip time of HTTP 301 redirection is avoided. The experimental evaluations of Red-Apache using the SURGE benchmark show that there is an increase of 8% in the number of requests honored as compared to the original Apache server for dial-up clients and an increase of 23% for LAN clients. Using the AB benchmark, it was shown there is an increase of 14% in the number of requests honored under dial-up and an increase of 18% under LAN. The server tag evaluation confirms that our new mechanism performs better than the HTTP 301 redirection mechanism. There is an increase of 10% in the number of requests honored as compared to the HTTP 301 implementation for both dial-up and LAN clients.

Acknowledgements

The authors acknowledge the anonymous referees for their helpful comments, especially with regards to interpretation (and correction) of the experimental results.

References

[1] The Apache Team, “Apache HTTP Server Project.” URL: http://www.apache.org.

[2] P. Barford and M. Crovella, “Generating Representative Web Workloads for Network and Server Performance Evaluation,” Technical Report BU-CS-97-06, May 1997. [3] S. Bhattacharjee, M. Ammar, E. Zegura, V. Shah, and Z.

Fei, “Application Layer Anycasting,” Proceedings of INFOCOM, pp. 1388 - 1396, April 1997.

[4] A. Bestavros, M. Crovella, J. Liu, and D. Martin, “Distributed Packet Rewriting and its Application to Scalable Server Architectures,” Proceedings of the Sixth International Conference on Network Protocols, pp. 290 -297, October 1998. 15 18 21 24 27 30 110 120 130 140 Number of UEs R esp o n se s p er se co n d a1 ra1 ra2, ra3 a2, a3 5.5 5.75 6 6.25 6.5 200 300 400 500 Number of clients R esp o n se s p er se co n d ht4 ht1, ht2, ht3 st1, st2, st3 st4

(8)

[5] A. Bestavros, R. Carter, M. Crovella, C. Cunha, A. Heddaya, S. Mirdad, “Application level Document Caching in the Internet, “Proceedings of SDNE'95: The second International Workshop on Services in Distributed and Network Environments,” pp. 166 - 173, June 1995. [6] T. Brisco, “DNS Support for Load Balancing,” RFC 1794,

April 1995.

[7] R. Carter and M. Crovella, “Dynamic Server Selection using Bandwidth Probing in Wide-Area Networks,” Technical Report BU-CS-96-007, March 1996.

[8] M. Dahlin, “Interpreting Stale Load Information,” Proceedings of the International Conference on Distributed Computing Systems, pp. 285 - 296, May 1999.

[9] D. Dias, W. Kish, R. Mukherjee, and R. Tewari, “A Scalable and Highly Available Web Server,” Proceedings of the IEEE COMPCON ’96, pp. 85 - 92, February 1996. [10] HTTP/1.1 Draft Specification. URL: http://www.w3.org/

Protocols/ HTTP/1.1/rfc2616.txt.gz.

[11] Y. Hu, A. Nanda, and Q. Yang, “Measurement, Analysis and Performance Improvement of the Apache Web Server,” Technical Report No. 1097-0001, Department of Electrical and Computer Engineering, University of Rhode Island, 1997.

[12] Netcraft Survey. URL: http://www.netcraft.com.

[13] D. Wetherhall and D. Tennenhouse, “The Active IP Option,” in 7th ACM SIGOPS European Workshop, Connemara, Ireland, September 1996.

[14] Zeusbench, 2000. URL: http://www.zeus.co.uk.

Appendix - Red-Apache Source Code

This appendix contains the Red-Apache source code. Figure 10 shows the beginning of the Apache module http_protocol.c. Figure 11 shows the added code that comprises the Red-Apache function.

API_EXPORT(void) ap_basic_http_header(request_rec *r) {

char *protocol; if (r->assbackwards)

return;

<SNIP SNIP - remainder of module not shown here> }

Figure 10 - Original Apache http_protocol.c (unmodified)

API_EXPORT(void) ap_basic_http_header(request_rec *r) {

// Define the location where you want to redirect char mylocation[MAX_STRING_LEN];

char *protocol; int threshold = 75;

// Copy the location where you want to redirect

strcpy(mylocation,"http://www.overflow.com"); // This is the URL of the overflow server // Check if it is backward compatible to HTTP 0.9

if (r->assbackwards) return;

// Keep in tab of the number of children open

// Issue the 301 redirection and the location to pass to if(request->connection->child_num > threshold) {

// Assigning status value request->status = 301;

// copy the redirection location strcat(mylocation,request->uri); // Sending it to the client

ap_table_setn(request->headers_out,"Location",mylocation); }

<SNIP SNIP - remainder of module - unchanged from original - not shown here> }