PerfCenter: A Methodology and Tool for Performance Analysis of Application Hosting Centers

Transcription

1 PerfCener: A Mehodology and Tool for Performance Analyss of Applcaon Hosng Ceners Rukma P. Verlekar, Varsha Ape, Prakhar Goyal, Bhavsh Aggarwal Dep. of Compuer Scence and Engneerng Indan Insue of Technology Bombay Mumba, Maharashra, Inda Emal: rukma.verlekar@b.ac.n,{varsha,prakhargoyal,bhavsh}@cse.b.ac.n Absrac We presen a ool, PerfCener, ha akes as npu he deploymen, confguraon, message flow and workload deals of he hardware and sofware servers n an applcaon hosng cener, and predcs he performance of he applcaons. We allow for a herarchcal specfcaon of he daa cener, where sofware s deployed on machnes, machnes conss of hardware devces and are deployed on LANs. We also explcly model nework lnks beween LANs and model he conenon a hose lnks due o messages exchanged beween servers. Whle ools and mehodologes for such analyss have been proposed earler, our approach allows for he mos naural specfcaon of a daa cener archecure, and s bes sued for adng n desgn decsons regardng deploymen and confguraon of sofware on varous hardware archecure scenaros. The ool akes hs hgh level npu and generaes he underlyng queueng nework, whch s hen solved analycally. Snce we allow for synchronous mehod calls, and model conenon a sofware as well as hardware resources, he generaed queueng nework s solved usng approxmae mehods. We valdae he soluon agans resuls obaned from a measuremen esbed, and found ha he predced values were reasonably accurae. I. INTRODUCTION The performance of onlne servces has become one of he man qualy arbues by whch curren Inerne users rae hem. A recen repor by Juper Research [5], based on a sudy of on-lne shoppers, denfes poor Web-se performance as second only o cos consderaons, as a reason o enrely abandon, or no re-vs an onlne realng Web-se. Thus, s crcal o offer good performance o Inerne and Web users. Onlne servces are ypcally suppored by dsrbued applcaons, or mul-er server sysems. Thus, e.g., a Webbased e-mal servce s suppored by a leas hree applcaon componens, he Web server, IMAP server, and he SMTP server. More complex servces can be made of a large number of such componens. Such servces are ofen hosed ou of a daa cener whch houses he machnes runnng hese applcaons. Before enablng such a servce, he daa cener admnsraor has o make several decsons - how many hoss would be requred for he servce? How should he deploymen of sofware componens on hoss be? Wha should be he confguraon of an applcaon (e.g. hread pool sze). For larger organzaons, a servce could be composed ou of applcaons ha are geographcally separaed - n such a case, how would he nework delay affec he user response me? All hese quesons can be answered by buldng an approprae queueng model of he dsrbued sysem. However, gven he complexy of mul-er sysems, such models canno be bul manually. Thus we need ools ha can ranslae a hghlevel specfcaon of he dsrbued sysem no a queueng model, and hen solve. Over he las decade, here has been sgnfcan effor n creang ools and echnques for analyss of dsrbued sysems [3]. All of he echnques are rooed n queueng heory, where he dsrbued sysem s vewed as a complex sysem of resources. The dsrbued sysem s mapped o a queueng nework and analyzed. One of he prmary challenges n such queueng nework analyss has been he capurng of he layered behavour of a dsrbued sysem -.e. he behavour n whch he server of one queue, makes a reques o anoher resource on behalf of he reques ha s servng. Ths resource could be a hardware devce (e.g. when a Web server hread jons a CPU queue), or anoher sofware server (e.g. when a Web server hread makes an RPC call o an applcaon server). Several approaches have been proposed o solve such models. The sgnfcan ones nclude he Sochasc Rendezvous Nework model by Woodsde e al [14] and he Mehod of Layers by Sevck and Rola [12]. These approaches are noable for her analycal soluons of he models. The work n recen years has focussed mmensely on ranslaon of hgh-level specfcaon, o he formalsms acceped by such models [1], [6], [7], [17], assumng ha a ool for he soluon of he model s avalable. Some amoun of work has also been done n developng more accurae (as opposed o generc) models of a sysem, so ha more dealed behavour can be specfed and analyzed [8], or n developng models specfc o ceran sofware echnologes [11], [16]. Whle exsng ools and echnques have progressed consderably, we beleve here s sll room for mprovemen n he ease wh whch some of he feaures of a dsrbued

2 sysem can be specfed. Specfcally, a drec approach by whch a daa cener archecure can be specfed would be very convenen. In oher words, we would lke o specfy he hardware archecure (such as how many machnes, of wha ype), he nework archecure (how he machnes are deployed on LANs, and perhaps separaed by a WAN), he sofware archecure (he message flows for varous use cases), and he deploymen and confguraon deals of he sofware and hardware. To our knowledge, none of he exsng ools/mehodologes allow such specfcaon. We nroduce such a specfcaon n he form of a sofware ool, called PerfCener, whch we beleve s boh nuve and sraghforward, and presen he analycal mehodology for dervaon of varous performance measures based on hs specfcaon. We valdae he resuls of our ool wh he acual measuremens, and fnd ha he model provdes reasonable accuracy n predcng values of mporan performance measures of he dsrbued sysem. The res of he paper s as follows: n Secon II, we presen a movang example and revew exsng work n hs area. We descrbe he elemens of our sysem model n Secon III. In Secon IV, we presen he formal specfcaon and analycal soluon of he model. In Secon V, we presen valdaon resuls, and llusrae he use of our ool by runnng varous wha-f scenaros. We conclude he paper n Secon VI. II. MOTIVATING EXAMPLE: A WEBMAIL SERVICE Consder a Web-based e-mal (Webmal) servce, whch s provded usng he followng sofware componens: he Web, he Auhencaon, he IMAP and he SMTP servers. A ypcal Webmal servce allows he user o logn, on whch dsplays a ls of messages from he user s defaul folder. The user may hen read, send, delee messages, and carry ou a varey of oher ransacons on he IMAP/SMTP servers hrough he Web nerface. Each arrvng Web reques rggers a flow of messages hrough he sofware componens, whch nerac wh each oher o fulfll he user reques. Each such ype of reques or a ransacon s ermed a use case scenaro. A vsual formalsm called a Message Sequence Char (MSC) [1] s ofen used o depc a use case scenaro. Fgures 1 and2 depc he MSCs correspondng o he logn, read, send and delee scenaros for he Webmal sysem. In he logn scenaro, he Web server processes he user reques and makes a call o he auhencaon server (send o auh) whle passng on he user logn d and password for auhencaon o. The auhencaon server hen verfes he credenals (verfy password) and sends back he reply. We assume ha he logn reques s rejeced due o auhencaon falure wh probably.1, whereas wh probably.9 he user s auhencaed. If auhencaed, he Web server ssues a reques o he IMAP server o dsplay he message box of he requesng user (send o map). The IMAP server hen sends he conens of he message box (ls messages) o he Web server whch formas for sendng o he user (change o hml). The res of he scenaros are smlar o he logn scenaro. USER W EB AUT H IMAP USER W EB AUTH IMAP password s a no ok ok s (a) Fg. 1. (a) v p.1.9 l m sess d s a no ok ok s Logn and Read Message Scenaros (b) (b) v s.2.8 r m USER WEB AUTH IMAP SMTP USER WEB AUTH IMAP sess d sess d s a s a v s v s no ok.1 no ok.2 ok.9 ok.8 s s s s m d m Fg. 2. Send and Delee Message Scenaros Several quesons arse for hs sysem, whch depend on he hardware deploymen and sofware confguraon of he servers. E.g., for a gven deploymen, wha would he boleneck machne be? Wha would be he scenaro response mes? Would he machnes be adequaely ulzed? How many hreads should he Web-server be confgured wh? Wha f one of he servers s geographcally separaed? To answer such wha-f quesons, we would lke a ool ha would allow npu specfcaon n a manner ha would be naural o a daa cener archec. In he followng secon, we revew exsng ools ha ry o mee hs need. A. Exsng Mehodologes and Tools A large amoun of research has been done over he las decade o address he problem of analyzng he performance of sofware sysems. Here, we focus on approaches ha propose analycal soluons o he performance models. The Mehod of Layers echnque [12] was among he early approaches, whch proposed a model and an analycal soluon for capurng he layered behavour of sofware sysems -.e. where one layer of servers uses he servces of anoher layer of servers, where he lowes layer s ha of

3 he hardware devces. All calls beween layers are assumed o be synchronous. The Sochasc Rendezvous Nework [14] s a powerful model, whch capures many neresng behavours of a dsrbued sysem. Apar from synchronous calls o servers a dfferen layers, he model allows execuon of a servce n phases. Ths allows capurng of pos-processng ha s done by a server, even afer a reply s sen back o he caller. The soluon mehod of hs model s mplemened n a ool called he LQNSolver [15]. Furher aemps have manly focussed on mappng hgher-level specfcaon formalsms o he formalsm ha LQNSolver can accep (e.g. UCM2LQN [1], UML2LQN [17]). Some exensons o he power of he model have also been made (e.g. addng he capably of modelng forks and jons [1]) n he processng of he reques. Anoher sgnfcan body of work has been done by Balsamo e al [1], [2], [4] who have used queueng neworks wh fne capacy queues o model sofware archecures, ncludng hose ha allow synchronous calls beween servers. Afer he nal effors n defnng sochasc models ha could capure mporan behavours, recen work has manly been dreced owards makng specfcaon easer for a sofware developer, so ha he process of performance analyss can be negraed no he developmen cycle. A dealed survey s ou of he scope of hs paper, and he reader s nsead referred o he excellen revew by Balsamo e al [3]. Whle a varey of ools seem o exs for he purpose of analyzng sofware sysems, we clam ha none of hese are suable for analyss from he daa cener pon of vew. We clam ha he exsng ools are deal as ools o be used durng developmen, when he deals of deploymen may no be avalable. However, a he sage when an applcaon s ready o be deployed n a hosng cener, he archecure of he daa cener (machne specfcaons and nework archecure) sars playng an mporan par. A daa cener archec would requre a ool ha allows hm/her o run varous wha-f scenaros of deploymen and confguraon, and see her effec on he performance of he applcaon. The formalsm we propose capures he naural language ha daa cener archecs speak - n erms of number of machnes of a ceran ype, he specs of a ype of machne, he deploymen of a sofware applcaon on a ceran machne, and he deploymen of he machnes on varous dfferen daa ceners ha mgh be separaed by long dsance nework lnks. PerfCener acceps specfcaon a hs level, and solves he underlyng queueng model whch capures he complexy of he conenon for resources. In he nex secon, we presen he elemens of our sysem model, whch wll clarfy how our formalsm s sued owards he analyss of an applcaon ha s abou o be deployed n a daa cener. III. THE DISTRIBUTED SYSTEM MODEL Our sysem model aemps o formalze a daa cener roughly herarchcally, as a ypcal archec would - hus we defne machnes, (sofware) servers, neworks, and provde 1 resources CPU PS; 2 machnes SUN[2]: CPU = 1; HP[2]: CPU = 1; 3 nework lan1 lan2 rans=1mbps prop=2.3ms mu=256b; 4 5 sofware WEB: hreads = 8 s a {CPU =.15}, s { CPU =.2 }, s s {CPU =.2}, {CPU =.1}; AUTH: hreads = 5 v p { CPU =.1 }, v s {CPU =.5}; 6 maplans lan1 SUN[1], SUN[2], HP[1], HP[2]; IMAP: hreads = 8 l m { CPU =.25 }, r m {CPU =.2}; SMTP: hreads = 8 s m {CPU =.14}; mappngs WEB SUN[1]; AUTH SUN[2]; IMAP HP[1]; SMTP HP[2]; 7 Scenaro Logn 12. { WEB s a AUTH v p 128 SYNC; [.1] { AUTH v p WEB 128 ; } [.9] { AUTH v p WEB s 256 ; WEB s IMAP l m 512 SYNC ; IMAP l m WEB 248; } } Fg. 3. Example npu fle for he PerfCener ool fner level deals of he resources ha consue he machnes. We also specfy deploymen and confguraon deals for he servers. The deploymen s specfed n erms of servers on machnes, and machnes on LANs. The specfcaon s done usng a smple ex nerface. Fgure 3 shows an excerp from he npu fle correspondng o he example descrbed n Secon II. We explan he componens of our sysem model usng hs npu fle as an example. 1) Hardware Devces: A he lowes level of he dsrbued sysem, here are hardware devces (e.g. CPU, dsks), whch are pars of machnes. Each such devce can be declared, by gvng each ype a symbolc name whch s used laer for referencng and s correspondng servce dscplne (eg. PS for CPU, FCFS for Dsk). 2) Machnes: We can defne dfferen ypes of machnes, and specfy how many of each ype here are n he sysem. A machne s defned by he ypes and he quany of he varous hardware devces (from he declared ls) ha possesses. 3) Nework Archecure: We allow our sysem o conss of several LANs ha can be separaed by pon-o-pon lnks. For each such pon-o-pon lnk we specfy he value of ransmsson rae, propagaon delay and he Maxmum Transmsson Un (MTU). 4) Machne deploymen descrpon: The machnes n he dsrbued sysem can be deployed ono dfferen LANs. 5) Servers: Here, by servers we mean he server applcaons such as Web server, IMAP server, ha run on he machnes. Each of he servers n he dsrbued sysem s specfed wh he number of hreads possesses and s correspondng se of smple asks. A smple ask s defned as a connuous pece of execuon, whch holds a devce of s hos machne, for a gven amoun of me. (We wll explan he concep of smple asks furher, n

4 Secon IV). 6) Server deploymen descrpon: The deploymen of hese servers o dfferen machnes s also specfed. 7) Use Case Scenaros: The neracon of he servers o provde a varey of servces s specfed hrough a formalsm smlar o message sequence chars whch are a par of he UML specfcaon. Each use case scenaro consss of an ordered sequence of asks of varous servers, wh ceran annoaons. Once a hread execues a ask locally, may make a synchronous or asynchronous call o a ask of anoher server (denoed by a SYNC/ASYNC ag). We allow probablsc branchng o reflec dfferen pahs ha may be aken n a scenaro. We also have a noon of a message sen when a ask makes a remoe call. Thus each such call s annoed wh a message sze n byes. The use case scenaro self s gven a symbolc name and s correspondng arrval rae s specfed n erms of requess per second. Thus, currenly we assume open arrvals o he sysem. Wh he above specfcaon, he performance measures of neres would be: Response mes of he use case scenaros Ulzaon of he hardware resources Sysem capacy (n erms of maxmum aggregae reques rae ha can be suppored) Boleneck server (hardware or sofware). We derve all hese measures usng an analycal modelng approach ha essenally vews he enre sysem as a layered nework of queues. The analycal mehodology works by dervng wo parameers: reques arrval rae, and average servce me, for each of he queues n he nework. The arrval rae o each of he resources of he sysem depends on facors such as hgh-level use case scenaro arrval raes, as well as he deploymen of servers on machnes, and machnes on neworks. The average servce me of a server, n hs case beer ermed as holdng me of a resource s a complex quany for hs sysem: depends on conenon for resources ha are requesed whle holdng hs resource - e.g. he holdng me of a hread would depend on he me requred for recevng a response from a remoe server, when a synchronous call s made. I would also depend on he workload on he CPU on whch he hread s execung - snce here could be conenon for he CPU. Thus, he mehodology mus ake no accoun delays caused by all such neracons whn he sysem. In he followng secon, we presen n deal, he analycal soluon for dervng he measures. Snce makes several assumpons along he way, he analycal soluon s approxmae. IV. THE ANALYTICAL SOLUTION Before we presen he formal model and soluon of he queueng nework underlyng our sysem, we explan a few key conceps and defnons: Synchronous vs asynchronous calls: A sofware server ofen calls a ask of anoher server o fulfll he reques ha s processng (e.g. n he Webmal example, he Web server calls he ls message ask of he IMAP server). Ths can be done n wo ways. The frs s o smply forward he reques o he nex server, whou wang for a response, hereby releasng he hread whch was execung he reques on hs server. Ths s ermed as an asynchronous call. The second way s o call he ask of he oher server, and wa for he response. In hs case, he hread whch makes he call, blocks, and s held unl he response s receved, and s connued o be held unl eher makes an asynchronous call, or fnshes processng and reurns he response o he user (reques exs). When we calculae queueng delays a sofware servers, he ype of calls s asks make s a very mporan facor ha deermnes how long he hread resource s held by a reques. Smple vs Compound asks: The asks ha a server carres ou can be of wo ypes: smple, and compound. Smple asks conss purely of nsrucons ha execue on local devces of he machne. Compound asks represen funcons or mehods of servers ha may no only have some local compuaon, bu also nclude synchronous calls o oher asks. Thus, when a server hread performs a compound ask, s held durng local compuaon as well as durng he mes ha s blocked on responses from synchronously called servers. E.g.,n he Webmal example, he Web server execues a compound call nvolvng local processng (s a,, s ) and synchronous calls o he auhencaon and IMAP servers. Wh he above clarfcaon, we frs proceed o formally express he specfcaon gven n he prevous secon, hen derve he parameers of he underlyng queueng nework, and lasly, derve he performance measures of he queueng nework. A. Formal model of he npu parameers Le here be D ypes of devces, M machnes and S servers n he sysem. A machne m s characerzed by he se: {q m1, q m2,...,q md,..., q md } where q md s he number of ype d devces presen n machne m. Two dfferen machnes ha are characerzed by he same se, are consdered o be he same ype of machne. Le A = [a sm ] denoe he server-o-machne allocaon marx. Thus, a sm = 1 f server s s deployed on machne m, and f no. Then a s = m a sm denoes he number of machnes on whch server s has been deployed. Le B = [b mn ] denoe he machne-o-lan allocaon marx. Thus, b mn = 1 f machne m s deployed on LAN n, and f no, wh n b mn = 1. Furher, le β m denoe he ndex of he nework on whch machne m s deployed. Le r nn, δ nn, and MTU nn denoe he b-rae, he propagaon delay and he maxmum packe sze ( Maxmum Transmsson Un ) respecvely of he pon-opon lnk beween he wo LANs n and n.

5 Each server s s characerzed by a smple ask se: {E1 s, Es 2, Es 3,..., Es n s }. We also specfy he number of hreads c s ha he server can have. Assocaed wh each smple ask E s, s he execuon me ha requres on each devce d, denoed by τ s,,d There are F use case scenaros n he sysem. The arrval rae of scenaro f s denoed by λ f. A use case scenaro, f, s specfed as a ree denoed as f, where each node corresponds o a smple ask and can be denoed by f. An arc from one node (ask) o he nex node (ask) sgnfes ha he frs ask has called he nex ask. Each such arc s annoaed wh he arbues: he probably of he call, wheher he call s synchronous or asynchronous, and he sze of he message ransfered as a resul of he call. Le G( f, f j ) denoe he probably ha n scenaro f, ree node f, represenng ask Es, wll call a ree node f j, represenng ask E s. where f s an mmedae paren node of f j. Nf s he oal number of nodes n a ree for scenaro f. The roo of he ree s he frs smple ask of he scenaro. Le l s,,s, denoe he average sze of he message sen from ask E s o Es n a scenaro (hus, we assume ha for a gven sequence of one ask callng anoher ask, he average message sze remans he same). The above srucures and parameers form he npu o our analycal model. B. Dervng he Parameers of he Queueng Nework Based on he above npu, some nermedae values need o be calculaed, for dervng he performance measures of he sysem. Brefly, hese values are he arrval raes and he average holdng mes ha characerze he queueng models correspondng o he sof and hard resources of he sysem. Before dervng hese quanave parameers, he ool carres ou he mporan sep of denfyng he compound asks of a server. Recall ha he ool user, n he specfcaon, only provdes deals of he smple asks of a server. The complee ask se of a server s revealed only by nspecng he use case scenaros (algorhm gven n [13]). Noe ha a smple ask s a specal case of a compound ask, and hus, henceforh we refer o he compound asks as smply asks. Le he complee ask se for he server s be denoed by T s = {T1,T s 2 s,...,tc s s }, where C s s he oal number of asks n he ask se of server s. Each ask T s n T s corresponds o an execuon sequence of seps, whch are eher local compuaons (smple asks) or synchronous calls. We represen hs as T s = Xs,1, Xs,2, Xs,3, Xs,4,..., Xs,Q where s Q s s s he oal number of seps n he compound ask T n T s. X,j s s eher a smple ask Es of server s or a synchronous call o a ask of anoher server s, denoed by S(T s ). We assume ha every ask consss of a smple ask as s frs sep, possbly followed by an alernae sequence of synchronous calls and smple asks. Once he ask se for each server s bul, we can proceed o derve he parameers of he varous queueng models: Task arrval raes: The ask arrval raes o smple asks, denoed by λ E s are calculaed based on he use case scenaros and her arrval raes. Usng preorder ree raversal algorhm, we can calculae he oal arrval rae o any smple ask n a scenaro by vsng each ree node. In a ree, node f j represens ask E s and here can be many such nodes f j 1, f j 2, f j 3,..., f j n. whch also represen ask E s n he ree for any j n N f. Arrval rae o a parcular node f j whch represens ask E s s λ f = λ j f G( f, f j ), where f s he mmedae paren node of f j. If f j s he roo node hen λ =λ f. Hence f j he oal arrval rae o any ask E s n a scenaro f s hen N f j=1, λ f f j =Es j. Snce we assume ha f he server s deployed on mulple machnes, he load s equally dsrbued among all he servers, he oal effecve ask arrval rae wll be λ E s = F N f f=1 j=1, f λ f j =Es j /a s. Assumng no probablsc branchng n scenaros, he arrval rae a a compound ask, λ T s s equal o he arrval rae of he frs smple ask n s execuon sequence. Thus, f T = X,1 s, Xs,2, Xs,3, Xs,4,...,Xs,Q, where s X,1 s = Es hen λ T s = λ X s,1 = λ E s. Ths can be easly generalzed o he case where here s probablsc branchng. The oal arrval rae o a server s on a machne m s hen gven by λ s m = λ T s (1) T s Thread holdng mes for each ask: Le he holdng me of ask T s, a machne m, be denoed by hs,m. Then, Q s h s,m = R m (X,j) s (2) j=1 where R m (X,j s ) s eher he response me a he devces of a smple ask or of a synchronous call. If X,j s s a smple ask E s, R m (X s,j) = D R md (E s ) (3) d=1 where R md (E s ) s he response me of ask E s a devce d on machne m. If X,j s s a synchronous call, say o ask T s, hen le Xs,j 1 be a smple ask Es, and le E s be he frs smple ask of T s. Then he message sze for hs call s l s,,s,, and he reply s of sze l s,,s,. Then R m (X,j s ) s gven by m a s m [Dmesg m,m (l s,,s, ) + R s m (T ) + Dmesg m,m (l s,,s,)] a s (4) f b mβm b mβm =, and by m a s m R s m (T ) a s (5)

6 oherwse. where R m (T s ) s he average response me of he ( ) h ask of (s ) h server on machne m, and Dm,m mesg (l s,,s. ) and D mesg m,m (l s,,s,) are he delays for ransferrng he message correspondng o he reques and he response, respecvely. Average hread holdng me: The average hread holdng me of server s a machne m, denoed by h s m s gven by he weghed average of holdng mes of he ndvdual asks: Cs h s m = =1 λ T shs,m Cs =1 λ (6) T s Arrval rae o devces: The oal arrval rae of smple asks o a devce of a machnes s he sum of all he requess comng from all he asks of all he servers deployed on ha machne λ m,d = S n s a sm 1(τ s,,d > )λ E s (7) s=1 =1 where 1(τ s,,d > ) s 1 f he E s uses devce d and oherwse. Average devce holdng mes: Alhough devce holdng mes are gven drecly as an npu, he average holdng me of a devce mus be calculaed, for characerzng he devce-level queue. Ths average wll depend on he relave arrval raes a whch requess from varous smple asks wh dfferen holdng mes arrve o he devces. Hence he average holdng me of a devce d on machne m s gven by τ m,d = S s=1 ns =1 a smλ E s τ s,,d λ m,d (8) Arrval raes o lnks: Le λ call s,,s, be he rae a whch a call s made o E s from Es. Then λ call s,,s, = f N f =1, f =Es N f j=1, f j =Es λ f G( f, f j ) a s (9) If λ call s,s denoes he oal rae a whch a server s sends messages o a server s, hen λ call s,s = λ s,,s, (1) The average number of packes generaed beween m and m, by he call from E s o Es s n lnk s,,s,,m,m = celng( l s,,s, ) (11) MTU βm,β m The correspondng average packe sze s gven by l pack s,,s,,m,m = l s,,s, n lnk (12) s,,s,,m,m The arrval rae of packes on he lnk (m, m ), λ m,m s gven by: a sm a s m λcall s,,s, nlnk s,,s,,m,m (13) s s and he overall average packe sze, l m,m s gven by: s s a sm a s m lpack s,,s,,m,m λcall s,,s, nlnk s,,s,,m,m λ m,m (14) Thus, he lnk ulzaon ρ m,m s gven by λ m,m l m,m /r m,m where l m,m /r m,m s he average packe ransmsson me. Gven he average packe sze, lnk rae and packe arrval rae, he lnk can be approxmaed as a smple M/M/1 queue, whose wang me can be calculaed. Le hs wang me be denoed by W m m. The packe ransfer delay of a packe of a parcular sze l s hen smply gven by D m,m = W m,m + l/r m,m + δ m,m We approxmae he message delay for a message of sze L: C. Performance measures D mesg m,m (L) = W m,m + δ m,m + L r m,m The above analyss resuled n dervaon of arrval raes and average holdng mes for all he queues n he model. Now, he performance measures of he sysem can be derved as follows: Devce hroughpu: Snce we consder lossless queueng sysems, devce hroughpu, Λ m,d s smply λ m,d, f λ m,d τ m,d < q md and q md /τ m,d oherwse. Devce ulzaon: The devce ulzaon for a devce d a machne m s gven by ρ m,d = λ m,dτ m,d q m,d (15) Devce response mes: These are gven by: R md (E s ) = W m,d + τ s,,d (16) where W md can be calculaed by approxmang he devce as a smple M/M/c queue, wh q md servers, λ m,d arrval rae, and τ m,d servce me. Server hroughpu: Agan, snce we consder lossless queueng sysems, server hroughpu s smply Λ s m = λt s, f λs m hs m /c s < 1 and c s /h s m oherwse. Server ulzaons: The ulzaon of a server s on machne m (denoed by ρ s m) s gven by ρ s m = λs m hs m c s (17) Task response mes: The ask response mes are gven by R m (T s ) = h s,m + W m,s (18)

7 where W m,s can also be calculaed by approxmang he sofware server as a smple M/M/c queue, wh c s servers, λ s m arrval rae, and h s m servce me. Scenaro response mes: Whou loss of generaly, le us consder scenaros whou probablsc branchng. The scenaro can hen be defned by a sequence of asks. The scenaro response me, R f, hen, s gven by he sum of response mes of all he asks n he scenaro. However, he response mes of asks ha are called synchronously are no ncluded n hs sum, as hey are already accouned for n he holdng mes of he callng asks. The average scenaro response me s he weghed sum of response mes of all he scenaros, and s gven by: R avg = f λ f R f λ f (19) Equaons 2 o 18 can be solved eravely ll he correspondng values of hread holdng mes n he successve eraons converge, n order o yeld he desred performance measures. The eraon sars wh he nal values of wang mes se o zero. Thus, W m,m, W m,d and W m,s should be se o. V. RESULTS Whle here s a lo of work on models of dsrbued sysems, very few repor on her praccal usably, whch would depend grealy on he accuracy of he predcons of he model. We chose, herefore, o valdae our model, wh measured daa. A esbed emulang he Webmal applcaon as descrbed n Secon II was bul, and expermens were carred ou on. The four dfferen servers - Web, Auhencaon (Auh), IMAP and SMTP; were hosed on four dfferen machnes. The Web server s an Apache server execung PHP scrps o emulae synchronous calls o he Auh, IMAP and SMTP servers. The backend servers were wren n C++. Mulple expermens were conduced on hs dsrbued es-bed. For load generaon, hperf [9] was used, whle server performance measures were obaned hrough Lnux ules such as sar, ps, ec. The servce mes of he asks n seconds were as specfed n he npu fle of Fgure 3. The mx of he reques was as follows: one read and send reques each s ssued for every wo logns. The measuremens were carred ou up o he pon a whch one of he servers bolenecked. The values obaned for response me and CPU ulzaon were hen mached agans he resuls obaned from PerfCener. Fgures 4 and 5 compare he measured and model predced values of average scenaro response mes and CPU ulzaons, respecvely, for he sysem specfed n Fgure 3, for varyng load. The predced CPU ulzaons are hghly accurae, whle he he predced scenaro response mes are also whn reasonable accuracy up o he pon where he Web server CPU reaches 8% ulzaon. Ths ndcaes ha he model predcons are farly relable and can be used for makng a number of deploymen Fg. 4. values. Average scenaro response me n ms Analycal Measuremen Arrval rae n requess per second Average scenaro response me: comparson of model vs. measured Ulzaon n percenage Fg Web-CPU Analycal Web CPU Mesuremen Auh-CPU Analycal Auh CPU Mesuremen Imap CPU Analycal Imap CPU Mesuremen Smp CPU Analycal Smp CPU Mesuremen Arrval rae n requess per second CPU ulzaon: comparson of model vs. measured values. and confguraon decsons by he daa cener archec. For example, s clear from he ulzaons ha he machnes hosng SMTP and Auh server are under-ulzed, whereas he machne hosng he Web-server s over-ulzed (1% a 22 requess/second). Thus, we could deploy he Web-server on wo machnes, whle allocae only one machne o Auh and SMTP. Fgure 6 shows he ulzaons of he Web, AUTH and SMTP (boh mapped o one machne) CPU s under hs scenaro as predced by PerfCener. As we can see, he CPU ulzaons are now balanced beer, wh he Web server CPU a 5% and he Auh and SMTP CPU a 23%, a 22 reqs/sec. Fnally, we evaluae a scenaro where he resource demands of smple asks s a and v s have been changed from 15ms o 55ms and 5ms o 55ms respecvely. We sll wsh o suppor a maxmum load of 22 req/sec. Here, we use PerfCener o deermne he opmal number of hreads requred o suppor hs reques rae. Too few hreads may resul n lesser capacy han requred, and under-ulzaon of hardware resources, whle oo many hreads are undesrable, snce hs mples sysem overheads. Thus, we evaluae he sysem wh a varyng hread confguraon for he Web server. Fgure 7 shows he change n Web CPU as well as he (sofware) server ulzaon wh ncreasng number of hreads for he server. We can see ha as number of avalable hreads ncrease, he CPU ulzaon and sysem hroughpu ncreases nally. Afer a ceran pon, however (afer 19 hreads), here s no benef

8 Ulzaon n percenage Ulzaon n percenage Web server CPU Auh, SMTP server CPU Fg Arrval rae n requess per second Ulzaon values wh he new deploymen Number of Web server hreads Web server Web CPU Sysem hroughpu Fg. 7. Usng PerfCener o fnd he mnmum number of hreads for he Web server for a sysem wh hgher resource demands. n addng more hreads - even hough he server ulzaon decreases, he sysem hroughpu and CPU ulzaon flaen ou. Thus he opmal number of hreads for hs workload s 19. VI. SUMMARY AND CONCLUSIONS In hs paper, we nroduced a sysem model ha suppors easy specfcaon of daa cener desgn, and sofware archecure deals, so ha performance measures under varous archecure, deploymen and confguraon opons can be generaed. We presened an analycal mehod for he approxmae soluon of he model. We compared our resuls wh measured daa, and found ha he predced resuls mach que well wh he measured daa. Ths ool can be a par of a more ambous vson of selfuned sysems, whch opmze hemselves for beer performance. Several approaches have been proposed ha ulze a modelng engne n a conrol loop for unng sysem parameers. Ths ool could be used as one such engne. One of he drawbacks of hs approach s ha requres dealed nformaon abou he sysem. Ths s an area of research we are acvely focussng on - o auo-dscover he message flows and resource consumpon deals ha would serve as an npu o hs model. Once dscovered, hese npus can be auomacally convered no a specfcaon forma, Sysem hroughpu accepable by he ool. Furhermore, he ool needs o be valdaed on ndusral-scale server applaons. REFERENCES [1] F. Andolf, F. Aqulan, S. Balsamo, and P. Inverard. Dervng performance models of sofware archecures from message sequence chars. In WOSP : Proceedngs of he 2nd Inernaonal Workshop on Sofware and Performance, pages 47 57, NY, USA, 2. ACM Press. [2] Smonea Balsamo, Federca Aqulan, and Paola Inverard. An approach o performance evaluaon of sofware archecures. In Proceedngs of he frs Inernaonal Workshop on Sofware and Performance, pages , Sana Fe, New Mexco, Uned Saes, ACM Press. [3] Smonea Balsamo, Annsca D Marco, Paola Inverard, and Mara Smeon. Model-based performance predcon n sofware developmen: A survey. IEEE Transacons on Sofware Engneerng, 3(5):295 31, 24. [4] Smonea Balsamo and Moreno Marzolla. Performance evaluaon of UML sofware archecures wh mulclass queueng nework models. In WOSP 5: Proceedngs of he 5h Inernaonal Workshop on Sofware and Performance, pages 37 42, NY, USA, 25. ACM Press. [5] Anone Gonsalves. Akama and Juper Research denfy 4 seconds as he new hreshold of accepably for real web page response mes. TechWeb News, hp:// press/releases/26/press 1166.hml, November 26. [6] Vncenzo Grass, Raffaela Mrandola, and Anonno Sabea. From desgn o analyss models: a kernel language for performance and relably analyss of componen-based sysems. In WOSP 5: Proceedngs of he 5h Inernaonal Workshop on Sofware and Performance, pages 25 36, NY, USA, 25. ACM Press. [7] Gordon P. Gu and D. Peru. XSLT ransformaon from UML models o LQN performance models. In WOSP 2:Proceedngs of he 3rd Inernaonal Workshop on Sofware and Performance. ACM Press, 22. [8] Danel A. Menascé; and Hassan Gomaa. A mehod for desgn and performance modelng of clen/server sysems. IEEE Transacons on Sofware Engneerng, 26(11): , 2. [9] Davd Mosberger and Ta Jn. hperf: a ool for measurng web server performance. SIGMETRICS Performance Evaluaon Revew, 26(3):31 37, [1] Dorn C. Peru and C. Murray Woodsde. Sofware performance models from sysem scenaros n use case maps. In TOOLS 2: Proceedngs of he 12h Inernaonal Conference on Compuer Performance Evaluaon, Modellng Technques and Tools, pages , London, UK, 22. Sprnger-Verlag. [11] Paul Reeser and Rema Harharan. Analyc model of web servers n dsrbued envronmens. In WOSP : Proceedngs of he 2nd Inernaonal Workshop on Sofware and Performance, pages , NY, USA, 2. ACM Press. [12] J. A. Rola and K. C. Sevck. The mehod of layers. IEEE Transacons on Sofware Engneerng, 21(8):689 7, [13] Rukma P. Verlekar. Perfcener: A mehodology and ool for performance analyss of applcaon hosng ceners. Techncal repor, Deparmen of Compuer Scence and Engneerng, Indan Insue of Technology Bombay, 27. [14] C. Murray Woodsde, John E. Nelson, Dorna C. Peru, and Shkharesh Majumdar. The sochasc rendezvous nework model for performance of synchronous clen-server-lke dsrbued sofware. IEEE Transacons Compuers, 44(1):2 34, [15] Murray Woodsde. Layered queueng nework solver. LQNSolver Homepage, hp:// hml, November [16] Jng Xu, Alexandre Oufmsev, Murray Woodsde, and Lam Murphy. Performance modelng and predcon of enerprse javabeans wh layered queung nework emplaes. In SAVCBS 5: Proceedngs of he 25 Conference on Specfcaon and Verfcaon of Componen-Based Sysems. ACM Press, 25. [17] Jng Xu, Murray Woodsde, and Dorna Peru. Performance Analyss of a Sofware Desgn Usng he UML Profle for Schedulably, Performance and Tme, volume 2794 of Lecure Noes n Compuer Scence. Sprnger, 23.