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