1 / 49

Queueing Models with Multiple Classes

Queueing Models with Multiple Classes. CSCI 8710 Tuesday, November 28th Kraemer. The Need for Multiple-Class Models. As you may recall, motivations for constructing multiple-class models for heterogeneous workloads include: To represent different QoS or SLA workload classes

reese-fletcher
Download Presentation

Queueing Models with Multiple Classes

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. Queueing Models with Multiple Classes CSCI 8710 Tuesday, November 28th Kraemer

  2. The Need for Multiple-Class Models • As you may recall, motivations for constructing multiple-class models for heterogeneous workloads include: • To represent different QoS or SLA workload classes • To (more) accurately model requirements of the workload • Example: e-mail server • Heavy user • Light user • Averaging together to create “medium” user is a less accurate model for predictive purposes

  3. Multiclass modeling • Choosing “right” number of classes is difficult • Too few -> inaccurate • Too many -> too complex • Downside of multiclass modeling: • Difficult to obtain parameters for each class

  4. Example: Proposed SLA Agreement • Proposal • Risk Portfolio analysis transactions • Average RT: 3 hours • $15 per transaction • Purchase transactions • Average RT < 1 sec. • $0.50 per transaction • Browsing transactions • Average RT < 2 sec • $0.10 per transaction

  5. Modeling the Proposed System • Class 1: Risk portfolio analysis • Closed, defined by service demands and number of processes in execution during the “peak hour” • Class 2: Online purchase transactions • Open, defined by service demands and average arrival rate during a “peak minute” • Class 3: Browsing transactions • Open, defined by service demands and average arrival rate during a “peak minute”

  6. Simple Two-Class Model

  7. Simple Two-Class Model • During peak hours, system is under heavy load • Four transactions are in execution almost all the time • More than 4 -> thrashing, so keep 5th & higher in system entry queue (blocking) • Observed mix: 3Q, 1U

  8. Simple Two-Class Model • Assume: • Service time per disk visit is same for Q&U • U has more visits per transaction

  9. Note: scheduling matters for multiclass • Choice of scheduling discipline affects performance modeling for multiclass • First-come, first served (FCFS) • Round-Robin (RR) • Shortest Job Next (SJN) • Shortest Remaining Time (SRT) • Earliest Deadline (ED) • Least Laxity (LL)

  10. Simple Two-Class Model • One approach: construct an equivalent single-class model • (We did this before the break) • Useful, in that the single-class approach “pessimistically bounds the performance of the multiclass model”[Dowdy] • Problematic, in that it doesn’t permit the solution of many “what-if” scenarios

  11. Assumptions: BCMP • Specify a combination of service-time distributions and scheduling disciplines that yield multiclass product-form queueing networks that “lend themselves to efficient model solution techniques” • Open, closed, or mixed networks are allowed

  12. Assumptions: BCMP • Service centers with FCFS discipline • Service time distribution must be exponential with same mean for all classes • May have different visit ratios • Service rate can be load_dependent • But can only depend on total number of customers at the server, not on the number of customers of any particular class

  13. Assumptions: BCMP • Service centers with PS discipline • n customers, each receives service at rate 1/n • Each class may have distinct service time dist. • Reasonable approximation for RR

  14. Assumptions: BCMP • Service centers with infinite servers (IS) • Never any waiting for a server • a.k.a. - delay server or no queueing

  15. Assumptions: BCMP • Service centers with LCFS-PR discipline • Each class may have distinct service time dist. • Can be used to model servers at which high-priority interrupts require immediate but small amounts of service

  16. Assumptions: BCMP • Open networks: • Exponentially distributed inter-arrival time • No bulk arrivals

  17. Notation • K: number of devices (service centers) • R: number of classes of customers • Mr : number of terminals of class r • Zr: think time of class r • Nr: class r population • r: arrival rate of class r • Si,r: avg. service time of class r customers at device i • Vi,r: avg. visit ratio of class r customers at device i • Di,r: avg. service demand of class r customers at device i; Di,r = Si,r * Vi,r

  18. Notation, continued • Ri,r: avg. response time per visit of class r customers at device i • R’i,r: avg. residence time of class r customers at device i; R’i,r = Vi,r * Ri,r • Xi,r: class r throughput at device i • X0,r: class r system throughput • Rr: class r response time

  19. Closed Models • typically used for batch jobs and interactive jobs • = (1,3) for the update/query example of earlier

  20. Multiple class closed model

  21. Multiclass MVA • relies on 3 basic equations applied to each class • First: apply Little’s Law separately to each class of customers

  22. Multiclass MVA • Second: • Apply Little’s Law and the Forced Flow Law to each service center:

  23. Mulitclass MVA • The sum up customers of all classes at device i to get the total number of customers at that device:

  24. Multiclass MVA • Note: mean response time of a class r customer at service center i is own mean service time at that device plus time to service mean backlog seen upon its arrival. • Therefore:

  25. “backlog” • backlog = average queue length at device i seen by arriving class r customer • for delay server => 0 • for PS or LCFS-PR => an “inflation factor”

  26. Closed Models: Exact Solution Algorithm • Observation: queue length is 0 when no customers are in the network • Also:

  27. Exact MVA for Multiclass:

  28. Closed Models: Case Study

  29. Closed Models: Case Study

  30. Closed Models: Case Study • What is the predicted increase in the throughput of query transactions if the load of the update class is moved to off-peak hours? • Assume we still have 4 transactions – now all query transactions. Solve single-class model with 4 queries, get tput=5.275 tps … which is an increase of 28.87%

  31. Closed Models: Case Study • Realizing that disk 1 is the bottleneck and disk 2 is lightly loaded, which is the predicted RT if the total I/O load of query transactions is moved to disk 2? • shift value of D2,q to D3,q , solve new model. Results: • X0,q = 4.335 tps • X0,u = 0.517 tps • Rq = 0.692 sec • Ru = 1.934 sec

  32. Open Models • number of customers (transactions, processes, requests) varies dynamically

  33. Multiclass Open Models

  34. Analysis of Multiclass Open Models • In steady state, the throughput of class r equals its arrival rate: • X0,r = r (13.6.11) • The application of Little’s Law to each device gives Eq. 13.6.12:

  35. Analysis of Multiclass Open Models • The avg. residence time for the entire execution is R’i,r=Vi,rRi,r • Using the Forced Flow Law and Eq. (13.6.11) from the previous slide, the throughput of class r is given by Eq. 13.6.13

  36. Analysis of Multiclass Open Models • Using Eq. 13.6.12 and 13.6.13, the average queue length per device becomes (Eq. 13.6.14):

  37. Analysis of Multiclass Open Models • Combining the Utilization Law and the Forced Flow Law, the utilization of device i by class r customers can be written as (Eq. 13.6.15):

  38. Analysis of Multiclass Open Models • To computer average number of class r customers in service center i, need R’i,r as function of the input parameters.

  39. Analysis of Multiclass Open Models • In an open system, the population is infinite, so the arriving customer sees the overall steady-state distribution. Thus,

  40. Analysis of Multiclass Open Models

  41. Analysis of Multiclass Open Models • Notice that the expression in the [] on the previous slide doesn’t depend on class r. Thus, for any two classes r and s, we have:

  42. Analysis of Multiclass Open Models • Taking as class s all classes combined, we can rewrite ni,r as:

  43. Analysis of Multiclass Open Models • Applying Little’s Law to the previous formula, we obtain:

  44. Summary

  45. Open Model: Case Study • distributed environment • diskless clients connected to file server via high-speed LAN • file server = 1 CPU, 1 disk(large) • Question: what is the predicted performance of the file server if the number of diskless clients doubles?

  46. Open Model: Case Study • Workload characterization, monitor for 1 hour: • read requests - 18000 • write requests - 7200 • other requests – 3600 • CPU utilization: 32% (9% R, 18%W, 5%O) • disk utilization: 48% (20%R, 20%W, 8%O)

  47. Open Model: Case Study • From per-class utilizations and throughputs, can calculate Di,r, and then Vdisk,r , based on disk service times quoted by manufacturer. • Can calculate Vproc,r as 1 initial CPU visit plus one more CPU visit for every I/O visit

  48. Case Study – Open/multi

  49. Alternative Configurations

More Related