1. Nikolaos Vasiliou and Hanan Lutfiyya The University of Western Ontario London, Ontario, Canada Differentiated Quality of Service for Web Servers for Electronic Commerce Applications

2. Introduction l Consumers do not want to be kept waiting when browsing, selecting, or paying for products on-line. l Consumers are annoyed by delays and failures. l Consumers expect a high-level of quality of service and are sometimes willing to pay for it.

3. Architecture client Accept Reques t Read Re quest Register Request Send Respons e Log Reques t Deregiste r Request Complet e Registration Deregistration QoSBoar d Module Scheduler Module Resource Manager Normal Request Processing Web Server QoS Addition

4. Architecture l A request is assigned to a process. l Register Request occurs when a request arrives and before any processing begins. Scheduler l Registration suspends processing of the request until the Scheduler decides processing should be resumed. l The request is put on a queue based on the categorization taking place (e.g., by type of request or by type of requestor). The queue is in the QoSBoard.

5. Scheduling Algorithm (Version 1) l Two queues: A and B. l The Scheduler always runs class A requests and only runs class B requests when there are no class A requests. l This can starve out class B requests if there is always a request in the A queue. Obviously, not a good solution.

6. Scheduling Algorithm (Version 2) l Two queues: A and B l Two variables (also stored in QoSBoard): max_proc_A :The maximum number of A processes allowed to run. max_proc_B : The maximum number of B processes allowed to run. l Similar to Version 1, except there is now a limit on the number of A processes allowed to run at any one time.

7. Scheduling Algorithm (Version 2) l Our experimental results show that this works best when max_proc_B is relatively small. l However, by keeping max_proc_B small (and static) means that we may waste computing resources if there aren’t that many A requests. l These resources could have gone to B requests.

8. Scheduling Algorithm (Version 3) l The difference between this algorithm and the second is that the scheduler doesn’t distinguish between A processes and B processes unless an A process complains that it is waiting too long l If the number of complaints is equal to max_complaints then max_proc_B is reduced. l The variable representing the number of complaints is set to 0. If it again exceeds max_complaints, max_proc_B is reduced.

9. Scheduling Algorithm (Version 3) l max_proc_A and max_proc_B are initially set to the same value. l As long as A processes aren’t complaining then B processes can be run. l This is a more effective use of resources.

10. Implementation l We use the Apache Web Server l The QoSmodule is implemented as shared memory between request processes and the Scheduler (which is a separate process).

11. Results and Future Research l Initial results are promising, but they show that there are many factors to take into account. l We are especially interested in architecting out a solution that makes it easy for developers to implement different scheduling algorithms tailored for their sites. l We will also look at other ways of differentiating between users. Example: If a user is idle for more than n time units then the process associated with the request is given a lower priority.