Insulation Despite Service Sharing

Instead of letting the sites A and B execute CGI scripts to serve the advertisement banners (part of the benchmark), a shared, single-threaded Fast-CGI server (FCGI) was used. Queuing theory suggests that the impact of this shared FCGI will be the worst when (a) it exhibits highly variant execution times and (b) a high percentage of requests are forwarded to it. Therefore, we modified the FCGI to execute a busy wait cycle randomly chosen between 0 and 10 ms (uniformly distributed), before serving incoming requests for advertisement. Furthermore, the percentage of advertisement banners requests was raised from 13% to 30% on each site. Other dynamic requests were eliminated from the benchmark's workload. The Apache sites (A and B) used a TCP connection to retrieve advertisement from the shared FCGI, which was located on the same machine as the two sites. Since we used a TCP connection, we could have also moved the FCGI to a remote server without breaking the VS paradigm. Nevertheless, the remote server would have been so underloaded that interference effects would not have been easy to observe. Moreover, the time required to invoke a remote FCGI would have severely limited overall HTTP throughput. The load offered to Site A was kept at 30 simultaneous connections while the load offered to Site B increased from 10 to 60 simultaneous connections -- with the changed dynamic mix, the server became saturated at a total of 60 simultaneous connections of offered load.

As in the experiments of the last section, two VSs (www1 and www2) were created and each was assigned half of the machine's CPU capacity. The first experiment (Apache insulation only) executes the FCGI outside the VS context of either site so that it could utilize all unused server capacity.

In the second round (dynamic FCGI-to-VS binding) we loaded the additional accept and socket gates to police access to the FCGI, which received its requests via TCP. The following classification rules were instantiated:

(accept, www[1|2], req = www[2|1]) => (www[2|1])

The accept rules cause the FCGI to change its resource binding if it is executing in the VS context of www1 ( www2) and receives a request from www2 (www1) to www2 (www1). Moreover, accept reorders requests in the order of their VS's remaining resource share as explained in Section 4. The default socket rule associates a new socket with its creator's VS. This ensures that requests sent to the shared FCGI will have appropriate TOS markings. To establish a baseline for optimal insulation, we replicated the FCGI script in each VS context (replicated FCGI). This cannot be done in real setups because many applications are not designed to be replicated.
 

Figure:A's performance while increasing load on B

As Figure 12 shows, sharing the FCGI without the accept gate breaks the insulation between sites A and B (Apache insulation only); the performance of Site A decreases rapidly as the load on Site B increases. This effect can be traced back to the contention for the shared FCGI. With the accept gate (dynamic FCGI-to-VS binding), the performance of Site A drops at a much slower, nearly the pace for replicated FCGI. The benefit of using the accept gate is a performance improvement for the well-behaved site (well-behaved means that its clients do not overload the site) of approximately 60% under maximal load. Further experiments show that the accept gate for dynamic VS bindings performs almost as well as if the shared service were replicated for each VS (replicated FCGI). The ill-behaved Site B suffers from overloading its CPU share. This results in a 10% loss of aggregated performance compared to the ideal case of a replicated FCGI under peak load. The reason for this is that the ill-behaved site uses its resources mainly on serving static HTTP requests. Only when the number of queued-up FCGI requests is large will its FCGI requests be processed. During those times Site B operates mostly sequentially.

Without changing Apache this problem could not have been solved using RC's or any other approach presented in Section 2, because the resource binding for the FCGI must be dynamic, assuming it cannot be replicated.

2000-04-17