9/25/2001 Network Computing Lab. EECS. KAIST Kang, Seungwoo

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?