Performance Analysis of a Middleware Demultiplexing Pattern

U. Praphamontripong, S. Gokhale Aniruddha Gokhale Jeff GrayDept. of CSE Dept. of EECS Dept. of CIS

Univ. of Connecticut Vanderbilt Univ. U. of Alabama at BirminghamStorrs, CT 06269 Nashville, TN 37235 Birmingham, AL 35294

ssg@engr.uconn.edu a.gokhale@vanderbilt.edu gray@cis.uab.edu

Abstract

A key enabler of the recently adopted, assembly-centric development approach for distributed real-time soft-ware systems is QoS-enabled middleware, which providesreusable building blocks in the form of design patterns thatcodify solutions to commonly recurring problems. Thesepatterns can be customized by choosing an appropriate setof configuration parameters. The configuration options ofa pattern exert a strong influence on system performance,which especially for real-time systems is of paramount im-portance. Despite this significant influence, currently thereare no techniques available to analyze performance at de-sign time, prior to the use of a pattern in a system.

Many software systems are based on an event-drivenparadigm, primarily because it fosters evolvability andcomposability. The event demultiplexing and dispatchingcapabilities that are uniform across such systems are encap-sulated in the Reactor pattern, which can be used to facil-itate their development. Design-time performance analysisof these event-driven systems thus requires a model of theReactor pattern. In this paper, we present a performancemodel of the Reactor pattern based on the Stochastic Re-ward Net (SRN) modeling paradigm. We discuss how themodel can be used to obtain performance metrics such asthroughput, loss probability and upper and lower boundson the response time. We illustrate the use of the model toguide the selection of configuration options and for sensitiv-ity analysis using a case study of a handheld mobile device.We also validate the performance estimates obtained fromthe model using simulation.

1 Introduction

Society today is increasingly reliant on the services pro-vided by distributed real-time software systems. These ser-vices have permeated our lives and have become prevalent

in many domains including health care, finance, telecom-munications and avionics. In many of these domains, theperformance of a service is just as important as the func-tionality provided by the service.

To counter the dual pressures of developing systemswhich offer a rich menu of services with superior perfor-mance, while simultaneously reducing their time to market,service providers are increasingly favoring the assembly-centric approach over the traditional development-centricapproach. A key facilitator of this assembly-centric ap-proach has beenQoS-enabled middleware[1]. Middle-ware consists of software layers that provide platform-independent execution semantics and reusable services thatcoordinate how system components are composed and in-teroperate. Middleware offers a large number of reusablebuilding blocks in the form of design patterns [2, 3], whichcodify solutions to commonly recurring problems. Thesepatterns can be customized with an appropriate set of con-figuration parameters as per system requirements.

The choice of configuration parameters have a profoundinfluence on the performance of a pattern and hence a sys-tem implemented using the pattern. Despite the influence onsystem performance, which is crucial for real-time systems,current methods of selecting the patterns and their config-uration options are manual,ad-hocand hence error-prone.The problem is further compounded, because there are notechniques available to analyze the impact of different con-figuration parameters on the performance of a pattern priorto building a system. Performance analysis is thus invari-ably conducted after a system is assembled, and it is of-ten too late and too expensive to take corrective action if aparticular selection of patterns and their configuration para-meters cannot satisfy the desired performance expectations.The capability to conduct design-time performance analy-sis of middleware patterns and the composition of these pat-terns is thus necessary, especially for systems with stringentperformance requirements.

A growing number of software systems are being based

1

on an event-driven paradigm [4], which constitutes aprovider/listener model [5]. In this paradigm, the systemlistens for service requests or “events” and provides the nec-essary services in response to these requests. These ser-vice requests may be issued by end-users or by other sys-tems. In the latter case, an event-driven system may beviewed as a component of a larger composition of systems,or systems-of-systems. Event-driven systems provide manyadvantages, the most prominent ones being evolvability andcomposability. Evolvability is enabled by the separation ofevent demultiplexing and dispatching from event handling.Composability is enabled by the ability to invoke a servicetransparently without any knowledge of its underlying im-plementation. Although event handling is specific to a sys-tem, the event demultiplexing and dispatching functional-ity is uniform across all the systems that follow the event-driven style. The event demultiplexing and dispatching ca-pability is codified into a middleware pattern called theRe-actorpattern [3]. This pattern can be reused to facilitate thedevelopment of event-driven systems.

To enable design-time performance analysis of Reactor-based, event-driven systems, a model which captures thedemultiplexing and dispatching functionality encapsulatedby the Reactor pattern is essential. This paper describes aperformance model of a Reactor-based system based on theStochastic Reward Net (SRN) modeling paradigm [6]. Wediscuss how the model can be used to obtain performancemetrics such as throughput, loss probability, and upper andlower bounds on the response time. We illustrate the useof the model to guide the selection of configuration optionsand for sensitivity analysis using a case study of a hand-held mobile device. We validate the performance estimatesobtained from the model using simulation.

The organization of the paper is as follows: Section 2provides an overview of the Reactor pattern and Section 3briefly reviews the SRN modeling paradigm. Section 4 dis-cusses the performance analysis methodology. Section 5illustrates the use of the methodology using a case study.Section 6 summarizes the related research. Section 7 offersconcluding remarks and future research directions.

2 Overview of the Reactor pattern

Figure 1 depicts a typical event demultiplexing and dis-patching mechanism documented in the Reactor pattern [3].The system registers an event handler with the event demul-tiplexer and delegates to it the responsibility of listening toincoming events. On the occurrence of an event, the demul-tiplexer dispatches the event by making a callback to thecorrect system-supplied event handler. This is the idea be-hind the Reactor pattern, which provides synchronous eventdemultiplexing and dispatching capabilities.

The dynamics of the Reactor pattern can be categorized

Figure 1. Event demultiplexing pattern

into two phases [3]:

1. Registration phase: In this phase all the event han-dlers register with the Reactor associating themselveswith a particular event type they are interested in.Event types usually supported by a Reactor are in-put, output, timeout and exceptions. The Reactor willmaintain a set of handles corresponding to each han-dler registered with it.

2. Snapshot phase: After the event handlers have com-pleted their registration, the main thread of control ispassed to the Reactor, which in turn listens for eventsto occur. A snapshot represents an instance in timewherein a Reactor determines all the event handlesthat are enabled at that instant. For all the event han-dles that are enabled in a given snapshot, the Reactorproceeds to service each event by invoking the asso-ciated event handler. There could be different strate-gies to handle these events. For example, a Reactorcould handle all the enabled events sequentially in asingle thread or could hand it over to worker threadsin a thread pool. After all the events are processed, theReactor proceeds to take the next snapshot.

3 Stochastic Reward Nets (SRNs)

In this section we provide an overview SRNs, which isthe modeling paradigm used in the analysis methodology.The details of SRNs can be obtained from elsewhere [6].

A SRN is a directed graph, which contains two typesof nodes:placesand transitions. A directed arc connect-ing a place (transition) to a transition (place) is called aninput (output) arc. Arcs are associated with a positive in-teger called themultiplicity. Places can containtokensthatmove from one place to another through transitions. A tran-sition is enabled when each of the places connected to itby its input arc have at least the number of tokens equal to

2

the multiplicity of those arcs. When an enabled transitionfires, a number of tokens equal to the input arc multiplic-ity is removed from each of the corresponding input places,and a number of tokens equal to the output arc multiplic-ity is deposited in each of the corresponding output places.A SRN may also include aninhibitor arc, which can alsohave a multiplicity associated with it. An inhibitor arc in-hibits the transition it is connected to if the place it is con-nected to at its other end has a number of tokens equal to atleast its multiplicity. The state of a SRN withP places isrepresented by a vector(m1, m2, · · · , mp) called themark-ing of the SRN, wheremi is the number of tokens in placei. A SRN marking with at least one immediate transitionenabled is called avanishing marking, and a marking withno immediate transitions enabled is called atangible mark-ing. A reward function may be associated with each tan-gible marking of a SRN. A reward function is a functionof a SRN marking that accepts the number of tokens inone or more places of a SRN as input and evaluates to areal number. This function is usually designed to quantifythe “value” that the system provides in a state. The tangi-ble markings of a SRN and the rates of transition amongthem are equivalent to the corresponding states and statetransitions of an underlying continuous time Markov chain(CTMC) [7]. Hence, a SRN can be mapped into an equiv-alent Markov reward model (MRM) [6], automatically us-ing software tools such as the Stochastic Petri Net Package(SPNP) [8]. SRN models allow a concise specification ofvarious reward functions. To extend the power of specifica-tion, a SRN may also include the specification ofenabling(or guard) functionsfor each transition. The transition isenabled only if the enabling function returns one.

SRNs substantially extend the modeling power of Gener-alized Stochastic Petri Nets (GSPNs) [9], which are an ex-tension of Petri nets [10]. SRNs represent a powerful mod-eling technique with concise specification and form closerto a designer’s intuition. As a result, it is also easier to trans-fer the results obtained from solving the models and inter-pret them in terms of the entities in the modeled system.SRNs have been extensively used for performance and re-liability analysis of a variety of systems including clustersystems, polling systems, and wireless networks [7].

4 Performance analysis methodology

In this section we describe the performance analysismethodology for a Reactor-based system.

4.1 System characteristics

We consider an event-driven system which uses a single-threaded, select-based Reactor with the following charac-teristics, as shown in Figure 2:

Figure 2. Characteristics of the Reactor-based system

• The system offers two types of services and hence re-ceives two types of requests; one for each. The Reactorpattern used to implement the system thus receives twotypes of input events1 with one event handler for eachtype of event registered with the Reactor.

• In the system, each event type has a separate queue tohold the incoming events of that type. The buffer ca-pacities for the queues of type #1 and type #2 eventsare denotedN1 and N2, respectively. We note thatevent queues are not a part of the Reactor pattern it-self, but are a part of the overall system.

• Event arrivals for both types of events follow a Poissondistribution with ratesλ1 andλ2.

• The service times of the events are exponentially dis-tributed with ratesµ1 andµ2.

• In a given snapshot, if the event handles correspondingto both the event types are enabled, then they are ser-viced in no particular order. Thus, the order in whichthe events are handled is non-deterministic.

1Due to the one-to-one mapping between a service request and anevent, we use these two terms interchangeably in the rest of the paper.

3

4.2 Performance metrics

The following performance metrics are of interest foreach service type provided by the Reactor-based system:

• Throughput – which provides an estimate of the num-ber of service requests that can be processed by thesystem. These estimates are important for many sys-tems, such as telecommunications call processing.

• Queue length – which provides an estimate ofthe queuing for each of the event handler queues.These estimates are important to develop appropriatescheduling policies for real-time systems.

• Probability of event loss – which indicates how manyevents will have to be discarded due to the lack ofbuffer space. These estimates are important particu-larly for safety-critical systems, which cannot affordto lose events. These also provide an estimate of thedesired levels of resource provisioning.

• Response time – which indicates the total time takenby the system to complete the service in response to aservice request. In addition to obtaining an estimate ofthe average response time, it is also necessary to esti-mate the upper and the lower bounds on the responsetime. The upper bound estimate can be used to deter-mine if the deadlines can be met in the worse case forreal-time services.

4.3 Performance model

In this section we introduce the performance model ofa Reactor-based system described in Section 4.1 using theSRN paradigm. We first describe the structural aspects ofthe net, followed by its dynamic evolution and finally adiscussion of the assignment of the reward functions.

Description of the net: The net shown in Figure 3 is com-prised of two parts. Part (a) models the arrival, queuing,and service of the two types of events. TransitionsA1 andA2 represent the arrivals of the events of type #1 and #2,respectively. PlacesB1 andB2 represent the queues for thetwo types of events. TransitionsSn1 andSn2 are imme-diate transitions that are enabled when a snapshot is taken.PlacesS1 andS2 represent the enabled handles of the twotypes of events, whereas transitionsSr1 andSr2 representthe execution of the enabled event handlers of the two typesof events. An inhibitor arc from placeB1 to transitionA1with multiplicity N1 prevents the firing of transitionA1when there areN1 tokens in placeB1. The presence ofN1 tokens in placeB1 indicates that the buffer to hold theinput events of type #1 is full, and no additional events can

be accepted. The inhibitor arc from placeB2 to transitionA2 achieves the same purpose for type #2 events.

Part (b) models the process of taking successive snap-shots and non-deterministic service of event handles ineach snapshot as follows. TransitionSn1 is enabled whenthere are one or more tokens in placeB1, a token in placeStSnpSht, and no token in placeS1. Similarly, transitionSn2 is enabled when there are one or more tokens in placeB2, a token in placeStSnpSht and no token in placeS2.Transition T StSnp1 and T StSnp2 are enabled whenthere is a token in either placeS1 or S2 or both. TransitionsT EnSnp1 andT EnSnp2 are enabled when there are notokens in both placesS1 andS2. TransitionT ProcSnp2is enabled when there is no token in placeS1, and a tokenin placeS2. Similarly, transitionT ProcSnp2 is enabledwhen there is no token in placeS2 and a token in placeS1.TransitionSr1 (Sr2) is enabled when there is a token inplaceSnpInProg1 (SnpInProg2). Table 1 summarizesthe enabling functions for the transitions in the net.

Dynamic evolution of the net: We explain the process oftaking a snapshot and servicing the enabled event handlesin the snapshot, with a scenario where there is one tokeneach in placesB1 and B2. Because there are tokens inplacesB1, B2 andStSnpSht, transitionsSn1 and Sn2are enabled. Both of these transitions are assigned the samepriority, and hence either one of them can fire. Withoutloss of generality, we assume that transitionSn1 fires first,which deposits a token in placeS1. The presence of atoken in placeS1 and placeStSnpSht enables transitionT StSnp1. Also, transitionSn2 is already enabled. IftransitionT StSnp1 were to fire before transitionSn2, thefiring of transitionSn2 would be precluded. In order toprevent this from happening, transitionSn2 is assigned ahigher priority than transitionT StSnp1, so that transitionSn2 fires beforeT StSnp1 when both are enabled. Firingof transition Sn2 deposits a token in placeS2 whichenables transitionT StSnp2. TransitionsT StSnp1 andT StSnp2 are both enabled, corresponding to the eventhandles of both types of events. If transitionT StSnp1fires beforeT StSnp2, then the event handle for type#1 event will be executed prior to the event handle fora type #2 event. However, ifT StSnp2 fires beforeT StSnp1, then the event handle for a type #2 event willbe executed prior to event handle for a type #1 event. Boththe transitionsT StSnp1 and T StSnp2 have an equalchance of firing, and this represents the non-determinism inthe execution of the enabled event handles. Without loss ofgenerality, we assume transitionT StSnp1 fires depositinga token in placeSnpInProg1, which enables transitionSr1. Additionally, firing of transitionT StSnp1 precludesthe firing of transitionT StSnp2 and vice versa. OncetransitionSr1 fires, a token is removed from placeS1, after

4

Figure 3. SRN model of the Reactor pattern

Table 1. Guard functionsTransition Guard function

Sn1 ((#StSnpShot == 1)&&(#B1 >= 1)&&(#S1 == 0))?1 : 0Sn2 ((#StSnpShot == 1)&&(#B2 >= 1)&&(#S2 == 0))?1 : 0

T StSnp1 ((#S1 == 1)||(#S2 == 1))?1 : 0T StSnp2 ((#S1 == 1)||(#S2 == 1))?1 : 0

T ESnpSht1 ((#S1 == 0&&(#S2 == 0))?1 : 0T ESnpSht2 ((#S1 == 0&&(#S2 == 0))?1 : 0T ProcSnp1 ((#S1 == 1&&(#S2 == 0))?1 : 0T ProcSnp2 ((#S1 == 0&&(#S2 == 1))?1 : 0

Sr1 (#SnpInProg1 == 1)?1 : 0Sr2 (#SnpInProg2 == 1)?1 : 0

which transitionT ProcSnp2 fires and deposits a tokenin placeSnpInProg2. A token in placeSnpInProg2enables transitionSr2, the firing of which removes thetoken from placeS2. OnceSr2 fires, there are no tokensin placesSnpInProg1 andSnpInProg2, which enablestransitionT EnSnp2. The firing ofT EnSnp2 marks thecompletion of the present snapshot, and the beginning ofthe next one.

Assignment of reward functions: The performance mea-sures for event type #1 can be obtained by assigning thereward functions summarized in Table 2. These rates areobtained using the following reasoning. The throughputT1

is given by the rate at which transitionSr1 fires. The queuelengthQ1 is given by the number of tokens in placeB1.The loss probabilityL1 is given by the probability ofN1 to-kens in placeB1. The reward functions to obtain the lowerand the upper bounds of the response time are determinedusing the tagged customer approach [11], in which the tra-jectory of an arriving event is followed until its exit. Theresponse time of the tagged event is determined for eachpossible system state when the event arrives. The expected

response time is given by the weighted sum of the responsetimes in each system state, with the weights given by theoccurrence probabilities of each state.

To determine the response time of a tagged type #1 event,we define the system state as the number of tokens or mark-ings of placesS1, S2, B1 andB2. The markings of placesS1 andS2 determine the progress of the ongoing snapshotwhen the tagged event arrives. Even if the queues are empty,this ongoing snapshot must be completed before the taggedevent can be serviced. The time taken to complete the ongo-ing snapshot isS1 × 1

µ1

+ S2 × 1

µ2

. To determine the con-tribution of the events in the queues to the response time,we let n1 andn2 denote the number of events of type #1and #2 in the queues, when the tagged type #1 event ar-rives. Because there aren1 events in the queue of type #1events, the tagged event will be serviced aftern1 snapshots.If n1 ≤ n2, the service time of the firstn1 snapshots will ben1 × (1/µ1 + 1/µ2). In the snapshot in which the taggedevent is serviced, there is a50% chance that an event oftype #2 will be serviced before the tagged event. Thus, theservice time of the snapshot in which the tagged event isserviced is given by1/µ1 +0.5/µ2. If n1 > n2, the service

5

Table 2. Reward functions for performance measuresPerformance metric Reward function

T1 return rate(Sr1)T2 return rate(Sr2)Q1 return (#B1)Q2 return (#B2)L1 return (#B1 == N1?1 : 0)L2 return (#B2 == N2?1 : 0)R1,l if (#B1 < N1) {

if (#B1 < #B2)return((1/µ1 ∗ (#S1 + #B1 + 1) + 1/µ2 ∗ (#S2 + #B1)))elsereturn((1/µ1 ∗ (#S1 + #B1 + 1) + 1/µ2 ∗ (#S2 + #B2))) }

else return(0.0)R1,u if (#B1 < N1)

return((1/µ1 ∗ (#S1 + #B1 + 1) + 1/µ2 ∗ (#S2 + #B1 + 0.5)))elsereturn(0.0)

R2,l if (#B2 < N2) {if (#B2 < #B1)return((1/µ2 ∗ (#S2 + #B2 + 1) + 1/µ1 ∗ (#S1 + #B2)))elsereturn((1/µ2 ∗ (#S2 + #B2 + 1) + 1/µ1 ∗ (#S1 + #B1))) }

else return(0.0)R2,u if (#B2 < N2)

return((1/µ2 ∗ (#S2 + #B2 + 1) + 1/µ1 ∗ (#S1 + #B2 + 0.5)))elsereturn(0.0)

time of the firstn2 snapshots will ben2 × (1/µ1 + 1/µ2).During the firstn2 snapshots, in the best situation, no addi-tional type #2 events will arrive. Then the service time ofthe(n2+1)st throughn1

st snapshot is(n1−n2)×1/µ1, andthe service time of the snapshot in which the tagged event isserviced is1/µ1. In the worse case, however, an additionaln1 − n2 + 1 events of type #2 will arrive in the firstn2

snapshots, in which case, the service time of the(n2 + 1)st

throughn1st snapshots will be(n1 −n2)× (1/µ1 +1/µ2).

The service time of the snapshot in which the tagged eventis serviced is the same as in the case whenn1 ≤ n2. Basedon this reasoning, the upper and the lower bounds of the re-sponse time of type #1 events, denotedR1,u andR1,l, canbe obtained using the reward functions in Table 2.

4.4 Model variations

In the SRN model of the Reactor-based system, the ar-rival and the service time distributions are assumed expo-nential to facilitate a discussion of the process of building aSRN-based model. This assumption may not hold in certaintypes of systems. For example, in safety-critical systems,

events may occur periodically, hence the arrival process isdeterministic. The arrival and service times may also followany other non-exponential or general distributions, whichcan be considered in the SRN model using two methods. Inthe first method, a non-exponential distribution can be ap-proximated using a phase-type approximation [6], and theresulting SRN model can then be solved using SPNP [8]. Inthe second method, the model can be simulated using thediscrete-event simulation in SPNP [8].

5 Case study

In this section we illustrate the use of the performanceanalysis methodology described in Section 4 with a casestudy of a handheld mobile device. Figure 4 illustrates atypical software architecture for event demultiplexing anddispatching in mobile handhelds. Handhelds, such as PDAs,have been at the forefront of ubiquitous computing and arebecoming increasingly complex due to the need to supportmultiple applications, such as email, web browsing, calen-dar management, multimedia support, and games. Because

6

these handhelds are used in many critical domains (e.g., pa-tient health care monitoring and emergency response sys-tems), they must provide exceptional performance.

Figure 4. Event demultiplexing in handhelds

The application mix available in the handhelds is aptlysuited for event-driven systems, which require demultiplex-ing and dispatching events to the correct event handlers inthe handheld. For example, a user of the handheld couldhave set appointments in his/her calendar, which might raisean event while the user may be in the midst of web brows-ing. Similarly, it is conceivable that email notification ar-rives while the user is in the midst of web browsing or lis-tening to an MP3 song. In the context of handhelds that aretailored to provide service to emergency response person-nel, one could conceive of scenarios where sensor data froma phenomenon of interest is received by the handheld withother notifications, such as Short Message Service (SMS)notifications from command and control.

For the sake of illustration, we consider a handheld sys-tem which provides two services; namely, the SMS andemail service. To implement this service mix, the Reac-tor pattern with the characteristics described in Section 4.1can be used for demultiplexing the requests. Because of thereal-time nature of SMS notifications, it is necessary to keepthe response time of these notifications below an acceptablethreshold. In addition, the probability of rejecting emailmessages and SMS notifications must be negligible. TheSRN model of the Reactor-based system can guide the se-lection of configuration and provisioning options to achievethe performance objectives outlined above. To use the SRNmodel, we designate the SMS notification and email mes-sage requests as events of type #1 and #2, respectively.

We designed two experiments to demonstrate the use ofthe SRN model. In each experiment, performance estimateswere obtained by solving the SRN model using SPNP [8].The estimates obtained from the SRN model were alsovalidated using simulation implemented using CSIM [12],

a general purpose language used to build simulation models.

Experiment I: Impact of buffer capacityThe first experiment assesses the influence of a system con-figuration parameter, namely, the buffer capacity on the ser-vice performance. The allocation of buffer capacity willhave a direct impact on the performance metrics, most no-tably on the loss probabilities of service requests.

We analyze the impact of two settings of the buffer ca-pacities,N1 = N2 = 1 andN1 = N2 = 5 on the perfor-mance measures. The arrival ratesλ1 andλ2 were set to0.4/s and the service ratesµ1 andµ2 were set to2.0/s. Theperformance metrics for both of these cases are summarizedin Table 3. Because the parameters for SMS service (λ1, µ1

andN1) are the same as the parameters of email service (λ2,µ2, andN2), the performance estimates are nearly similarfor both types of services. Thus, performance estimates foronly one service type are reported in Table 3.

It can be observed that the loss probability is significantwhen the buffer capacity is1 and is negligible when thebuffer capacity is5. Also, due to the higher loss probability,the throughput is slightly lower when the buffer capacity is1 and is almost identical to the arrival rate when the buffercapacity is5. Thus, for the arrival and service rates consid-ered, the buffer capacity must be at least5 to ensure verylow likelihood of losing service requests.

Table 3. Buffer capacity vs. performance

Measure Buffer spaceN1 = N2 = 1 N1 = N2 = 5

SRN CSIM SRN CSIMT1 0.37/sec. 0.37/sec. 0.40/sec. 0.40Q1 0.064 0.0596 0.12 0.115L1 0.064 0.00024R1,l 0.63 sec. 0.676 sec. 0.79 sec. 0.830 sec.

(average) (average)R1,u 0.86 sec. 1.08 sec.

The results in Table 3 indicate that the throughput, lossprobability and queue length obtained from the SRN modelare very close to the estimates obtained from simulation.Further, the average response time estimated from simula-tion lies within the upper and lower bounds of the responsetimes obtained from the SRN model. The SRN model canthus be used to determine an appropriate level of bufferprovisioning for specific arrival and service rates, therebyeliminating the need to conduct lengthy simulations.

Experiment II: Impact of request arrival ratesIn the early stages of the life cycle, it is rarely the case thatthe values of the input parameters can be estimated with cer-

7

tainty, which makes it imperative to analyze the sensitivityof the performance measures to the variations in the inputparameters for a given choice of configuration options.

In the second experiment, we analyzed the sensitivity ofthe performance measures to the input parameters; namely,the arrival rates of the service requests. The parametersλ1 andλ2 were varied one at a time in the range0.5/s to1.8/s, roughly in steps of0.025 and the expected perfor-mance measures were obtained using the SRN model andsimulation. The buffer capacities were set to5, since theresults of the previous experiment indicated that the lossprobabilities were negligible for this buffer capacity. Theservice rates were set to2.0/s.

Figure 5 shows the performance measures as a functionof λ1. The plots in the first and second column show themeasures for SMS and email services respectively. Theplots in the first, second, third and fourth rows respectivelyshow throughput, queue length, loss probability, and re-sponse time. The top-left plot indicates that the throughputof SMS notifications increases and keeps pace with the ar-rival rate till it is below1.1/s. When the arrival rate exceeds1.1/s, the throughput starts lagging the arrival rate, indicat-ing that the system cannot service the incoming SMS notifi-cations at the rate at which they arrive. The loss probabilityand the queue length increase afterλ1 = 1.1/s, indicatingthat the queue operates near capacity and results in a re-jection of SMS notifications leading to reduced throughput.Thus, if the arrival rate of SMS notifications exceeds1.1/s.,the buffer capacity of five is not sufficient to prevent lossof requests. The loss probability increases substantiallyifλ1 exceeds1.9/s, indicating that the system cannot sustainthe inflow of SMS notifications with its current event han-dling/service rate. Finally, referring to the last plot in thefirst column, the average response time of SMS notificationsis closer to the lower bound for low values ofλ1 and movescloser to the upper bound as the value ofλ1 increases. Theresponse time of SMS notifications may thus become unac-ceptable for the entire range of variation ofλ1 for a givenservice rate of2.0/s.

The throughput and the loss probability of email mes-sages is unaffected by an increase inλ1. The queue lengthand the response time of email messages shows only a slightincrease withλ1. This slight increase occurs because theprobability that a SMS notification will have to be servicedin each snapshot increases with increasingλ1. As a result,the effective service time of email messages increases caus-ing a rise in the queue length and the response time. Thetrend in the response time for email messages is similar tothe response time trend for SMS notifications; i.e., closerto the lower bound for lower values ofλ1 and to the upperbound for higher values. However, the difference betweenthe highest and the lowest response times for email mes-sages is smaller than the difference for SMS notifications.

Similar trends, with the roles of SMS notifications andemail messages reversed were observed whenλ2 was var-ied. Although the trends are similar, the implications aresignificantly different. As shown in Figure 5, when the ar-rival rate of SMS notifications increases, the response timeprovided by the system for these notifications increases andapproaches the pessimistic or upper bound. As indicatedearlier, the response time of SMS notifications may becomeunacceptable beyond a certain threshold, after which it maybecome necessary to improve the service rate of the eventhandler. When the arrival rate of email messages (λ2) in-creases, the response time of SMS notifications also in-creases, however, the increase is much smaller comparedto the increase whenλ1 increases. Thus, an increase in theresponse time of SMS notifications occurring due to an in-crease inλ2 may be tolerated, whereas, an increase due toan increase inλ1 may be unacceptable.

6 Related research

Performance and dependability analysis of some mid-dleware services and patterns has been addressed by a fewresearchers. Aldredet al. [13] develop Colored Petri Net(CPN) models for different types of coupling between theapplication components and with the underlying middle-ware. They also define the composition rules for composingthe CPN models if multiple types of coupling is used si-multaneously in an application. A dominant aspect of theseworks are related to application-specific performance mod-eling. In contrast, we are concerned with determining howthe underlying middleware that is composed for the systemsthey host will perform. Kahkipuro [14] propose a multi-layer performance modeling framework based on UML andqueuing networks for CORBA-based systems. The researchreported in this paper is concerned with performance analy-sis of a specific design pattern used in the development ofevent-driven systems. The work closest to the research pre-sented in this paper is by Ramaniet al. [15], where a per-formance model of the CORBA event service (a pattern forpublish/subscribe service) is developed.

To predict the quality attributes of an assembled com-plex system, it is necessary to compose the attributes of thecomponents comprising the system [16]. Along these lines,our future research is focused on developing techniques tocompose models of a collection of patterns to obtain theend-to-end performance of a system.

7 Conclusions and future research

In this paper we presented a performance model of theReactor-based system, which embodies the event demulti-plexing and dispatching capabilities that lie at the heart of

8

event-driven systems. The model is based on the StochasticReward Net (SRN) modeling paradigm and can be used fordesign-time performance analysis of Reactor-based, event-driven systems. We illustrated the model to guide the selec-tion of configuration parameters and for sensitivity analysiswith a case study of a handheld mobile device. We vali-dated the performance estimates obtained from the modelusing simulation.

State-space explosion, while solving the SRN modelmay be an issue as the queue sizes increase. Developingmodel decomposition strategies, which will alleviate thisproblem, preferably by providing an approximate analyt-ical solution is the topic of future research. Developingperformance models of other commonly used middlewarepatterns, such as the Proactor and Active Object [3] andschemes for the composition of performance modelscorresponding to the composition of patterns is also aconcern of the future.

AcknowledgmentsThis research was supported by the following grants fromthe National Science Foundation (NSF): Univ. of Con-necticut (CNS-0406376 and CNS-SMA-0509271), Vander-bilt Univ. (CNS-SMA-0509296) and Univ. of Alabama atBirmingham (CNS-SMA-0509342).

References

[1] R. E. Schantz and D. C. Schmidt, “Middleware fordistributed systems: Evolving the common structurefor network-centric applications,” inEncyclopedia ofSoftware Engineering, J. Marciniak and G. Telecki,Eds. New York: Wiley & Sons, 2002.

[2] E. Gamma, R. Helm, R. Johnson, and J. Vlissides,De-sign Patterns: Elements of Reusable Object-OrientedSoftware. Reading, MA: Addison-Wesley, 1995.

[3] D. C. Schmidt, M. Stal, H. Rohnert, andF. Buschmann, Pattern-Oriented Software Archi-tecture: Patterns for Concurrent and NetworkedObjects, Volume 2. New York: Wiley & Sons, 2000.

[4] J. W. S. Liu,Real-time Systems. New Jersey: PrenticeHall, 2000.

[5] M. Shaw and D. Garlan,Software Architecture: Per-spectives on an Emerging Discipline. Upper SaddleRiver: Prentice Hall, 1996.

[6] A. Puliafito, M. Telek, and K. S. Trivedi, “The evo-lution of stochastic Petri nets,” inProc. of WorldCongress on Systems Simulation, Singapore, Septem-ber 1997, pp. 3–15.

[7] K. S. Trivedi, Probability and Statistics with Relia-bility, Queuing and Computer Science Applications.John Wiley, 2001.

[8] C. Hirel, B. Tuffin, and K. S. Trivedi, “SPNP: Sto-chastic Petri Nets. Version 6.0,” inProc. of ComputerPerformance Evaluation: Modeling Tools and Tech-niques, 11th Intl. Conference, Lecture Notes in Com-puter Science 1786, 2000.

[9] R. A. Sahner, K. S. Trivedi, and A. Puliafito,Perfor-mance and Reliability Analysis of Computer Systems:An Example-Based Approach Using the SHARPESoftware Package. Boston: Kluwer Academic Pub-lishers, 1996.

[10] J. L. Peterson,Petri Net Theory and the Modeling ofSystems. Prentice-Hall, 1981.

[11] B. Melamed and M. Yadin, “Randomization proce-dures in the computation of cumulative-timed distribu-tions over discrete-state markov process,”OperationsResearch, vol. 32, no. 4, pp. 926–944, July-August1984.

[12] H. Schwetman, “CSIM reference manual (revision16),” Microelectronics and Computer TechnologyCorp., Austin, TX, Tech. Rep. ACA-ST-252-87.

[13] L. Aldred, W. M. P. van der Aalst, M. Dumas, andA. H. M. ter Hofstede, “On the notion of coupling incommunication middleware,” inProc. of Intl. Sympo-sium on Distributed Objects and Applications (DOA),Agia Napa, Cyprus, 2005, pp. 1015–1033.

[14] P. Kahkipuro, “Performance modeling framework forCORBA based distrbuted systems,” Ph.D. disserta-tion, Dept. of Computer Science, Univ. of Helsinki,Helsinki, Finland, May 2000.

[15] S. Ramani, K. S. Trivedi, and B. Dasarathy, “Perfor-mance analysis of the CORBA event service using sto-chastic reward nets,” inProc. of the 19th IEEE Sympo-sium on Reliable Distributed Systems, October 2000,pp. 238–247.

[16] I. Crnkovic, M. Larsson, and O. Preiss, “Concerningpredictability in dependable component-based sys-tems: Classification of quality attributes,” inBook onArchitecting Dependable Systems III, R. de Lemos,Ed. Springer-Verlag, 2005, pp. 257–278.

9

Figure 5. Sensitivity of performance measures to arrival ra te λ1

10