queueing models with multiple classes csci 8710 tuesday, november 28th kraemer

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

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

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

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”

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


• Assume: Service time per disk

visit is same for Q&U U has more visits per

transaction

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)


• 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

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

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

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

Assumptions: BCMP

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

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

Assumptions: BCMP

• Open networks: Exponentially distributed inter-arrival time No bulk arrivals

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

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

ideviceatcustrclassnumavgn ri ______.,

ideviceatcustnumavgni ____.

Closed Models

N (N1, N 2,...NR)

• typically used for batch jobs and interactive jobs

• = (1,3) for the update/query example of earlier

Multiple class closed model

Multiclass MVA

• relies on 3 basic equations applied to each class• First: apply Little’s Law separately to each class

of customers

K

irir

rr

NRZ

NNX

1,

,0

)(')(

Multiclass MVA

• Second: Apply Little’s Law and the Forced Flow Law to each

service center:

)(')(

)()(

)()()(

,,0

,,,0

,,,

NRNX

NRVNX

NRNXNn

rir

ririr

ririri

Mulitclass MVA

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

R

rrir

R

rrii

NRNX

NnNn

1,,0

1,

)(')(

)()(

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:

)](1[)('

)](1[)(

)](1[)(

,,,

,,,,,

,,,

NnDNR

NnSVNRV

NnSNR

Ariri

Aririririri

Aririri

ri

“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”

Arin ,

Closed Models: Exact Solution Algorithm

• Observation: queue length is 0 when no customers are in the network

• Also:

)1()(, riAri NnNn

Exact MVA for Multiclass:

Closed Models: Case Study


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


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

Open Models

• number of customers (transactions, processes, requests) varies dynamically

Multiclass Open Models

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:

)()()( ,,,

ririri RXn


• 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

• riririrri VVXX ,,,,0, )()(


• Using Eq. 13.6.12 and 13.6.13, the average queue length per device becomes (Eq. 13.6.14):

)(')( ,,

rirri Rn


• 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):

rirririrririri DSVSXU ,,,,,, )()(


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

)](1[)('

)](1[)(

)](1[)(

,,,

,,,,

,,,

,

Aririri

Ariririri

Aririri

nDR

nSVRV

nSR

ri


• In an open system, the population is infinite, so the arriving customer sees the overall steady-state distribution. Thus,

)()(,

iAri nn


)](1)[()](1[)(

)](1[)('

,,,

,,

iriirirri

iriri

nUnDn

nDR


• 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:

)(

)(

)(

)(

,

,

,

,

si

ri

si

ri

U

U

n

n


• Taking as class s all classes combined, we can rewrite ni,r as:

)(1

)()( ,

,

i

riri

U

Un


• Applying Little’s Law to the previous formula, we obtain:

)(1)(' ,

,

i

riri

U

DR

Summary

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?


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


• 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

Case Study – Open/multi

Alternative Configurations

queueing models with multiple classes csci 8710 tuesday, november 28th kraemer

Documents

class modelsimple

class modelassume

neach class

multipleclass modelsas

singleclass approach

distinct service time

combination of service

class modelone approach