1. 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

2. 1 Contents Introduction Methodology Design & Implementation Experiment & Results Limitations of the study Conclusions

3. 2 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. 3 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. 4 Methodology (2/2) Performance metric  Response time The average latency time taken by the server After accepting a connection, until closing the connection

6. 5 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-priority Queue request or

7. 6 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-priority Queue request or 3 requests 4 requests

8. 7 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 Scheduler spawn Child process #1 Child process #2 Child process #3 spawn requests request scheduling sleep or wakeup policy

9. 8 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. 9 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. 10 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. 11 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. 12 Results (1/6) - User-level approach (1/3) Non-work conserving

14. 13 Results (2/6) - User-level approach (2/3) Non-work conserving

15. 14 Results (3/6) - User-level approach (3/3) Work conserving

16. 15 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. 16 Results (5/6) - Kernel-level approach (2/3) Average latency for workload WA

18. 17 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. 18 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. 19 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. 20 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?