9/25/2001 network computing lab. eecs. kaist kang, seungwoo
DESCRIPTION
Providing Differentiated Levels of Service in Web Content Hosting J ussara Almeida, Mihaela Dabu, Anand Manikutty and Pei Cao First Workshop on Internet Server Performance, 1998. 9/25/2001 Network Computing Lab. EECS. KAIST Kang, Seungwoo. Contents. Introduction Methodology - PowerPoint PPT PresentationTRANSCRIPT
Providing Differentiated Levels of Service in Web Content Hosting Jussara Almeida, Mihaela Dabu, Anand Manikutty and Pei Cao
First Workshop on Internet Server Performance, 1998
9/25/2001Network Computing Lab. EECS. KAISTKang, Seungwoo
2
Contents
Introduction Methodology Design & Implementation Experiment & Results Limitations of the study Conclusions
3
Introduction Increased Web content hosting
Many servers charge fees for the Web service Customers expect quality of service proportional to the fee
Apache Most used Web server FCFS(first-com first-served)
doesn’t support for differentiated quality of service
Objective To provide differentiated levels of service by priority-
based request scheduling Focus on server QoS, not network QoS Single-machine server system
4
Methodology (1/2) Priority-based approaches
Two levels (high, low) of quality priority based on requested documents
Approaches User-level
Add a scheduler process to Apache Kernel-level
Both Apache and Linux kernel by adding new system calls Mapping from request priorities into process priorities Keeping track of which processes are running at each priority level
5
Methodology (2/2)
Performance metric Response time
The average latency time taken by the server After accepting a connection, until closing the connection
6
Design & Implementation (1/5)
Scheduling policies Preemptive at kernel-level, non-preemptive at user-level Sleep policy : Upon receiving a request Wakeup policy : In place of a completed request
Implementation Maximum thresholds : A fixed number of slots for each priority
level Queue for blocked requests
High-priority
Low-priorityQueue
request
or or
7
Design & Implementation (2/5) Conserving policies
Non-work conserving Allow requests to occupy only slots of the same type
Work conserving Not allow a slot to go empty Allows requests to occupy slots of a different type
High-priority
Low-priorityQueue
request
or or3 requests
4 requests
8
Design & Implementation (3/5) User-level approach
A master process spawn a child process for each request and a Scheduler process
The child process determines its priority from URL Maps the customer name into a priority value
Master process
Schedulerspawn
Childprocess
#1
Child process
#2
Child process
#3
spawn
requests
request scheduling
sleep or wakeup policy
9
Design & Implementation (4/5) Kernel-level approach
Parameters The number of priority levels The number of concurrent processes at each level The priority value The priority value assigned to a blocked process
SLEEPING_PRIORITY
New system calls initialize_priority_scheme my_set_priority my_release_priority
10
Design & Implementation (5/5) Roles of kernel
Maps request priority to a process priority Scheduling (sleep & wake-up policy) Wake-up
Decides the priority level of the processes to be unblocked Choose the oldest process
Process
kernel
call
Sleep policy Wakeup policy
11
Experimental Setup (1/2) HTTP server : Apache 1.3b2, KeepAlive off
For user-level approach Sun SparcStation
Two 66MHz CPUs, 64 MB RAM, Solaris 2.4, 100 Mbps Ethernet
Client : WebStone 6 machines, 5 client processes per machine
12
Experimental Setup (2/2) For kernel-level approach
DEC 90MHz Pentium 32 MB RAM, Linux 2.1.54, 10 Mbps Ethernet
Client : WebStone 2 independent WebStone benchmarks on the same machine 15 client processes for one specific type
2 different workloads
13
Results (1/6)- User-level approach (1/3)
Non-work conserving
14
Results (2/6)- User-level approach (2/3)
Non-work conserving
15
Results (3/6)- User-level approach (3/3)
Work conserving
16
Results (4/6)- Kernel-level approach (1/3)
Average latency for requests of type A & B for both workload with no policy
The configurations used in the experiments
17
Results (5/6)- Kernel-level approach (2/3)
Average latency for workload WA
18
Results (6/6)- Kernel-level approach (3/3)
Average latency for workload WB using non-work conserving and SLEEPING_PRIORITY = -1
Average latency for workload WB
19
Limitations of the Study For truly differentiated QoS
CPU scheduling Replacement policy for buffer cache Disk I/O scheduling to favor high-priority Networking QoS But, focused on only CPU scheduling in this study
Webstone cannot drive the Web server to overload Need to test under bursty loads with various mix of
high-priority and low-priority requests
20
Conclusions Implement the priority-based scheduling Restricting the number of concurrent processes is
a simple and effective strategy Work conserving policy is not adequate when the
thresholds are large Non-work conserving is better for multiple levels of
priority
21
Critique
Is the way to determine priority reasonable? Too small benefit for high-priority, too much loss
for low-priority Is modifying kernel good approach? If requests of the same type are explosive?