1 / 10

Introduction

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

sanjiv
Download Presentation

Introduction

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Architecture client Accept Request Send Response Normal Request Processing Web Server Read Request Log Request Deregister Request Register Request Request Complete Scheduler Module Registration QoS Addition Deregistration Resource Manager QoSBoard Module

  3. Architecture • A request is assigned to a process. • Register Request occurs when a request arrives and before any processing begins. • Registration suspends processing of the request until the Scheduler decides processing should be resumed. • 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.

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

  5. Scheduling Algorithm (Version 2) • Two queues: A and B • 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. • Similar to Version 1, except there is now a limit on the number of A processes allowed to run at any one time.

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

  7. Scheduling Algorithm (Version 3) • 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 • If the number of complaints is equal to max_complaints then max_proc_B is reduced. • The variable representing the number of complaints is set to 0. If it again exceeds max_complaints, max_proc_B is reduced.

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

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

  10. Results and Future Research • Initial results are promising, but they show that there are many factors to take into account. • We are especially interested in architecting out a solution that makes it easy for developers to implement different scheduling algorithms tailored for their sites. • 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.

More Related