Transcript 1. dia - EKTF.hu

Performance Analyzes of
a Proxy Cache Server Model
with External Users
using the Probabilistic Model
Checker PRISM
Tamás Bérczes1,
[email protected],
Gábor Guta2,
[email protected],
Gábor Kusper3,
[email protected],
Wolfgang Schreiner2, [email protected],
János Sztrik1,
[email protected]
1.: Faculty of Informatics, University of Debrecen, Hungary,
http://www.inf.unideb.hu
2.: Research Institute for Symbolic Computation (RISC), Johannes Kepler
University, Linz, Austria, http://www.risc.uni-linz.ac.at
3.: Esterházy Károly College, Eger, Hungary, http://www.ektf.hu
Abstract
• We report our experience with formulating and
analyzing in the probabilistic model checker PRISM
a web server performance model with proxy cache
server and external users that was previously
described in the literature in terms of classical
queuing theory. We describe how to model a proxy
cache server, a web server, internal and external
users in PRISM.
• The main contribution of the paper shows how to
model in PRISM an input queue which might receive
different type of messages and has to place the
answer in different output queues depending on the
type of the message.
PRISM
• A Probabilistic Model Checker,
developed at University of Oxford
• Supports 3 models:
1. Discrete-time Markov chain (DTMC)
2. Markov decision processes (MDP)
3. Continuous-time Markov chain
(CTMC); we use this one
Why PRISM?
ETMCC
MRMC
PRISM
hybrid
PRISM
sparse
VESTA
YMER
worst, only small models
fastest for small models
fast if MTBDD is small
fast
rather slow, no S , statistical errors
slim & very fast, only U ≤t,
few statistical errors
The goal of our work
• The two originally distinct areas of the qualitative
analysis (verification) and quantitative analysis
(performance modeling) of computing systems
have in the last decade started to converge by the
arise of stochastic/probabilistic model checking.
• This fact is recognized by both communities. While
originally only individual authors hailed this
convergence, today various conferences and
workshops are intended to make both communities
more aware of each others’ achievements.
• One attempt towards this goal is to compare
techniques and tools from both communities by
concrete application studies.
• The present paper is aimed at exactly this direction.
Case Study
• We applie PRISM to re-assess a web
server performance models with proxy
cache servers with external users that
have been previously described and
analyzed in the literature:
• T. Bérczes, J. Sztrik: Performance
Modeling of Proxy Cache Servers,
Journal of Universal Computer Science,
12(9):1139–1153, 2006.
The system
• Using proxy cache server, if any information or
file is requested to be downloaded, first it is
checked whether the document exists on the
proxy cache server. (We denote the probability of
this existence by p). If the document can be
found on the PCS then its copy is immediately
transfered to the user.
• In the opposite case the request will be sent to
the remote Web server. After the requested
document arrived to the PCS then the copy of it
is delivered to the user.
• We assume that the requests of the PCS users
arrive according to a Poisson process with rate
lambda , and the external visits at the remote
web server form a Poisson process with rate
Lambda.
The system
• This network consists of four queues:
– one models the Proxy Cache Server
– two model the Web server, input/output
– one models the loop to download the
requested file.
• We have two more job-sources:
– Internal users, rate: lambda.
– External users, rate: Lambda.
• We have 6 models together.
Parameters
• Network Arrival Rate (lambda)
• Visit rates for external users (Lambda)
• Cache hit rate probability (p)
•
•
•
•
•
•
•
•
•
•
•
•
Buffer size of the Web server given in requests (K = 100)
Average File Size (F = 5000)
Buffer Size (Bs = 2000)
PCS buffer size (Bxc = Bs)
Initialization Time (Is = 0.004)
PCS initialization time (Ixc = Is)
Static Server Time (Ys = 0:000016)
Static PCS time (Yxc = Ys)
Dynamic Server Rate (Rs = 1310720)
Dynamic PCS rate (Rxc = Rs)
Server Network Bandwidth (Ns = 193000)
Client Network Bandwidth (Nc = 16000)
Programming PRISM
• Each process contains declarations of its state
variables and state transitions of form:
[label] guard -> rate : update ;
• guard: A transition is enabled to execute
guard condition evaluates to true;
if its
• rate:
it executes with a certain (exponentially
distributed) rate and …
• update:
variables.
performs an update on its state
• label: Transitions in different processes with the
same label execute synchronously as a single
combined transition whose rate is the product of
the rates of the individual transitions.
An Example: The model of
internal and external users
// generate requests at rate lambda
module jobs
[accept] true -> lambda : true ;
endmodule
How to implement a queue?
• Each node models a queue with a counter,
which contains the number of request in
the queue, i.e., we make no distinction
between requests.
• Example:
module PCS
pxwaiting: [0..IP] init 0;
…
endmodule
How to implement a queue?
• Each node has (generally) two transitions. One
(or more) for receiving requests, one (or more)
for serving requests. The first one increases the
counter, the second one decreases it.
• Example:
module PCS
pxwaiting: [0..IP] init 0;
[accept] pxwaiting < IP -> 1 :
(pxwaiting’ = pxwaiting+1);
[sforward] (pxwaiting > 0) & (1-p > 0) ->
(1/Ixc)*(1-p) : (pxwaiting’ = pxwaiting-1);
[panswer] (pxwaiting > 0) & (p > 0) ->
(1/Ixc)*p
: (pxwaiting’ = pxwaiting-1);
endmodule
How to implement a queue?
• The rate of the server transactions has generally
this shape: 1/t * p, where t is the time for
processing a request and p is the probability of
the branch for which the transaction corresponds.
• Note that if t is a time, then 1/t is a rate.
• Example, where Ixc is the PCS initialization time:
module PCS
…
[sforward] (pxwaiting > 0) & (1-p > 0) ->
(1/Ixc)*(1-p) : (pxwaiting’ = pxwaiting-1);
[panswer] (pxwaiting > 0) & (p > 0) ->
(1/Ixc)*p
: (pxwaiting’ = pxwaiting-1);
endmodule
How to implement a queue?
• If two queues, say A and B, are connected, then
the server transaction of A and the receiver
transaction of B have to be synchronous, i.e.,
they have to have the same label.
• The rate of the receiver transactions are always
1, because product of rates rarely makes sense.
module PCS …
[sforward] (pxwaiting > 0) & (1-p > 0) ->
(1/Ixc)*(1-p) : (pxwaiting’ = pxwaiting-1);
endmodule
module S_I …
[sforward] waiting<IA->1: (waiting’=waiting+1);
…
endmodule
Who to compute the expected
response time of PCS?
• Program:
module PCS
pxwaiting: [0..IP] init 0;
…
endmodule
• Reward:
rewards "time"
true : (pxwaiting)/lambda;
endrewards
• CSL query (R: expected value, S: steady-state):
R{"time"}=? [ S ]
Expected response time of
the system
• p = 0.25
• Lambda =
100
• computed
(by PRISM)
results are
the same
as the
numerical
ones up to
the 4-5th
digit
Implement input queue with
two output queues, The goal:
• Implement an input queue
which might receive different
type of messages and has to
place the answer in different
output queues depending on the
type of the message.
Solution
• If we know the incoming rates of the two
types of messages, then we can compute
the probability that a message is of type
A or B.
• Let the two rates lambda2 and Lambda.
If lambda3 = lambda2 + Lambda, then:
– lambda2/lamdba3 is the probability that a
message belongs to type A,
– 1-(lambda2/lamdba3) is the probability that
a message belongs to type B.
Program of the solution
• lambda2/lamdba3: message is of type A
• 1-(lambda2/lamdba3): message is of type B
module S_R
…
// forwarding of block to internet queue
[sanswer] (irwaiting > 0) & (q > 0) ->
1/(Ys+Bs/Rs)*q *(lambda2/lambda3):
(irwaiting’ = irwaiting-1) ;
// forwarding of block to external users
[extanswer] (irwaiting > 0) & (q > 0) ->
1/(Ys+Bs/Rs)*q *(1-(lambda2/lambda3)):
(irwaiting’ = irwaiting-1) ;
endmodule
Implement this server!
Which is the right solution?
• Internal users send request with rate alfa. External ones
with rate beta. Answers to internal users are sent to a PCS.
• The server initialization time is Is, the buffer size is Bs,
static server time is Ys, and the dynamic server rate is Rs.
module Server
RC[0..size] init 0;
[inter] RC<size->alfa: RC’=RC+1;
[exter] RC<size->beta:RC’=RC+1;
[pcs] RC>0-> 1/Is*1/(Ys+Bs/Rs)*
(alfa / (alfa+beta)): RC ’ =RC-1;
[out] RC>0-> 1/Is*1/(Ys+Bs/Rs)*
(1-alfa/(alfa+beta)):RC ’=RC-1;
endmodule
module ServerInputQueue
RC[0..size] init 0;
[inter] RC<size->alfa: RC’=RC+1;
[exter] RC<size->beta:RC’=RC+1;
[serve] RC>0 -> 1/Is: RC’ =RC-1;
endmodule
module ServerOutputQueue
AC[0..size] init 0;
[serve] AC<size -> 1: AC’=AC+1;
[pcs] AC>0 -> 1/(Ys+Bs/Rs)*
(alfa/(alfa+beta)): AC’=AC-1;
[out] AC>0 -> 1/(Ys+Bs/Rs)*
(1-alfa/(alfa+beta)): AC’=AC-1;
endmodule
Conclusion
• The PRISM modeling language can be
quite conveniently used to describe
queueing networks by representing every
network node as an automaton (“module”)
with explicit (qualitative and quantitative)
descriptions of the interactions between
automata.
• This forces us to be much more precise
about the system model, which may first
look like a nuisance, but shows its
advantage when we want to argue about
the adequacy of the model.
Thank you for your
attention!
Tamás Bérczes1,
[email protected],
Gábor Guta2,
[email protected],
Gábor Kusper3,
[email protected],
Wolfgang Schreiner2, [email protected],
János Sztrik1,
[email protected]
1.: Faculty of Informatics, University of Debrecen, Hungary,
http://www.inf.unideb.hu
2.: Research Institute for Symbolic Computation (RISC), Johannes Kepler
University, Linz, Austria, http://www.risc.uni-linz.ac.at
3.: Esterházy Károly College, Eger, Hungary, http://www.ektf.hu