Resource Provisioning in an E-commerce Application - Amazon Web ...

Resource Provisioning in an E-commerce Application∗ Jijun Lu and Swapna S. Gokhale Department of Computer Science and Engineering University of Connecticut, Storrs, CT 06269, USA {jijun.lu, ssg}@engr.uconn.edu Abstract It is the responsibility of an e-commerce provider to provision resources to ensure that the performance of the services provided by an e-commerce application is acceptable. A quantitative estimate of the performance expected from the site, obtained from the expected workload imposed on the application, may allow the provider to make informed decisions with respect to the right level of resources so that acceptable service performance may be offered in a costeffective manner. In this paper we first present a systematic methodology to estimate the performance expected from an e-commerce application based on the representation of the e-commerce workload. Subsequently, we discuss how the estimate of the expected application performance could guide resource provisioning decisions. We illustrate the performance estimation and resource provisioning methodology using the TPC-W benchmark.

1. Introduction and motivation E-commerce, which involves commercial transaction of goods and services between different parties electronically mainly through open Internet-based systems rather than physical exchange or contact is rapidly becoming a prominent way of conducting business. To encourage customers to prefer e-commerce services over their traditional on-site counterparts, it is necessary that the performance of the online services be superior. A customer unsatisfied with service performance may cancel the transaction and may even turn to the competitor’s sites. At the minimum, this will result in a financial loss for the provider. It may also tarnish the provider’s reputation and may discourage the customer from ever using the site again. Thus, service performance is of paramount importance in ensuring the success of an ∗ The research at Univ. of Connecticut was supported by a CAREER award from NSF (#CNS-0643971).

e-commerce site1 [3]. To ensure superior service performance, it is necessary to provision an adequate level of resources. Resource provisioning may be guided based on an intuitive or a heuristic expectation of performance. Provisioning based on heuristics and intuition, however, may lead to more resources than are actually necessary. While such overprovisioning may guarantee performance, this guarantee may come at a very high cost. A quantitative performance estimate may guide the provider in making informed decisions about the right level of resources, so that acceptable service performance may be provided in a cost-effective manner. A quantitative estimate of application performance must consider its workload characteristics. Unlike other Web applications, an e-commerce application serves a large number of requests that may be presented in many different sequences. Due to these complex workload characteristics of an e-commerce application, estimation of its performance is not straightforward. A systematic performance estimation methodology based on the representation of e-commerce workload is thus necessary and is the focus of this paper. Subsequently, we discuss how the performance estimate could guide the provisioning of resources. We illustrate the methodology using the TPC-W benchmark. The layout of the paper is as follows: Section 2 provides an overview of DTMCs. Section 3 provides an overview of the e-commerce workload. Section 4 presents the performance analysis and provisioning methodology. Section 6 illustrates the methodology using the TPC-W benchmark. Section 7 summarizes the related research. Section 8 offers concluding remarks and directions for future research.

2. Overview of DTMCs We provide an overview of irreducible discrete time Markov chains (DTMCs) [15], which is the modeling paradigm used to represent the e-commerce workload. 1 The terms e-commerce site, e-commerce application, site and application are used interchangeably in this paper.

A DTMC is characterized by its one-step transition probability matrix P = [pi,j ]. A DTMC is said to be irreducible if every state can be reached from every other state. The steady state probability vector, π of an irreducible DTMC can be computed by solving the following equations [15]: π =π·P π·e=1

(1)

where e = (1, 1, . . . , 1)T and the superscript T denotes the transpose. The entries of π represent the limiting probabilities of finding a system in each of the states [15].

3. E-commerce workload A customer2 interacts with an e-commerce application through a series of consecutive and related requests. This request sequence is termed as a session, and the sequence in a single session is known as a navigational pattern. The navigational pattern of a group of customers may be represented by a Customer Behavior Model Graph (CBMG) [11]. A CBMG is a state transition graph in which: (i) states represent the type of requests that can be presented to an e-commerce site, and (ii) transitions between the states represent the sequencing among these request types. State transitions are usually probabilistic, which captures the random nature of the sequence of requests that may be presented. A CBMG also includes the time spent in thinking between two types of requests. Stated formally, think time refers to the time elapsed from the the last byte received by the client in a transaction until the first byte sent by the client to request the next interaction [14]. Mathematically, a CBMG can be represented by a pair (W, Z) of n × n matrices, where n is the number of states. W = [wi,j ] contains the transition probabilities between the states. The matrix Z = [zi,j ] contains the average think times between consecutive pairs of requests i and j. A CBMG may be automatically extracted from Web logs [4]. In the early stages, it may also be extracted from the design documents. For instance, if the functional structure of a site is depicted using UML, CBMG would be just a flat representation of the top-level statechart describing the logic of the navigation possibilities. Users of an e-commerce application are categorized into different groups, each group with its own navigational pattern. This gives rise to multiple CBMGs, each corresponding to a single user group. These multiple CBMGs will have the same set of states but different transition probabilities which reflect the distinct characteristics of different groups. The workload presented to an e-commerce application depends on the CBMGs of each group of users, and also on the distribution or the mix of the different groups. 2 The

terms user and customer are used interchangeably in this paper.

4. Analysis and provisioning methodology In this section we first describe an analysis methodology to estimate the performance of an e-commerce application. We then discuss how the performance estimates obtained from the analysis could be used to guide resource provisioning decisions.

4.1. Performance analysis Performance analysis of an e-commerce application can be addressed from two perspectives: end-user’s and service provider’s. Metrics such as response time, session length and session availability, are important from a user’s perspective since they are directly related to his/her shopping experience. On the other hand, metrics such as throughput and resource usage are more important from a provider’s perspective since they can guide the selection of the most cost-efficient hardware and software configuration(s). In our previous paper [6], we proposed a methodology to estimate user-perceived site performance. In this paper, we consider the performance from a provider’s perspective, which is given by the throughput of different types of requests. The rationale behind using request-level throughputs rather than the aggregated throughput across all request types is that the workload of different request types may vary dramatically, and aggregation may not capture these variations adequately. Request-level throughput, however, can provide information of finer granularity, which could be additionally helpful in provisioning resources. The request-level throughput will be determined by the navigational pattern of each group and the distribution of groups. We consider m user groups, with their distribution denoted by O1 , O2 , . . ., Om . We consider n request types in each pattern. A group’s pattern is mapped to a DTMC as follows. Each request type corresponds to a DTMC state, whereas the transition probabilities map to the state transition matrix P. Thus, the DTMCs of all the groups have the same set of states but different Ps. For a user group i, let the request probabilities obtained from Equation (1) be denoted by πi = (π1,i , π2,i , . . . , πn,i ), where πj,i represents the likelihood that a request from user i is of type j. Let the the think time be denoted τ . Thus, the rate at which requests are presented is 1/τ . Finally, the rate at which user type i presents a request of type j is πj,i ×1/τ . We let N denote the total number of users accessing the site in the steady state. Notice that it may be difficult to estimate N prior to the deployment of a site. Hence, as such, N could either be the peak or average number of users. The methodology is flexible to accommodate any choice of N and would provide an estimate of either the peak or average throughput accordingly. The provider can thus choose the peak or average population size. A peak N could be used

if conservative provisioning is desired, whereas, an average N could be used for optimistic provisioning. Based on N , the expected throughput for request type j is given by: Sj =

m  1 πj,i · N · Oi τ i=1

(2)

4.2. Resource provisioning The architecture of an e-commerce application typically consists of three tiers as shown in Figure 1. The presentation tier consists of a front-end Web server, the application server is in the second tier, the home of the business logic. The back-end database resides in the data tier. The Web server intercepts the client calls and redirects them to the application server to perform the processing. The application server makes calls as needed to the back-end database.

Figure 1. Three-tier architecture of an ecommerce application

n 

Sj Ij,w

Tw  (4) Cw Similar expressions can be obtained for the minimum number of servers in the application and database tiers, denoted Na and Nd respectively. The provider may also include a few additional servers over the minimum required number for fault tolerance to ensure that the performance is sustained even when a few servers fail. Such redundancy is an effective means to improve application availability. Nw = 

5. TPC-W benchmark TPC-W is a transactional Web benchmark specifically designed for evaluating business oriented transactional Web sites [14]. We choose the TPC-W benchmark to illustrate our approach because of its wide use in research areas such as workload characterization of e-commerce sites [2, 5]. The TPC-W benchmark has fourteen types of Web interactions or requests as in Table 1. Each interaction can be classified as either “Browse” or “Order” depending on whether it involves browsing and searching on the site or whether it plays an explicit role in ordering [14]. The CBMG for TPC-W interactions is shown in Figure 2. Table 1. Request types in TPC-W

Referring to the architecture in Figure 1, the primary resources include the servers in each tier, which will depend on the throughput and processing time expectations from the tier, which will further depend on the workload and the application characteristics. To determine the number of servers in each tier, we first obtain an estimate of each tier’s expected throughput. Let Ij,k , k = w, a, d denote an indicator function to express the tiers through which a request of type j traverses. Thus, a request type j traversing Web and application tiers would have Ij,w = 1, Ij,a = 1, Ij,d = 0. A Web service for mathematical computations could service this kind of a request. The expected Web tier throughput denoted Tw is given by Equation (3). Similar expressions can be obtained for application and database tier throughputs Ta and Td . Tw =

to be provisioned in the Web tier, denoted Nw is given by:

(3)

j=1

Let Cw , Ca and Cd denote the capacity of the individual servers in the Web, application and database tiers respectively. The capacity of a server is the throughput that can be sustained by the server, while maintaining a reasonable processing time. The minimum number of servers that need

# 1 2 3 4 5 6 7 8 9 10 11 12 13 14

Name ADMC ADMR BESS BUYC BUYR CREG HOME NEWP ORDD ORDI PROD SREQ SRES SHOP

Description Admin Confirm Admin Request Best Seller Buy Confirm Buy Request Customer Registration Home New Products Order Display Order Inquiry Product Detail Search Request Search Results Shopping Cart

Type Order Order Browse Order Order Order Browse Browse Order Order Browse Browse Browse Order

TPC-W simulates three different groups or patterns by varying the ratio of browse to buy: primarily shopping (WIPS), browsing (WIPSb) and Web-based ordering (WIPSo). WIPS (Web Interactions Per Second) is the primary group, based on an average shopping scenario, while WIPSb and WIPSo are secondary groups. The interaction mix for WIPSb is primarily browsing, and the mix for WIPSo involves a significant percentage of ordering resulting in transaction processing [14]. Each TPC-W request has a set of navigation options, which determine the next request selected by the client after the present request is fulfilled. An integer between 1

6.1. Performance estimation The transition matrices of the patterns are solved to obtain the request probabilities in Table 3. Table 3. Request probabilities

Figure 2. CBMG for TPC-W workload and 9,999, called a threshold, is assigned to each navigation option [14]. To select its next request the client generates a random number from a uniform distribution between 1 and 9,999 and then selects an option for which the threshold is equal to or most immediately greater than the random number [14]. The transition probabilities of the DTMC are computed from the thresholds as follows: ⎧ 0, ti,j = NULL; ⎪ ⎪ ⎪ ⎨ 1 ti,j , for first ti,j > 0 9999 pi,j = in each row; ⎪ ⎪ 1 ⎪ (ti,j − max{ti,k }), all others ti,j ⎩ 9999 k