Post on 03-Feb-2022
transcript
Comparison of Web ServerArchitectures: a MeasurementStudy
Enrico Gregori, IIT-CNR, enrico.gregori@iit.cnr.it
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
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