1. Handling Web Hotspots at Dynamic Content Web Sites Using DotSlash Weibin Zhao Henning Schulzrinne {zwb,hgs}@cs.columbia.edu Columbia University Dagstuhl Workshop October 4-6, 2004

2. 09/10/2004 DotSlash2 The Problem Web hotspots Short-term dramatic surge of request rate Flash crowds, the Slashdot effect Dynamic content web sites CPU-bound, request rate supported is low Hard to cache dynamic content Bottleneck at different servers Database server: on-line bookstore (Amazon) Web server: auction (eBay), bulletin board (Slashdot)

3. 09/10/2004 DotSlash3 Our Approach: DotSlash Rescue system Different sites, mutual aid Cost effective: for rare events Self-configuring Build an adaptive distributed web server system on the fly (fully automated) server directory mutual-aid community server directory

4. 09/10/2004 DotSlash4 Aside: Solution Approaches Change client side behavior see NYU Coral system prefix URL with Coral URL Change server only our approach could use P2P network, but really need capacity estimation, not ID mapping

5. 09/10/2004 DotSlash5 DotSlash Overview Workload monitoring: CPU/Link Rescue server discovery: different sites Load migration: HTTP redirect, DNS-RR Dynamic virtual hosting: on the fly Adaptive rescue control: desired load region originrescue (1) (2) (1) (2)(3) reverse caching proxy Static content DNS client1 client2

6. 09/10/2004 DotSlash6 Implementation Apache module Dynamic DNS: dot-slash.net Service discovery: enhanced SLP BINDmSLP HTTP SHM SLP DNS DSRP Other DotsdApache Dotsd Mod_dots client

7. 09/10/2004 DotSlash7 DotSlash for Dynamic Content Remove the web server bottleneck Dynamic script replication LAMP configuration origin serverdatabase rescue server MySQLApache (5) PHP (6) PHP (1) (2) (3) client (4)

8. 09/10/2004 DotSlash8 Dynamic Script Replication Operations at rescue server Map a redirected URI to a script file Trigger 404 handler if the script file not found Retrieve the script file Handle file inclusions Set query variables Run the script by invoking native include Operations at origin server If a request is from a rescue server and for dynamic content, return the script file

9. 09/10/2004 DotSlash9 Handling File Inclusions The problem A replicated script may include files that are located at the origin server Assume: included files under DocumentRoot Approaches Renaming inclusion statements Need to parse scripts: heavy weight Customized error handler Catch inclusion errors: light weight

10. 09/10/2004 DotSlash10 Evaluation Experimental Setup Linux machines: Redhat 9.0 HC: 2 GHz CPU, 1 GB memory LC: 1 GHz CPU, 512 MB memory Apache: 2.0.49, DotSlash module PHP: 4.3.6, DotSlash extension MySQL: 4.0.18, open_files_limit, max_connection RUBBoS bulletin board benchmark 19 scripts: 1 KB to 7 KB 439 MB database

11. 09/10/2004 DotSlash11 Increasing Max Request Rate: R No rescue: R=118 With rescue: R=245 #rescue servers: 9 Origin (HC)DB (HC) Rescue (LC) Configuration: Rescue (LC) 245/118>2 CPU: Origin=100% DB=45% CPU: Origin=55% DB=100%

12. 09/10/2004 DotSlash12 Effectiveness No rescue: R=49 With rescue: R=245 245/49=5 origin serverHCLC improvement25 #rescue servers910 Conclusion: remove web server bottleneck Origin (LC) DB (HC) Rescue (LC) Another Configuration: Comparison: #rescue server: 10 Rescue (LC)

13. 09/10/2004 DotSlash13 CPU Utilization Control

14. 09/10/2004 DotSlash14 Workload Migration

15. 09/10/2004 DotSlash15 Handling Worst-Case Workload Settling time: 24 second #timeouts 921/113565

16. 09/10/2004 DotSlash16 Reducing Settling Time and #Timeouts Assign different priorities to rescue requests and client requests Allocate rescue servers in parallel

17. 09/10/2004 DotSlash17 Conclusions Prototype 10-fold improvement for static content web sites Removing the web server bottleneck for dynamic content web sites On-going work DNS-RR experiments PlanetLab experiments for dynamic content Real Slashdot test For further information http://www.cs.columbia.edu/IRT/dotslash