Tamás Bérczes 1 , tberczes@inf.unideb.hu, Gábor Guta 2 , Gabor.Guta@risc.uni-linz.ac.at,

1. Performance Analyzes ofa Proxy Cache Server Modelwith External Users using the Probabilistic Model Checker PRISM Tamás Bérczes1, tberczes@inf.unideb.hu, Gábor Guta2, Gabor.Guta@risc.uni-linz.ac.at, Gábor Kusper3, gkusper@aries.ektf.hu, Wolfgang Schreiner2, Wolfgang.Schreiner@risc.uni-linz.ac.at, János Sztrik1, jsztrik@inf.unideb.hu 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

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

3. PRISM • A Probabilistic Model Checker, developed at University of Oxford • Supports 3 models: • Discrete-time Markov chain (DTMC) • Markov decision processes (MDP) • Continuous-time Markovchain (CTMC); we use this one

4. Why PRISM?

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

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

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

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

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

11. 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 if its guard condition evaluates to true; • rate: it executes with a certain (exponentially distributed) rate and … • update: performs an update on its state variables. • 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.

12. An Example: The model of internal and external users // generate requests at rate lambda module jobs [accept] true -> lambda : true ; endmodule

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

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

15. 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 tis a time, then 1/tis a rate. • Example, where Ixc isthe PCS initializationtime: 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

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

17. 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 ]

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

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

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

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

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

23. Conclusion • The PRISM modeling language can be quite conveniently used to describe queueingnetworks by representing every network node as an automaton (“module”) withexplicit (qualitative and quantitative) descriptions of the interactions between automata. • This forces us to be much more precise about the system model, which mayfirst look like a nuisance, but shows its advantage when we want to argue about theadequacy of the model.

24. Thank you for your attention! Tamás Bérczes1, tberczes@inf.unideb.hu, Gábor Guta2, Gabor.Guta@risc.uni-linz.ac.at, Gábor Kusper3, gkusper@aries.ektf.hu, Wolfgang Schreiner2, Wolfgang.Schreiner@risc.uni-linz.ac.at, János Sztrik1, jsztrik@inf.unideb.hu 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