Composibility

 

A key design goal of Active Names is composibility. Not only should applications be able to inject extensions into the network, but they should be able to combine these extensions to provide new services and optimize existing ones. In this subsection, we first examine the costs composibility imposes on the system. We then study the benefits composable extensions bring to a key problem: web caching. Caching is a key technique for reducing both long-haul bandwidth and client-perceived latency. Table 1 breaks down the reason for web caching's relatively low hit rates that hang stubbornly near or below 50% [19,27]. This table suggests that composing different extensions may be a key technique for addressing the web caching problem. Moreover, these extensions are likely to be provided and implemented by a number of different entities, ranging from clients, to service providers, to third party software vendors. The experiments in this section demonstrate how the Active Name framework is utilized to compose multiple independent extensions, resulting in greater end-to-end performance gain than available from any single approach.

Our continuation-passing architecture imposes the overhead of indirection through the ``after-methods'' script when one Active Name program transfers control to another. On a Sun Ultra-10 with a 300MHz UltraSparc-II process running JDK 1.2 fcs, it takes 3.2 $\mu$s for one Active Name program to call another and return via this mechanism, compared to 0.2 $\mu$s if it were allowed to make the procedure call directly. Although this is more than an order of magnitude worse, the performance is sufficient to support the composition of relatively coarse-grained services such as we envision.

To determine whether composibility is worth this cost, we compare the cost the composition of several server-initiated customizations against the cost of a client-initiated customization. The semantics of the sample service we implement are that when a client fetches a base page, the service i) uses the server-side include interface to update the page for the current request, ii) randomly selects two out of eight candidate ``banner ad'' inline images, repeating the random selection on each viewing of the page, and iii) logs the provided cookies the advertisements selected for each request. We implement these server semantics in two ways. First, we construct them using standard mechanisms that run at the server: the server uses server-side includes to update the page and to execute a perl program that randomly selects advertisements to include on the page; we do not add additional logging to that already provided by the HTTP server. Second, we implement a version of the service by delegating a portion of the HTTP namespace to a set of three Active Name programs (provided by the service). The default HTTP namespace delegates control of all HTTP requests destined to www.cs.utexas.edu/users/anonymized/service to a ``controller'' Active Names program that alters the return path for such requests through a ``ssi'' Active Name program that provides server side include semantics and through an ``advertise'' Active Name program that does advertisement rotation and logging. In the first configuration, all requests for the base page must go to the server; requests for the inline images may be cached. In the second configuration, once the delegation Active Name programs have been installed, both the base page and the inline images may use the cache because cached results will pass through the ssi and the advertise Active Names programs before being returned to the client.

For the client-initiated customizations, clients use Active Names to customize their namespace to transcode images sent across a slow modem link. Because clients control their own namespace, adding this transformation to the pipeline is straightforward. The main subtlety is that clients cannot store the distilled images in the standard HTTP cache lest one client's mapping of the URL to the customized image disturb other clients. Rather than cache such results in the HTTP namespace, the client caches such results in the ``distiller'' namespace instead.

 

Source of Miss Fraction of Requests Available Approaches Client/Server Initiated

Compulsory 19%-30%[48] 45%(ISP) Prefetching [28,35,44] either

Server replication [50] or push caching [30] server

Increase number of clients sharing cache system [11,19,27,48] client

Transcoding [23,4], compression and delta-encoding[40] client or either

Consistency verify (unmodified) 10%(ISP) 2-7%[19] 4-13%[6] Server-driven consistency [37,56] server

Consistency miss 0-4%[19] delta-encoding[40] either

Dynamic (cgi or query) 21%(ISP) 0-34%[38] Active cache [12], HPP [18] server

TREC [49] server

Pragma: no-cache 9%(ISP) 5.7-7.2%[27] Hit logging server

Active cache [12], function-shipping server

Server-driven consistency [56] server

Redirection 3.7%(ISP) Server selection/anycast [9,57] server

Our experimental set up consists of three machines. The client, a 133 MHz Pentium machine running Microsoft NT3.5 and Sun JDK 1.2 beta 3, communicates with the proxy, a 300MHz Sun UltraSPARC-II machine running Solaris 5.6 and JDK 1.2 fcs, over a 28.8 kbit/s modem. Both the client and proxy run the Active Name framework. The service being tested is hosted on a departmental web server running on a dual-processor Sun SPARCServer 1000e running Solaris 5.5.1 and the Netscape Enterprise Server 3.0(J) HTTP server. The proxy and server are connected by a department-wide switched 100 Mbit/s Ethernet.

The base page and its header are between 657 bytes and 2393 bytes (depending on where customization occurs) and the advertisement banner images range in size from 8421 to 16928 bytes before distillation and from 2595 to 4365 bytes after distillation. The JAR files containing the server's controller, advertise, and ssi customization programs are 2622, 4700, and 3274 bytes, respectively. We begin the experiment with cold caches, except that we fetch two unrelated HTTP documents through the system to cause the JVMs to pre-load most of the basic classes associated with the system's standard HTTP data path, and we fetch two unrelated image files to cause the proxy to load the client's distiller Active Name program.

Figure 4 shows four cases representing the permutations of distillation (on/off) and server customization (on/off). Our client driver program uses the Active Name system running at the client to fetch the base document and then, using parallel connections, to fetch all inline images specified by the base document. After the driver receives each page and associated inline images, it pauses five seconds and repeats the process. The variation in response times from request to request is caused by cache hits and misses to the base page and the randomly selected inline images.

With respect to server customizations, there are three phases to consider. On the first request, no delegation has yet been specified to the client's Active Name system, so the ``Server: on'' performance closely matches the ``Server: off'' performance. Reacting to the delegation directive in the first request, the client's Active Name system spawns a background thread to download and install the specified customizations. This background thread is active during the second phase of the experiment--request two for the case when distillation is turned off and requests two and three when distillation is on. As a result, performance for these requests is noticeably worse under server customization than for the standard case. In the third phase--after request three--the client has installed the server customization into its namespace and thus no longer needs to go to the server for advertisement rotation, hit logging, or server side include expansion. Performance is now significantly better under the customized version (modulo cache hits to the inline images). For example, as Figure 4(a) indicates, after the cache is warm and when the inline images are hits, the ``Server: on'' case provides response times under 0.26 s while the other case requires over 1.3 s per request. In this situation, the Active Names system provides a 5-fold performance improvement. This result is particularly significant in light of human factors studies that suggest that driving computer response time from about a second to significantly less than a second may result in more than a linear increase in user productivity as the system becomes truly interactive [32,10].

 

Figure 4: (a) Per-request and (b) cumulative average performance of customizations of the HTTP namespace. 

Figure 4 also shows that distillation significantly improves performance for the initial series of requests, and makes little difference once the images are cached at the client. For example, when server customization is turned on, the five most expensive requests require an average of 15.3 s without distillation, whereas the five most expensive requests averaged 6.67 s under distillation, a speedup of 2.3. Without server customization, the five most expensive requests average 14.1 s and 6.39 s when distillation is off or on respectively, for a speedup of 2.2 for distillation.

Other researchers have noted the advantage of server-controlled caching [12] and distillation [23]. The above experiment suggests that a combination of server and client customizations may be particularly effective. On average for the 20-request sequence, the combination outperforms the distillation-only case by 50% and it outperforms the server-only case by 104%.