We use the sclient load generator to request a given high overhead URL and
control the request rate, steadily increasing it and measuring the throughput.
Figure 11 shows the client's throughput with varying
request rates for a dynamic CGI request that generates a file size of 29 KB.
The throughput increases linearly with the request rate
up to a critical point of about 63 connections/sec. For any further
increase in the request rate the throughput falls exponentially and
later plateaus to around 40 connections/sec. To understand this
behavior we used 
to capture the paging statistics.
Since the dynamic requests are memory-intensive, the available free
memory rapidly declines. For some combinations of the request rate
and the number of active processes, the available free memory falls to
zero. Eventually the system starts thrashing as the CPU spends most of the time
waiting for pending local disk I/O. In the above experiment with 150
server processes and a request rate of 63 reqs/sec the wait time starts
increasing as indicated by the 
field of the output
from vmstat.
To prevent overload we use URL-based connection control to limit the number of accepted dynamic CGI requests to a rate of 60 reqs/sec and a burst of 10. The dashed line in Figure 11 shows that with URL-based control the throughput stabilizes to 60 reqs/sec and the server never thrashes. In the above experiment, the URL-based connection control can handle request rates of up to 150 requests per second. However, for request rates beyond that thrashing starts as the kernel overhead of setting up connections, parsing the URL and sending the RSTs, becomes substantial.
To further delay the onset of thrashing we augment the URL-based control with the TCP SYN policer. For every TCP RST that is sent we drop any subsequent SYN request from that same client for a specified time interval. The time interval selected is the timeout value used for a lost SYN.
:
