WWV Analyzing a Proxy Cache Server Performance Model with the Probabilistic Model Checker PRISM Tamás Bérczes 1, Gábor Guta 2, Gábor Kusper 3, Wolfgang Schreiner János Sztrik 1, 1.: Faculty of Informatics, University of Debrecen, Hungary, 2.: Research Institute for Symbolic Computation (RISC), Johannes Kepler University, Linz, Austria, 3.: Esterházy Károly College, Eger, Hungary,

WWV Motivation The two originally distinct areas –qualitative analysis (verification) –quantitative analysis (performance modeling) have in the last decade started to converge by the arise of –stochastic/probabilistic model checking. One attempt towards this goal is to compare techniques and tools from both communities by concrete application studies. The presented paper is aimed at exactly this direction.

WWV Case Study We apply PRISM to re-assess some web server performance models with proxy cache servers that have been previously described and analyzed in the literature: –L. P. Slothouber. A Model of Web Server Performance. Proceedings of the 5th International World Wide Web Conference, –I. Bose and H. K. Cheng. Performance Models of a Firm’s Proxy Cache Server. Decision Support Systems, 29:47–57, 2000.

WWV The System Performance Models of a Firm’s Proxy Cache Server Client Proxy Cache Server(PCS) Case A: With probability p the request can be answered by the PCS. requests a file with rate lamba and with average file size F. sends back the file in a loop (F > Bxc)

WWV The System Performance Models of a Firm’s Proxy Cache Server Proxy Cache Server(PCS) Case B: With probability 1-p the request must be forwarded to a remote web server. Web Server requests the file from a remote web server with rate (1-p)lambda sends back the file in a loop (F > Bs) Client

WWV Derived Constants l1 = lambda1 = p * lambda l2 = lambda2 = (1-p) lambda Let q be the probability, that the Web Server can send the requested file at once. q = min{1, Bs / F) l2’ = lambda2prime = lambda2 / q

WWV Original Model

WWV Original Equation for Response Time

WWV Original Response Time Diagram

WWV 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

WWV PRISM In PRISM one gives the model by a –Finite state transition system qualitative aspects of the system –Associate rates to the individual state transitions quantitative aspects of the system Mathematical model: –Continuous-time Markov chain (CTMC) The model can be analyzed by queries –in the language of Continuous Stochastic Logic

WWV Programming PRISM Each process contains declarations of –state variables: vname: [minv..maxv] INIT initv; –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. update: performs an update on its state variables: vname’ = vname-1 label: Transitions in different processes with the same label execute synchronously as a single combined transition.

WWV Example // generate requests at rate lambda // [label] guard -> rate : update; module jobs [accept] true -> lambda : true; endmodule

WWV The System in PRISM 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 a job-source: –Users generates jobs, rate: lambda. We have 5 models together: –module jobs –module PCS –module server_input_queue –module server_output_queue –module client_queue

WWV How to Implement a Queue?

WWV State Variables Each model has a counter, which contains the number of request in the represented queue. Note: We make no distinction between requests. Example: module PCS pxc: [0..IP] init 0; … endmodule

WWV [label] guard -> rate : update ; Each module has (generally) two state transitions. One transition (or more) for receiving requests. One transition (or more) for serving requests. The first type increases the counter. The second one decreases it. module PCS pxc: [0..IP] init 0; [accept] pxc 1 :(pxc’ = pxc + 1); [sforward] (pxc > 0) -> (1/Ixc)*(1-p) : (pxc’ = pxc - 1); [panswer] (pxc > 0) -> (1/Ixc)*p : (pxc’ = pxc - 1); endmodule

WWV [label] guard -> rate : update; Each module has (generally) two transitions. One transition (or more) for receiving requests. Guard: there is place in the queue. One transition (or more) for serving requests. Guard: there is at least one request in the queue. module PCS pxc: [0..IP] init 0; [accept] (pxc 1 :(pxc’ = pxc+1); [sforward] (pxc > 0) -> (1/Ixc)*(1-p) : (pxc’ = pxc-1); [panswer] (pxc > 0) -> (1/Ixc)*p : (pxc’ = pxc-1); endmodule

WWV [label] guard -> rate : update; 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] (pxc > 0) -> (1/Ixc)*(1-p) : (pxc’ = pxc-1); [panswer] (pxwaiting > 0) -> (1/Ixc)*p : (pxc’ = pxc-1); endmodule

WWV [ label ] guard -> rate : update; 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] (pxc > 0) -> (1/Ixc)*(1-p) : (pxc’ = pxc-1); endmodule module server_input_queue … [sforward] (sic 1 : (sic’=sic+1); … endmodule

WWV A Question!

WWV Implement this server! Which is the right solution? Users send request with rate lambda. The server initialization time is Is, the buffer size is Bs, static server time is Ys, and the dynamic server rate is Rs. Solution A module Server RC[0..size] init 0; RC lambda: RC’=RC+1; [pcs] RC>0-> 1/Is*1/(Ys+Bs/Rs): RC ’ =RC-1; endmodule Solution B module ServerInputQueue RC[0..size] init 0; RC lambda: RC’=RC+1; [serve] RC>0 -> 1/Is: RC’ =RC-1; endmodule module ServerOutputQueue AC[0..size] init 0; [serve] AC 1: AC’=AC+1; [pcs] AC>0 -> 1/(Ys+Bs/Rs): AC’=AC-1; endmodule

WWV Who to Compute the Expected Response Time? Program: module PCS pxc: [0..IP] init 0; … endmodule Reward: rewards "time" true : (pxc+…) / lambda; endrewards CSL query (R: expected value, S: steady-state): R{"time"}=? [ S ]

WWV Response Time: Original Numerical Results and Results Computed by PRISM

WWV Errors in Performance Models of a Firm’s Proxy Cache Server. Client Network Bandwidth and Server Network Bandwidth are modeled as queues. “branching” should not start after the Server Network, but before. One queue is missing to simulate the looping process of sending and receiving files by the client.

WWV Original Model

WWV Corrected Model

WWV Original and Corrected Equations for Response Time

WWV Response Time: Numerical Results for Corrected Equation and Results Computed by PRISM

WWV Conclusion The PRISM modeling language can describe queuing networks by –representing every network node as a module –with explicit qualitative and quantitative descriptions Thus, it 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.

WWV Thank you for your attention! Tamás Bérczes 1, Gábor Guta 2, Gábor Kusper 3, Wolfgang Schreiner 2, János Sztrik 1, 1.: Faculty of Informatics, University of Debrecen, Hungary, 2.: Research Institute for Symbolic Computation (RISC), Johannes Kepler University, Linz, Austria, 3.: Esterházy Károly College, Eger, Hungary,