Comparison of Web Server Architectures: a Measurement Study

22
Comparison of Web Server Architectures: a Measurement Study Enrico Gregori, IIT-CNR, [email protected]. it Joint work with Marina Buzzi, Marco Conti and Davide Pagnin Workshop Qualità del Servizio nei Sistemi Geograficamente Distribuiti 9-10 Giugno 2004 Palazzo Mattei - Villa Celimontana, Roma

Transcript of Comparison of Web Server Architectures: a Measurement Study

Comparison of Web ServerArchitectures: a MeasurementStudy

Enrico Gregori, IIT-CNR, [email protected]

Joint work with

Marina Buzzi, Marco Conti and Davide Pagnin

WorkshopQualità del Servizio nei Sistemi Geograficamente Distribuiti

9-10 Giugno 2004 Palazzo Mattei - Villa Celimontana, Roma

E. Gregori – Roma, 9 giugno 2004

Motivation

We started a study an geographically replicated WEB serversduring the sabbatical year that Prof. Fabio Panzieri spent inCNR

The Quality of Service perceived by users is the dominant factorfor the success of an Internet-based web service and the targetof geographical replication is to improve it by bringing theinformation closer to the user

Geographical replication has significant impact on the serverload and policies for geographical replication cannot beevaluated without a precise characterization of the web serverbehavior

E. Gregori – Roma, 9 giugno 2004

Selected Previous papers

Conti, M. Gregori, E. Panzieri, F. Load Distribution among Replicated WebServers: A QoS-based Approach, Proc. Second ACM Workshop on InternetServer Performance (WISP'99), Atlanta, Georgia, May 1, 1999.

Conti, M. Gregori, E. Panzieri, F. QoS-based Architecture for GeographicallyReplicated Web Servers, Cluster Computing Journal, 4, 2001, pp. 105-116.

Conti, M. Gregori, E., Lapenna, W. “Content Delivery Policies in Replicated WebServices: Client-side vs Server-side, Cluster Computing Journal (to appear).

Conti, M. Gregori, E., Lapenna, W. “Client-Side Content Delivery Policies inReplicated WebServices: Parallel Access vs. Single Server Approach”,Performance Evaluation Journal (to appear).

E. Gregori – Roma, 9 giugno 2004

Motivation for Replicated WEB Servers

Client side vs Server side

Performing data distribution structure closer

to Internet structure

E. Gregori – Roma, 9 giugno 2004

Objective of this study

An accurate model of the web server behavior is essential forevaluating policies for replicated web server web servers

We initially started using simple queueing models tocharacterize the WEB servers but we need an environment formeasuring performance of real servers

To understand the key elements in web server performancecreation of a controlled test-bed environment which allows toanalyze web server performance in a simple and effective wayanalysis of two different web server architectures and theirperformances, with particular focus on discovering bottlenecks

E. Gregori – Roma, 9 giugno 2004

HTTP &TCP and Overload

E. Gregori – Roma, 9 giugno 2004

Measurement of a live system

The approach of directly evaluating performances ofa real web server suffers from difficulties related to

irreproducibility of real workloads

highly unpredictable behavior of the Internet

need for non-intrusive measurement of a live system

E. Gregori – Roma, 9 giugno 2004

Measurement of a live system

The alternative is evaluation through generation ofsynthetic HTTP client traffic in a controlledenvironment requires great care as there severalparameters limiting the performance.

E. Gregori – Roma, 9 giugno 2004

Synthetic WorkloadGeneration Tool

Httperfis capable of sustaining server overloadleaves a nearly total freedom as to the kind of workload andmeasurements to be performed

Parametersnumber of HTTP requests/sectotal number of requests to performusers’ think timerequest timeout....

It is crucial to avoid exhausting the available sockets of the load generator.This means thatstarting from about 60,000 total available sockets and considering that the TCP TIME_WAIT status lasts 60seconds in many TCP implementations, we have about 1,000 sockets available per second.

Furthermore, we have to consider the chosen request timeout and divide those 1,000 availablesockets by the request timeout, and then subtract the mean number of established connections to get an idea ofthe limit of maximum number of requests per second that a single client machine can generate

E. Gregori – Roma, 9 giugno 2004

Introducing WAN impact

Dummynet for introducing WAN delays in the routermachine

Flexible tool to modify delay and throughput, i.e., goodmodeling of the Internet bottleneck

E. Gregori – Roma, 9 giugno 2004

Web Server Architectures

Single-process architecture: Boa 0.94.13has a very efficient and lightweight implementation with verylow memory requirements

Multi-thread architecture: Apache2the newest implementation of the most popular general-purpose web server

E. Gregori – Roma, 9 giugno 2004

Web serverASUS TX97E motherboard with Intel 430TX chipset and with128Mb of memory, OS Linux Redhat 7.3to evaluate the influence of the processor, we switched from aPentium 133Mhz to a Pentium MMX 200Mhz

Experimental test-bedenvironment

Low speed processor are needed to be able to reach saturationcondition

E. Gregori – Roma, 9 giugno 2004

Experimental test-bedenvironment

Clients5-10 clients running httperf: Linux Redhat 7.3, with 2.4.18-19.7.x kernel rpm version and no active firewallHW ranged from K6 III at 450Mhz to Athlon XP 2000+all systems were equipped with full duplex Fast-Ethernetnetwork card and system memory between 256Mb and512Mb

E. Gregori – Roma, 9 giugno 2004

Experimental test-bedenvironment

WAN simulator gateway: a dual Pentium III at 1GHz with 1Gb ofmemory and 2 Fast-Ethernet network adapters, with FreeBSD4.7 release and dummynet option enabled

Dummynet configured to simulate a population of 20% ADSL(128/256Kbit/sec) and 80% MODEM (56Kbit) connections with aRTT delay of 200msec

E. Gregori – Roma, 9 giugno 2004

Average connection setup time

Average response time

Average transfer time

Performance indexes

Server throughputcalculated by summing up all the bytes transferred by a connectiondivided by the duration of the experiment (summed up for all thehttperf instances)

Completed requests per second

E. Gregori – Roma, 9 giugno 2004

Maximum Server Throughput:Cached Files

Boa server, Pentium MMX 200Mhz, 7K single file

Server Throughput

0

500

1000

1500

2000

2500

3000

3500

4000

4500

0100

200

300

400

500

600

700

800

900

1000

requests/sec

KB

/sec

E. Gregori – Roma, 9 giugno 2004

Maximum Server Throughput:Cached Files

Boa server, Pentium MMX 200Mhz, 7K single file, Modem access

Modem - Average Total Connection Time

0500

1000150020002500300035004000

50 150

250

350

450

550

650

750

850

950

requests/sec

ms

ec

Connection Setup Response Transfer

E. Gregori – Roma, 9 giugno 2004

From Cached to Memory-mapped Files

Boa server, single cached file vs 28K mmap-ed files

Average Response Time

400

420

440

460480

500

520

540

560

50 75 100 125 150

requests/sec

ms

ec

MODEM-cached MODEM-mmap-ed

E. Gregori – Roma, 9 giugno 2004

Server Architectures: Single-process versus Multi-threaded

Pentium 133Mhz, 2500 different mmap-ed files

Boa 0.94.13 - Server Throughput

0

1000

2000

3000

4000

5000

0 50100

150200

250300

350400

requests/sec

KB

/sec

4K Files 12K Files 28K FilesApache 2.0.39 - Server Throughput

0

500

1000

1500

2000

2500

3000

0 50100

150200

250300

350400

requests/sec

KB

/sec

4K Files 12K Files 28K Files

E. Gregori – Roma, 9 giugno 2004

Impact of the Processor

Files size 12K, Pentium 133 and 200MMX processors

Server Throughput

0

1000

2000

3000

4000

5000

75 100

125

150

175

200

225

250

275

300

325

350

375

400

425

requests/sec

KB

/sec

boa - P133 apache2 - P133boa - P200MMX apache2 - P200MMX

E. Gregori – Roma, 9 giugno 2004

DISK Accessed Files

Files size 12K, Pentium 133 and 200MMX processors

Server Throughput

0

200

400

600

800

1000

1200

50 55 60 65 70 75 80 85 90requests/sec

KB

/se

c

boa apache2

E. Gregori – Roma, 9 giugno 2004

Summary

Performance measurements of real systems with controllablenetwork and load parameters are extremely important

Preliminary results indicate:

The multi-thread architecture (i.e. Apache2) is CPU intensive but is

less penalized by disk access

Disk access is the most limiting factor for the server throughput

User perceived QoS degrades greatly when the server is

overloaded