november 26, 2002telesim research group1 performance and robustness testing of wireless web servers...

November 26, 2002 TeleSim Research Group 1

Performance and Robustness Testingof Wireless Web Servers

Guangwei BaiKehinde OladosuCarey Williamson


1. Introduction and Motivation Observation: the same wireless technology that allows a Web client to be mobile also allows Web servers to be mobile Idea: portable, short-lived, ad hoc networks Possible applications:

o classroom area networks, seminarso press conferences, media eventso sporting events, gaming, exhibitionso conferences and trade showso disaster recovery sites, field work, etc.


Background: Portable Networks Assumptions: the characteristics of a portable short-lived network are:

o set it up when needed; tear down aftero only needed for minutes or hourso when may not be known a priorio where may not be known a priorio no existing infrastructure of any kindo general Internet access not availableo general Internet access not requiredo pre-defined content; target audienceo 1-100 users; mobile; limited bw needed


2. Objectives to assess feasibility of portable networks to benchmark the performance capabilities and limitations of an Apache Web server in a wireless ad hoc network to identify the performance bottlenecks to understand impacts of different factors

o number of clientso Web object sizeo persistent connectionso transmit power (energy consumption)o wireless channel conditions


3. Experimental Setup

• Compaq Notebooks (1.2GHz Pentium III, 128MB RAM, 512 KB L2 cache, Cisco Aironet 350 network cards)• RedHat Linux 7.3, httperf, Apache 1.3.23, SnifferPro 4.6• Network: 11 Mbps IEEE 802.11b wireless LAN, ad hoc mode


Experimental Setup (Cont’d)

• IEEE 802.11b: a standard for wireless LANs Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA), up to 11 Mbps data rate at physical layer

• ad hoc modeframes are addressed directly from sender to receiver

• httperf Web benchmarking software tool developed at HP Labs

• Web server: Apache (version 1.3.23)Process-based, flexible, powerful, HTTP/1.1-compliant

• SnifferPro 4.6real-time capture, recording all wireless channel activity,enabling protocol analysis at MAC, IP, TCP and HTTP layers

7

4. Experimental Design

Factor Levels Number of Clients 1, 2, 4HTTP Transaction Rate (per-client) 10, 20, 30, …, 160

HTTP Transfer Size (KB) 1, 2, 4, 8, …, 100Persistent Connections no, yesHTTP Requests per Connection 1, 5, 10, 15, …, 60Transmit Power (mW) 1, 5, 20, 30, 50, 100

Client-Server Distance (m) 1, 10, 100

• Impacts of different factors on wireless Web server performance (one-factor-at-a-time)

Experimental Factors and Levels

• Performance metrics– HTTP transaction rate, throughput, response time, error rate at Application Layer,– TCP connection duration at Network Layer– Transmit queue behaviour at Link Layer,


5. Measurement Results and Analyses - Expt 1: Request Rate - Expt 2: Transfer Size - Expt 3: Number of Clients - Expt 4: Persistent Connections - Expt 5: Transmit Power - Expt 6: Wireless Channel


Experiment 1: Request Rate

Purpose: to determine the range of feasible and sustainable loads for the wireless Web server

Design: • Number of Clients: 1• HTTP transaction rate: 10, 20, …, 160 req/sec• HTTP transfer size: 1 KB (fixed)• Persistent connections: no• Transmit power: 100 mW• Client-server distance: 1 meter (on same desk)


Wireless Web Performance at Application Layer

Main observation:• As the offered load increases: linear increase instability lower plateau• Peak throughput < 1 Mbps for 1 KB transfers


Transmit Queue Behaviour for Experiment 1

Main observation: Wireless LAN is the bottleneck• Packet drops occur from link-layer queue (client side)• Even before they get on the wireless LAN!!!Reason:• No flow control / backpressure mechanism• Note: default queue size is 100 in the Linux kernel


Wireless Web Performance at Application Layer (Cont’d)

Main observation:• the response time is about 9 ms at low load, increase significantly to over 2 sec at high load (>85 req/sec)• failures occur frequently under overload


Measurement at Network Layer

Overload: 100 req/secQueue buildup,Packet drops, Retransmissions,TCP resets

Low load: 10 req/secStable performance Mean: 9.7ms

Medium load: 50 req/secGreater variation, 2 spikes Mean: 10ms

High load: 80 req/secMore variability, some spikes, slight skew


Experiment 2: Transfer Size

Purpose: to study impact of HTTP response size

Design: • Number of Clients: 1• HTTP transaction rate: 10 req/sec (fixed)• HTTP transfer size (KB): 1, 2, 4, 8, …• Persistent connections: no• Transmit power: 100 mW• Client-server distance: 1 meter (on same desk)



General observation:

as HTTP transfer sizeincreases, mean TCP connection duration increases, as does thevariance of distribution.


Light load: 8 KBDuration: 24 msec Throughput: 2.8 Mbps

Overload: 64 KBDuration: >100 msec Throughput: 4.1 Mbps

Medium load: 32 KBDuration: 67 msec Throughput: 3.9 Mbps



Experiment 3: Number of Clients

Purpose: to study impact of high load generated by multiple clients

Design: • Number of Clients: 2, 3, 4• HTTP transaction rate: 10, 20, …, 160 req/sec• HTTP transfer size: 1 KB (fixed)• Persistent connections: no• Transmit power: 100 mW• Client-server distance: 1 meter (on same desk)

18

Wireless Web Performance at Application Layer (4 Clients)


Main observation:• 4 clients share network and server resources equally• 30% higher aggregate throughput (110 conns/sec)• bottleneck is now at server network card (drops!!)

Wireless Web Performance at Application Layer (4 Clients)


Wireless Web Performance at Application Layer (2 or 3 Clients)


Wireless Web Performance at Application Layer (2 or 3 Clients)

Main observation: unfairness problem at high loads:

one client obtained a higher proportion of the throughput at expense of another (don’t know why?)


Experiment 4: Persistent Connections

Persistent Connections:• Multiple HTTP transactions can be sent on the same TCP connection.• amortize overhead of TCP connection processing• reduce memory consumption for TCP state

Purpose of this experiment: to study impact of persistent connection on wireless Web performanceDesign:

• Number of Clients: 1 and 2• HTTP transaction rate: 10 req/sec (fixed)• HTTP transfer size: 1 KB (fixed)• Persistent connections: yes• Transmit power: 100 mW• Client-server distance: 1 meter (on same desk)


Achieved Throughput for Experiment with Persistent Connections

Main observation:• Peak throughput: 3.22 Mbps, 3.5x improvement over non-persistent connections (0.9 Mbps),• two clients share the server and network resources equally


Experiment 5: Transmit Power

Energy consumption- an important issue for mobileClients and Server.

Purpose: to see what transmit power is required for acceptable performance in classroom setting

Design: • Number of Clients: 1• HTTP transaction rate: 10 req/sec (fixed)• HTTP transfer size: 1 KB (fixed)• Persistent connections: no• Transmit power: 1, 5, 20, 100 mW• Client-server distance: 10 meter (same floor)



General observation:

If transmit power<10 mW:• MAC-layer retransmits• rightward skew• unacceptable perf.

If transmit power20 mW:• acceptable performance


Experiment 6: Wireless Channel Characteristics

Wireless Internet is characterized by limitedbandwidth, high error rates, and interference.

Purpose: to study the impact of the wireless channel characteristics on wireless Web performance

Design: • Number of Clients: 1• HTTP transaction rate: 10 req/sec (fixed)• HTTP transfer size: 1 KB (fixed)• Persistent connection: no• Transmit power: 100 mW• Client-server distance: 1m, 10m, 100m


Low load: 10 req/secSignificant skew to thetail of the distribution,Some periodicity (why?)

Medium load: 50 req/secSignificant skew to thetail of the distribution

Measurement at Network Layer (100m scenario)


6. Summary and Conclusions

What we did: wireless Web server, portable nw• Application-layer measurements (httperf)• Network-layer measurements (Wireless Sniffer)

Our results show:• Server capability: 100 conn/sec for non-persistent HTTP with throughputs up to 4 Mbps (adequate?)• Bottleneck: at wireless network interface• Some “network thrashing” for large HTTP transfers when the network utilization is high (aborts, resets)• Effect of wireless channel on performance at TCP and HTTP-level (MAC-layer retransmits)• Power consumption issue for mobile client and server


7. Future Work

Explaining the anomalies (fairness, periodicity) Better system instrumentation (Linux) More realistic Web workloads Larger WLAN testing (classroom scenario) Repeat experiments with IEEE 802.11a (55 Mbps) Kenny’s M.Sc. Thesis... Another paper?

november 26, 2002telesim research group1 performance and robustness testing of wireless web servers...

Documents

hours o

exhibitions o conferences

o classroom area networks

seminars o press conferences

kind o general internet

media events o sporting

telesim research group2

telesim research group4