Post on 05-Jan-2016
Providing Differentiated Levels of Service in Web Content Hosting
Jussara Almeida, etc...
First Workshop on Internet Server Performance, 1998
Computer Architecture Lab. CS Dept. KAIST
2000/9/18
Kim, Sung-Wan
2/16
Contents
• Introduction
• Methodology
• Design & Implementation
• Experiment & Results
• Limitations of the study
• Conclusions
3/16
Introduction (1/2)
• 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
4/16
Introduction (2/2)
• Priority-based request scheduling– Performance metric
• QoS - Response time to the request
– Method of improving performance
• Restrict the maximum number of concurrent processes at each priority
– Approaches
• User-level & kernel-level
5/16
Methodology
• Priority of requests– Based on customer who pay, not 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
• Performance metric– Response time
• The average latency time taken by the server
• After accepting a connection, until closing the connection
6/16
Design & Implementation (1/3)
• Scheduling policies– 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
• Conserving policies– Non-work conserving
• Allow requests to occupy only slots of the same type
– Work conserving
• Does NOT allow above
High-priority
Low-priority
Queue
request
or or
7/16
Design & Implementation (2/3)
• 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
8/16
Design & Implementation (3/3)
• Kernel-level approach– Parameters
• The number of priority levels• The number of concurrent processes at each level• The priority value assigned to a blocked process
– SLEEPING_PRIORITY
– 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
• New system calls– initialize_priority_scheme, my_set_priority, my_release_priority
9/16
Experimental Setup
• For user-level approach– Sun SparcStation
• Two 66MHz CPUs, 64 MB RAM, Solaris 2.4, 100 Mbps Ethernet
• For kernel-level approach– DEC 90MHz Pentium
• 32 MB RAM, Linux 2.1.54, 10 Mbps Ethernet
• HTTP server : Apache 1.3b2, KeepAlive off
• Client : WebStone benchmark
– 6 machines, 5 client processes per machine
– 2 different workloads
10/16
Results (1/6)- User-level approach (1/3)
• Non-work conserving
11/16
Results (2/6)- User-level approach (2/3)
• Non-work conserving
12/16
Results (3/6)- User-level approach (3/3)
• Work conserving
13/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
14/16
Results (5/6)- Kernel-level approach (2/3)
Average latency for workload WA
Average latency for workload WB
15/16
Results (6/6)- Kernel-level approach (3/3)
Average latency for workload WB using non-work conserving and SLEEPING_PRIORITY = -1
16/16
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
• Various mix of high-priority and low-priority requests
17/16
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
• Critique– Kernel modification– Too small benefit for high-priority, too much loss for low-priority– Thresholds parameter– Request ratio - High-priority : low-priority = 1 : 1 ?– Separated server for high-priority requests