Design, Implementation and Evaluation of a Client Characterization Driven Web Server Balachander Krishnamurthy – AT&T Research Labs Balachander Krishnamurthy – AT&T Research Labs Craig Wills – WPI Yin Zhang – AT&T Research Labs Kashi Vishwanath – Duke University

Users with varying connectivity request a variety of files Web site wants no user to get disinterestedWeb site wants no user to get disinterested Handle requests based on connectivityHandle requests based on connectivity Motivation End Users Web server

Outline of our solution Figure out connectivity : use web server logs Figure out connectivity : use web server logs Classify clients(IPs) :store in shared memory Classify clients(IPs) :store in shared memory  Cluster: group of IPs [KW00] When a page is requested, the Web server: When a page is requested, the Web server:  Identifies client connectivity  Takes action if required: alternate content etc [12/Apr/2003:01:40:22 –0400] “GET /foo.html HTTP/1.0” [12/Apr/2003:01:40:22 –0400] “GET /foo.html HTTP/1.0”

System Architecture Server Log Classification Table (Shared Memory) Classifier User Requests Apache Processes

What is a page access? User clicks: container page page eg. /foo.html User clicks: container page page eg. /foo.html Subsequent requests : embedded objects eg. /img1.gif Subsequent requests : embedded objects eg. /img1.gif At server : how long before the user At server : how long before the user  starts getting the first object ?:E_first  gets the entire page ?: E_last Smoothed means for popular pages Smoothed means for popular pages Classes (poor, rich, normal) – [KW02] Classes (poor, rich, normal) – [KW02]  Poor : E_first >3 and E_last >5  Rich : E_first <=1 and E_last <=2

Modified Apache Server Modification to Apache Modification to Apache  three files, less than 200 lines  http_main.c, http_protocol.c, http_core.c One time overhead One time overhead  Open cluster library  Read in configuration file  /foo.html.gz.p_lc ;.r_mc  Initialize shared memory

Modified Apache Server : Per Request Changes Per Request Changes Per Request Changes  Is it a popular page ( URI ) ?  Lookup class (in shared memory data)  Cluster lookup if IP unavailable  Tailored action if appropriate and log it

Testing: How to choose test pages Proxy logs from a large manufacturing company (Dec 2001) Proxy logs from a large manufacturing company (Dec 2001) Over 100,000 users Over 100,000 users Select 1000 most popular pages Select 1000 most popular pages Download these : April 2002 Download these : April successful pages reconstructed 641 successful pages reconstructed 33% and 66% percentile value for characteristics 33% and 66% percentile value for characteristics  Container bytes, # of Embedded object, embedded bytes  3 x 3 x 3 = 27 buckets of pages

Testing: Distribution for test pages Percentage of pages in each bucket

Server Overhead : Latency increase at client Generate IPs (X-IP header)

Plot of average increase in processing time for the modified server Plot of average increase in processing time for the modified server Stress Test

Placing Clients and Modified Servers Prototype Apache Server with our test site Prototype Apache Server with our test site  Linux – att.com in NJ, USA  Linux – wpi.com MA, USA  FreeBSD – icir.org CA,USA Clients Clients  att:AT&T Labs-Research, NJ,USA  de: Saarbruecken University, Germany  cable: cable modem user, NJ,USA  modem: 56Kbps dialup modem user, NJ,USA  uk:London, U.K via a dedicated 56Kbps line.

Clients: Observed network characteristics uk-icir uk-att cable-icir uk-wpi de-att att-icir att-wpi Spans a wide spectrum

Experiments :Httperf Clients Request similar mix of pages as described earlier Request similar mix of pages as described earlier 200 random requests each 200 random requests each New Headers: X-Server-Actions, X-Class New Headers: X-Server-Actions, X-Class Baseline measure Baseline measure  parallel-1.0 – up to 4 parallel HTTP/1.0 requests Server actions Server actions  Manner of delivery  Compress, serial-1.1, pipeline-1.1, bundle  Amount served  Base-only, half-object,half-resolution

Classifier Stability and Correctness Overall consistent with expectation 90% Rich Moderate Poor

Results : Low throughput client Uk-wpi

Results : medium throughput de-att de-att

Results:Summary

Conclusions What all do we do ? What all do we do ?  Online client classification  Deliver modified server actions  Measure latency reduction to different clients  Compare various actions First to do this in a unified framework.

Conclusions: Server and Classifier Overhead at server Overhead at server  Average:75 usec. Negligible for end-user  Turn off classification during overload  Server poor-content during overload Classification Classification  Close to expectation  Stable over the duration of experiment  Improve by using select pages and better thresholds

Future Other server actions Other server actions  Delta encoding  Policies regarding cacheablility of objects Create a test for clustering Create a test for clustering

Acknowledgement Client testing Client testing  Saarbruecken, Germany  ICIR, USA Proxy logs - Manufacturing company Proxy logs - Manufacturing company

Thanks! Questions ? Slides:

Related Work Mark network packets [NT02] Mark network packets [NT02]  Improve performance of all clients Adapt content based on server load [AB99] Adapt content based on server load [AB99] User’s expectation [BBK00] User’s expectation [BBK00] Alternate admission control and server scheduling policies [CMC01, CR02] Alternate admission control and server scheduling policies [CMC01, CR02] Dynamically altering multimedia content [MB01] Dynamically altering multimedia content [MB01] Explicit client notification e.g. SPAND [ SSK97] Explicit client notification e.g. SPAND [ SSK97]