Handling Web Hotspots at Dynamic Content Web Sites Using DotSlash

1
Handling Web Hotspots at Dynamic Content Web
Sites Using DotSlash

• Weibin Zhao
• Henning Schulzrinne
• zwb,hgs_at_cs.columbia.edu
• Columbia University
• Dagstuhl Workshop
• October 4-6, 2004

2
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
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
server
mutual-aid community
server
server
server
server
directory
directory
4
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
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

reverse caching proxy
origin
rescue
(2)
(3)
(1)
client1
(2)
(1)
DNS
client2
Static content
6
Implementation

• Apache module
• Dynamic DNS dot-slash.net
• Service discovery enhanced SLP

SHM
Other Dotsd
Apache
Dotsd
Mod_dots
DSRP
client
HTTP
SLP
DNS
BIND
mSLP
7
DotSlash for Dynamic Content

• Remove the web server bottleneck
• Dynamic script replication
• LAMP configuration

MySQL
Apache
origin server
database
(1)
(2)
client
(4)
(5) PHP
(6) PHP
rescue server
(3)
Apache
8
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
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
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
Increasing Max Request Rate R
Configuration
Rescue (LC)
Rescue (LC)
Rescue (LC)
Rescue (LC)
Rescue (LC)
Rescue (LC)
Origin (HC)
DB (HC)
Rescue (LC)
Rescue (LC)
Rescue (LC)
No rescue R118
CPU Origin100 DB45
With rescue R245
rescue servers 9
CPU Origin55 DB100
245/118gt2
12
Effectiveness
Another Configuration
Rescue (LC)
Rescue (LC)
Rescue (LC)
Rescue (LC)
Rescue (LC)
Origin (LC)
Rescue (LC)
DB (HC)
Rescue (LC)
Rescue (LC)
Rescue (LC)
Rescue (LC)
With rescue R245
No rescue R49
rescue server 10
245/495
Comparison
origin server HC LC
improvement 2 5
rescue servers 9 10
Conclusion remove web server bottleneck
13
CPU Utilization Control
14
Workload Migration
15
Handling Worst-Case Workload
Settling time 24 second
timeouts 921/113565
16
Reducing Settling Time and Timeouts
Allocate rescue servers in parallel
Assign different priorities to rescue requests
and client requests
17
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