260 likes | 356 Views
Web Server Performance in a WAN Environment. Vincent W. Freeh Computer Science North Carolina State Vsevolod V. Panteleenko Computer Science & Engineering University of Notre Dame. Complex design and interaction Multiple tiers Appliance Web, app, & DB servers
E N D
Web Server Performance in aWAN Environment Vincent W. Freeh Computer Science North Carolina State Vsevolod V. Panteleenko Computer Science & Engineering University of Notre Dame
Complex design and interaction Multiple tiers Appliance Web, app, & DB servers Study performance of web server Cached pages Most testing Simulated load LAN environment Our evaluation adds Simulated WAN environment Small MTU, BW limits, latency Shows some optimization aren’t Large web site
Evaluating a web server • Three parts • Measuring the server • Loading the server • Supporting the server Server demand Net Tiers 2&3 Server load
Net Two ways to load server • Synthetic load • Controlled • Reproducible • Flexible • Only as good as assumptions, mechanisms • Hard to replicate real world • Real-world load • Uncontrolled • Not reproducible (can use traces) • Accurate model of system • Hard to produce extreme or rare conditions • Discussion • Need both • Validate simulations with real-world tests
Net Loading the server • Our tests use synthetic load • Three load-generating tools • Micro-benchmarking tool • Requests a single object at a constant rate • Tests delivery of static, cached documents • Establishes base line
Net Modified SURGE • SURGE • Scalable URL reference generator • Barford & Crovella, U Boston • Emulates statistical distribution • Object & request size • Object popularity • Embedded object references • Temporal locality • Use idle periods • Modifications • Converted from process based to event based To increase number of clients • Server-throttling problem eliminated
Net Delays and limits • Emulate WAN parameters in a LAN • Network delays • Bandwidth limits • Modified kernel and protocol stack • Separate delay queue per TCP connection • Necessary for accurate emulation • More accurate than Dummynet & NISTnet (per interface)
Measuring a web server HTTP Apache, TUX Network TCP/IP OS drivers request reply
Measuring a web server Measure utilization using HW performance counters HTTP Network OS request reply
Test environment Client NIC • OS: Linux 2.4.8 • Node: (server & clients) • Pentium III, 650MHz • 512MB main memory • NIC: • 3COM 3C590 • 100 Mbps ethernet • Direct connect • Software: • Client: microbenchmarking, SURGE, delay/limits • Server: Apache, Tux • Warmed client • No cache misses Server NIC NIC Client NIC
Cost breakdown – file size, Apache • MTU = 536 bytes • Delay = 200 ms • BW = 56 Kbps • Data send rate = 3MB/s Majority of time in interrupt (recv’g) But most data is sent.
Cost breakdown - file size, TUX • MTU = 536 bytes • Delay = 200 ms • BW = 56 Kbps • Data send rate = 6 MB/s • Twice data send rate as Apache. • Essentially all cost in interrupts.
Apache TUX Server send rate 3.0 MB/s 6.0 MB/s Packets rec’d / s 5738 11,991 Packets sent / s 6156 11,878 Interrupts / s 7482 13,974 Concurrent connections 784 1451 Apache versus TUX
Cost breakdown vs. MTU • Surge parameters • Size = 10 KB • Delay = 200 ms • BW = 56 Kbps • Data send rate = 6 MB/s
Effects of network delay • Surge parameters • MTU = 536 bytes • Size = 10 KB • BW = 56 Kbps • Data send rate = 6 MB/s
Effects of bandwidth limits • Surge parameters • MTU = 536 bytes • Size = 10 KB • Delay = 200 ms • Data send rate = 6 MB/s 20% decrease in overhead from 28kbps to infinity
Persistent connections 10% decrease going from 1 to 16 requests per connection • Surge parameters • MTU = 536 bytes • Size = 10 KB • Delay = 200 ms • Size = 10 KB • Data send rate = 6 MB/s
Copy and checksumming • Surge parameters • MTU = 536 bytes • Size = 10 KB • Delay = 200 ms • Size = 10 KB • Data send rate = 6 MB/s
Re-assess value of some optimizations • Copy & checksumming avoidance • LAN: 25-111% copy or 21-33% copy & 10-15% checksum • WAN: 10% combined • Select optimization • LAN: 28% • WAN: < 10% • Connection open/close avoidance (HTTP 1.1) • LAN: “greatly”, “significantly” • WAN: < 10%
Conclusion • Most processing in protocol stack and drivers • Small MTU size increases processing cost • Little effect from • Network delay • Bandwidth limitations • Persistent connections • End-user request latency depends • Primarily on connection bandwidth • Secondarily on network delay • Future • Dynamic & uncached pages • Add packet loss Work supported by IBM UPP & NSF CCR9876073 www.csc.ncsu.edu/faculty/freeh/
Apache Largest install base User space Process-based model TUX Niche server Kernel space Event-based model Aggressive optimizations Copy/checksum avoidance Object, name caching Web (HTTP) servers
Measuring a web server HTTP Network OS request reply
Interrupt coalescing • Decreases interrupt scheduling overhead • Interrupt every 2 ms