Managing Database Server Performance to Meet QoS Requirements in Electronic Commerce Systems *

Transcription

1 Managing Database Server Performance to Meet QoS Requirements in Electronic Commerce Systems * Abstract Patrick Martin 1, Wendy Powley 1, Hoi-Ying Li 1 and Keri Romanufa 2 1 Department of Computing and Information Science Queen's University Kingston, Ontario Canada K7L 3N6 2 IBM Toronto Laboratory Toronto, Ontario Canada M3C 1H7 The performance of electronic commerce systems will have a major impact on their acceptability to users. Different users will also demand different levels of performance from the system, that is, they will have different Quality of Service (QoS) requirements. Electronic commerce systems are the integration of several different types of servers and each server must contribute to meeting the QoS demands of the users. In this paper we focus on the role, and the performance, of a database server within an electronic commerce system. We examine the characteristics of the workload placed on a database server by an electronic commerce system and suggest a range of QoS requirements for the database server based on the examination of the workload. We argue that a database server must be able to dynamically reallocate its resources in order to meet the QoS requirements of different transactions as the workload changes. We describe Quartermaster, which is a system to support dynamic goal-oriented resource management in database management systems, and discuss how it can be used to help meet the QoS requirements of the electronic commerce database server. We provide an example of the use of Quartermaster that illustrates how the dynamic reallocation of memory resources can improve the performance of the database server under an example electronic commerce workload. We briefly describe the memory reallocation algorithms used by Quartermaster and present experiments to show the impact of the algorithms on the performance of the database server. * This research is supported by IBM Canada Ltd., NSERC (National Science and Engineering Research Council) and CITO (Communications and Information Technology Ontario). Martin, Powley, Li and Romanufa 1

2 1. Introduction Electronic commerce systems promise to radically transform the ways we do business [11]. They provide services to support three types of applications [8]: business-to-consumer applications, such as marketing and purchasing; business-to-business applications, such as information distribution, purchasing and selling; intra-company applications, such as communications, collaboration and decision support. The performance of electronic commerce systems will have a major impact on their acceptability to users. Users will not only expect reasonable performance at all times, but different users will expect different levels of performance, based on their needs and the amount they are willing to pay for a service. We refer to a users expected level of performance as the user s Quality of Service, or QoS, requirements. The issue of QoS originated in the areas of computer networks and multimedia systems [14]. It is a way to provide different levels of service to different applications on the same network. An application supplies a specification of its QoS demands to a system that then allocates sufficient resources to the application to meet the demands. If sufficient resources are not available then the demands can be renegotiated. Electronic commerce systems, as discussed below, are complex systems and are typically the integration of several servers, such as a web server, an electronic commerce server and a database server. Each server contributes to the performance of the system and each must be able to respond to the QoS demands of the users. In this paper we focus on the role, and the performance, of the database management system, or database server, within an electronic commerce system. We argue that more flexible and dynamic techniques than are currently available are required to properly manage the allocation of the database server s resources in an electronic commerce system. In order to manage the performance of any database server, we must first consider the characteristics of the workload presented to that database server. As mentioned above, an electronic commerce system supports three types of applications and each will have a different kind of workload. We base our discussion of the workload provided by the business-to-consumer applications on TPC-W, the proposed benchmark from the Transaction Processing Performance Council [18]. From the workload characteristics, we extract a range of likely QoS requirements for the database server. The remainder of the paper is structured as follows. Section 2 describes a framework for electronic commerce systems and explains the role of the database server within the framework. Section 3 considers the workload for an electronic commerce system and proposes a range of likely QoS requirements for the database server. Section 4 discusses the Quartermaster system for dynamic resource management. Section 5 describes an example use of Quartermaster to dynamically reallocate memory resources. Section 6 discusses related work. Section 7 summarizes the paper and identifies important research questions. Martin, Powley, Li and Romanufa 2

3 2. Electronic Commerce Framework The electronic commerce framework considered in this paper, which is shown in Figure 1, is typical of a number of electronic commerce system structures, including Net.Commerce [2] and Eco System [17]. The system is composed of three types of servers: a Web Server, an Electronic Commerce Server and a Database Server. There may be multiple instances of each type of server depending upon scalability issues and the existence of legacy database systems or different types of media data. The Web Server is the communication engine of the system. It supports client access to the system via the Web. Clients browse information and formulate requests via HTML pages. The Electronic Commerce Server contains the application logic for the system. It supports functions such as catalog browsing and searching, purchasing, secure payment, advertising and communication and interacts with both the Web Server and the Database Server. The Database Server manages the data for the system, which includes product catalogs, customer profiles and order information. In addition to the transaction workload provided by the Electronic Commerce Server, the Database Server must service transactions from other sources, for example queries and updates from local applications. We define a web interaction to be the unit of work in the electronic commerce system [18]. Users perform a series of web interactions when they use the system. We assume that each web interaction is an instance of a defined interaction class and that instances of Web Clients Web Server Electronic Commerce Server Database Server Local Transactions Figure 1: Electronic Commerce Framework Martin, Powley, Li and Romanufa 3

4 a class all have similar QoS requirements. A web interaction generates one or more transactions for the database server. The database transactions are also instances of a transaction class and all instances of a class have similar QoS demands on the database server. The QoS demands for the database server are derived from the QoS demands of the enclosing interaction. The mapping of QoS demands from the web interaction level to the database transaction level is not considered in this paper. We assume that the database transaction level demands are given and consider the problem of meeting the demands. 3. Database Server QoS Requirements In this paper, we assume that QoS requirements are specified for a class of database transactions and not an individual transaction. If a user requires a higher level of service for a specific execution of a transaction then this can be handled by assigning a higher priority to that execution. We also focus on the database transactions that access table and image data and do not access audio and video data. These types of transaction classes will have QoS requirements such as an average, or minimum, throughput rate and an average, or maximum, response time. In order to predict QoS requirements for the database server within an electronic commerce system it is necessary to first characterize the workload placed on it. The workloads generated by each of the three types of applications will have different properties and requirements Business-to-Consumer Applications Business-to-consumer applications, which form the most visible component of an electronic commerce system s workload, are a new class of application. The workload generated by this class of applications has not yet been studied and characterized. We base our analysis of the workload in the new Web Commerce benchmark, called TPC-W, from the Transaction Processing Performance Council (TPC) [18]. The TPC-W application models an online book retailer. Its database consists of eight tables: The Customer table contains information about customers. The Address table contains customer addresses. The Country table contains currency and exchange information about the customers countries. The Orders table contains information about the orders placed by customers. The Order_Line table contains information about particular item purchases within an order. The CC_Xacts table contains credit card information for each order. The Item table contains information about the books available through the storefront. The Author table describes the authors of the books Martin, Powley, Li and Romanufa 4

5 TPC-W is made up of a set of basic operations that are designed to exercise transactional web system functionality in a manner representative of electronic commerce systems. The benchmark simulates a retail store on the Internet. Customers visit the store s web site, or storefront, to look at products, find information, place an order or request the status of an existing order. The majority of customer activity involves browsing the site. Some percentage of all visits result in submitting a new order. In addition to operations to provide the storefront, the workload also includes a number of administrative operations to perform functions such as changing the price of an item and adding or deleting products. A number of the queries generated by the web interactions involve the retrieval of images. There are two types of images stored in the database: thumbnail images, which are 5K bytes in size, and full images, which are 25K bytes or 50K bytes in size. Each operation is modeled by a web interaction. Users perform a web interaction through HTML pages. A customer starts an interaction by following a link or pressing a button on the page, provides data for the interaction by filling in forms and receives results of requests via another page. The TPC-W workload is comprised of the following web interactions: A Home web interaction is the first interaction in a user session. The user initiates the interaction by going to the application s home page. The interaction issues transactions to the database server to retrieve item information for best seller and new book lists and thumbnail mages for several items. It also accepts a customer ID from the user and issues transactions to retrieve information about that customer. The home page provides links to most other web pages. A Shopping Cart web interaction is used to add or remove items from a customer s current set of potential purchases. The first Shopping Cart interaction of a session creates a cart to hold the purchases. When the Shopping Cart page is displayed the interaction issues queries to retrieve thumbnail images of several items. When the customer adds an item to the cart the interaction issues transactions to the database server to retrieve information about the item. A Customer Registration web interaction returns a form for the user to register as an existing customer or as a new customer. It generates transactions to the database server to either retrieve the information for an existing customer or to insert a new customer. A Buy Request web interaction returns information about the customer and items in the shopping cart. It also provides editable fields for credit card information and shipping instructions. It generates transactions to the database server to retrieve customer information. A Buy Confirm web interaction is initiated from the Buy Request page. It performs a payment authorization and then generates transactions to the database server to create new order information in the Order, Order_Line and CC_Xacts tables. An Order Inquiry web interaction allows customers to identify themselves as the first step in displaying information about a customer s last order. It generates transactions to the database server to verify the information provided by the customer. Martin, Powley, Li and Romanufa 5

6 An Order Display web interaction follows successful customer verification by the Order Inquiry web interaction. It issues transactions to the database server to retrieve information about the customer s last order and then displays that information. A Search Request web interaction first provides a web page that allows the customer to specify search criteria to find qualifying items. The interaction issues queries to retrieve thumbnail images of several items for display on the page. It then issues transactions to the database server to retrieve items that match the criteria supplied by the customer and then displays the items. A New Products web interaction is initiated by following a link in the list of new products on the home page. It issues transactions to the database server to retrieve information and thumbnail images about the designated new items. A Best Sellers web interaction is initiated by following a link in the list of best sellers on the home page. It issues transactions to the database server to retrieve information and thumbnail images about designated items. A Product Detail web interaction is initiated by following a link in the list of items on the new products or best sellers pages. It issues transactions to the database server to retrieve complete information and a full image of the item. An Admin Request web interaction allows an administrator to request an update of an item. It generates transactions to the database server to update the items and then responds with a confirmation page displaying the updated information a thumbnail image and a full image of the item. As we mentioned earlier, the majority of customers will just browse the site and only a percentage of these will actually purchase anything. Thus the majority of the workload is made up of read-only transactions. The queries generated by the New Products, Best Sellers and Product Detail web interactions are medium-weight queries that retrieve from a single table based on a primary key. The queries from New Products and Best Sellers retrieve several thumbnail images. The queries from Product Detail retrieve full images. In a real application, the Product Detail interaction could also be supplemented with audio or video data to help sell the item. This would increase the resource demands by the queries associated with Product Detail. The Search Request web interaction can generate heavyweight queries that involve searches on multiple conditions across more than one table. There will be a small percentage of update transactions generated by the Customer Registration and Buy Confirm web interactions. All of the transactions will have strict response time requirements since customers will be waiting for the response. A web-based workload also means that there will be periods where large numbers of clients are connected. This will result in periods of very high volumes of transactions against the server Business-to-Business Applications The business-to-business applications, which involve more familiar functions such as ordering, billing and inventory management, generate an online transaction processing (OLTP) type of workload on the database server. This type of workload consists mainly of light and medium weight read-write transactions with a relatively small number of Martin, Powley, Li and Romanufa 6

7 heavyweight read-only transactions. We expect that the volume of business-to-business transactions would be much less than the volume of business-to-consumer transactions because of the potentially large number of consumer clients. The response time requirements will also be less strict for business-to-business transactions than consumerto-business transactions since the performance of consumer-to-business transactions can have a direct impact on the sale of a product Intra-Business Applications We expect that the intra-business applications will not place a large load on the database server unless they include decision support applications, which involve heavyweight read-only transactions. These decision support transactions would typically access a large percentage of the data in the database and involve a significant amount of processing to perform sorts and aggregations of the data. The response time requirements for the queries would have to be best-effort so as not to interfere too much with the consumer-tobusiness workload Summary of Requirements We can therefore identify the following set of performance requirements for the database server in order to meet the range of QoS demands from the anticipated workload generated by electronic commerce systems: The database server must support a variety of transaction classes with different performance goals and resource requirements. The database server must be able to process transactions that require the presentation of multimedia data from the database. The database server must be able to efficiently process a workload whose characteristics and demands may vary significantly over time. More particularly, transaction volumes will vary widely due to the unpredictability of the Web client interface. 4. Managing Database Server Performance The database server must attempt to meet the QoS demands of electronic commerce systems by managing its performance. The performance of a database server is managed by controlling its resource allocations. The ways in which the resource allocations are controlled will depend on the type of QoS demands. For example, average response time or average throughput demands can be met by controlling the distribution of resources among the active transaction classes. On the other hand, maximum response time or minimum throughput demands require that competition for resources is controlled. This limiting of competition is implemented with admission control policies or priorities in addition to resource distribution. The techniques currently available to control resource allocations are very limited in current DBMSs. Allocations are controlled by configuration parameters. Some parameters can be altered on the fly; other parameters require that one stop the system, reset the values and then restart the system. Users may assign priorities to individual Martin, Powley, Li and Romanufa 7

8 transactions, which can affect the execution of that transaction, but they have no method of controlling the amount of resources allocated to a transaction. We claim that more flexible and dynamic methods are required to manage the resource allocations within the database server in order to meet the range of QoS demands described in the previous section. First, the variety of transaction classes with different demands means that it is not sufficient to tune the system to meet global criteria like average system response time or throughput. Second, the large variation in the types and frequencies of transactions implies that static tuning for one kind of workload is inadequate. We are developing a dynamic resource management facility based on the concept of goal-oriented resource management [15], which attempts to move some of the responsibility for resource management onto the database server. Performance goals, or QoS demands, such as average response times, are provided for each transaction class and the system itself determines how best to meet these goals. Examples of previous work in goal-oriented resource management are in the areas of distributed systems [15] and DBMSs [3][4]. UI Performance Goals Planner Controller Analyzer Monitor DBMS Resources Descriptions Rules Goals Performance Data Event Log Figure 2: Quartermaster Architecture Martin, Powley, Li and Romanufa 8

9 The structure of our goal-oriented resource management facility, which we call the Quartermaster, is shown in Figure 2. The Monitor collects performance data about the transaction classes and various database server resources and stores that data in the management repository. The Analyzer periodically examines the performance data, looking for transaction classes that are not meeting their performance goals. If a transaction class is not meeting its goal, then the Analyzer raises a violation and passes information about the violation to the Planner. The Planner uses the information about the violation and data in the management repository, including the performance data, descriptions of the transaction classes and tuning rules supplied by the DBA, to propose one or more tuning strategies to solve the problem. A tuning strategy describes the reallocation of resources in the database server. The system records the steps of the decision making process in an Event Log which can then be used to help explain the decision. The Planner presents the tuning strategies to the DBA via the UI. The DBA chooses one of the strategies and it is given to the Controller to implement on the database server. 5. Memory Reallocation Example The buffer area of DB2/UDB Version 5 [9], as shown in Figure 3, is partitioned into a number of independent buffer pools. Database objects (tables and indices) are assigned to specific buffer pools when the system is configured. For example, in Figure 3, indexes are assigned to the first buffer pool, the "warehouse" table is assigned to the second buffer pool, the "customer" and "item" tables are assigned to the third buffer pool and the "stock" table is assigned to the fourth buffer pool. An object's pages are moved between disk and it's designated buffer pool. The size of each buffer pool is set by configuration parameters and page replacement is local to each buffer pool. DB2/UDB enhances the performance of the buffer pool by performing asynchronous I/O, which is system-initiated data transfer between disk and the buffer pools. I/O servers can be created to perform prefetching where appropriate. I/O cleaners can be created to asynchronously write updated, or dirty, buffer pages back to disk [9]. A prototype of the Quartermaster system has been implemented for DB2/UDB. The prototype dynamically reallocates memory among multiple buffer pools based on average response time goals for a set of transaction classes. The Monitor uses the DB2/UDB monitoring API to collect information such as the number of logical and physical reads for each buffer pool. It also collects response time data from the application. The Analyzer calculates the Achievement Index for each transaction class T i, which is given by GoalAverage Re sponsetime AI = ActualAverage Re sponsetime If AI i < 1 then class T i is not achieving its goal. The Analyzer raises a violation for each class that is not achieving its goal. When the Planner detects the violation, it runs a buffer-tuning algorithm that determines a reallocation of buffer pool pages in favour of the transaction class with the smallest AI. We call this class the target transaction class for the tuning session. Martin, Powley, Li and Romanufa 9

10 Buffer Pools IO Servers index warehouse customer item stock IO Cleaners Figure 3: DB2/UDB Buffer Area 5.1. Dynamic Reconfiguration Algorithm Our buffer pool tuning algorithm, which we call the Dynamic Reconfiguration algorithm (DRF), is an iterative algorithm. It uses greedy heuristics to find a reallocation that benefits the target transaction class in each iteration. A summary of the notation used below to describe the algorithm is given in Table 1. A more detailed discussion and analysis of DRF is provided elsewhere [13]. An iteration of DRF reallocates a number of pages, which we will call δ, from one buffer pool to another. The source and target buffer pools of a reallocation are chosen such that the benefit to the target transaction class is maximized. The benefit of a reallocation to a transaction class is the estimated effect that a shift of pages from the source buffer pool to the target buffer pool has on the average response time of that class. Adding pages to a buffer pool can increase the hit rate of the buffer pool, which is the proportion of times that block requests are satisfied by pages in the buffer pool. The increased hit rate in turn reduces the response time of transactions using that buffer pool since there are, on average, fewer accesses to the disk. Martin, Powley, Li and Romanufa 10

11 Symbol Meaning T i Transaction class i. M j Size, in pages, of buffer pool j. δ Reallocation unit, in pages. H j Hit rate for buffer pool j. p(m j ) d O L i (O) Proportion of dirty pages that are cleaned by the IO cleaners, as a function of size of buffer pool j. Proportion of dirty pages in a buffer pool (constant for a workload) Database object. Number of logical reads of database object O by transaction class T i. r j Cost of a logical read of buffer pool j. C i Average response time of transaction class T i. Table 1 : Symbols used in cost equations The set of possible target buffer pools for a execution of DRF is the set of buffer pools used by the target transaction class T t. The set of source buffer pools is the set of all buffer pools minus the target buffer pool. An iteration of DRF considers each pair of target and source buffer pools and estimates the impact of reallocating δ pages on the average response time of transactions in class T t. For each possible source-target buffer pool pair (S, T), we first use Belady's equation [1] to estimate the hit rates for the adjusted source and target buffer pools, that is S of size M S -δ and T of size M T +δ. Belady s equation states that for buffer pool B with size M, the hit rate H can be approximated by b H ( M ) = 1 a M where a and b are constants. If two hit rates, H(M 1 ) and H(M 2 ) are collected for the two buffer pool sizes M 1 and M 2 for B, then a and b can be calculated using the following equations b = ln(1 H ( M 2)) ln(1 H ( M1)) ln M ln M H ( M1) a = b ln( M 1 ) e We assume that the average response time for a transaction class T is directly proportional to the average data access time for instances of T. The data access time for a Martin, Powley, Li and Romanufa 11

12 transaction depends upon the number of logical reads issued by that transaction. Each logical read incurs a processing cost. The percentage of logical reads that result in a disk access, or physical read, depends upon the hit rate of the buffer pool. The hit rate is in turn affected by the presence of IO servers, which perform asynchronous reads, that is they prefetch pages into the buffer pool. A physical read may also involve writing a dirty buffer page back to disk (called a physical write) if there are no free buffer pages available to receive the new page. IO cleaners increase the probability that a free page is found by asynchronously writing dirty pages back to disk (called asynchronous writes). We make several assumptions in constructing the response time estimator used here. First, we assume that the processing costs associated with a logical read are insignificant compared to the cost of disk IO and can be ignored. Second, we assume that prefetching is not used and ignore the effect of asynchronous reads. Finally, since we only require that the estimator be directly proportional to the actual response time, and not a close approximation to it, we assume that the cost of a physical read or write is 1. The cost for a logical read from buffer pool B i is therefore approximated by ( ) ( ( ) ) ri = 1 Hi 1+ 1 p( Mi) d where H i is the hit rate for buffer pool B i, d is the proportion of dirty pages in a buffer pool, M i is the size (in pages) of B i, and p(m i ) is proportion of dirty pages that are cleaned by the IO cleaners. The component of the access time given by (1 - p(m i )) d represents the probability that a write of a dirty page is necessary before a read can occur. We ran a set of experiments to help understand the effect of the IO cleaners on performance [13]. We found that, for a given number of IO cleaners, the proportion of dirty pages that are cleaned by the IO cleaners can be approximated by a linear function of M i, the size of the buffer pool. We determine this function for a configuration by taking values for the number of asynchronous writes at two different buffer pool sizes and then constructing the line through them. In estimating the average number of logical reads by an instance of T t on each of the buffer pools we first note that transactions of the class will access a set of database objects (tables, indices and temporaries), say O t = {O 1, O 2, O m }. We define the average number of logical reads of O i O t by instances of T t to be L t (O i ). We then note that database objects are buffered in specific buffer pools. We identify the set of buffer pools used by instances of the transaction class T t as B t = {B 1, B 2, B b }. We use the notation O i B j to indicate that database object O i is buffered in buffer pool B j. So an estimate of the average response time for transaction class T i is given by C i = b j= 1 O Bj L ( O) r which says that for each buffer pool B j (1 j b) used by instances of T i, we sum the cost of the logical reads for each database object O buffered in B j. For the experiments presented here, we obtained an estimate of the number of logical reads by a transaction T i of a database object O (L T (O)) from the explain facility of DB2/UDB [10]. i j Martin, Powley, Li and Romanufa 12

13 5.2. Experiments We now present two experiments using DRF that demonstrate how goal-oriented resource management can be used to ensure that a database server meets its QoS requirements under a dynamic workload, which is typical of electronic commerce systems. The first experiment shows how DRF can be used to react to a change in the QoS requirements of the workload. We consider the situation where one of the transaction classes presents the system with a new, and lower, average response time requirement. The second experiment shows how DRF can be used to react to changes in the contents of the workload. We consider the case where the transaction frequencies change but the goals remain the same. The experiments were run using DB2/UDB Version 5.2 under Windows NT on an IBMPowerServer 704. The machine was configured with one 200 MHz Pentium Pro processor, 1 GB of RAM and GB SCSI disks. DB2/UDB was configured with a disk page size of 4K bytes, 16 I/O cleaners and one I/O server. A total of K pages (400MB) of memory was allocated to three buffer pools which we identify as BP_DATA1, BP_DATA2 and BP_INDEX. The first two of these buffer pools handled data pages and the last one handled index pages. The workload used in the experiments is from the TPC-C benchmark [12]. The schema is composed of nine relations: Warehouse, District, Stock, Customer, Item, Order, New- Order, Order-Line and History. The experimental database consists of 3 warehouses. Each warehouse is composed of 10 districts and each district has 300 customers. Each warehouse is stocked 10,000 items. The workload consists of five transaction classes: Stock Level, Order Status, New Order, Payment and Delivery. The relative frequencies of instances of each class are specified in the benchmark. The database objects were assigned to buffer pools as follows: Warehouse, Item and District tables to BP_DATA1; all other tables to BP_DATA2; all indexes to BP_INDEX. In each experiment the TPC-C workload is run against the database for 20 minutes. We allow the application to run for 10 minutes in order to stabilize performance and then take the average of response times over the next 10 minutes All DB2/UDB performance measures are collected using the system's monitoring API [9]. TPC-C is representative of an OLTP workload. It consists mainly of medium-weight and lightweight read-write transactions. TPC-C is representative of the business-to-business workload discussed in Section 3. The transactions in TPC-C are also similar to transactions generated by several of the web interactions in the TPC-W benchmark; for example, Customer Registration, Buy Request, Buy Confirm, Order Inquiry, Order Display and Admin Request. The first experiment shows how DRF can be used to automatically adjust buffer pool resources in reaction to a change in the QoS requirements for a transaction class. In the initial state of operation, which we refer to as the "Before" state, all transactions have simple "best-effort" average response time goals. A "best-effort" goal means that a Martin, Powley, Li and Romanufa 13

14 Transaction Class Before state After state New Order Delivery Payment Order Status Stock Level Table 2: Experiment 1 - Average Response Times (secs) Average Response Time (sec) AI (BP_DATA1, BP_DATA2, BP_INDEX) Before state (33334, 33333, 33333) After state (10334, 53333, 36333) Table 3: Experiment 1 - Tuning Details for Delivery class specific goal is not given and any response times from the server are acceptable. The database server has a buffer pool allocation of 33334, and pages to BP_DATA1, BP_DATA2 and BP_INDEX, respectively. The response times achieved in the Before state are shown in Table 2. We change the QoS requirements for the Delivery transaction class so that it has an average response time requirement of 1.50 seconds. We see from Table 3 that, in the Before state, the Achievement index (AI) for the Delivery class is 0.60 for the new goal, which is a violation. Running DRF results in a new buffer pool allocation of 10334, and pages to BP_DATA1, BP_DATA2 and BP_INDEX, respectively. This allocation allows a reduction in the response time of the Delivery class to 1.41 seconds and gives a new AI of The new QoS requirements are therefore satisfied. The details of the "After" state, that is the state after buffer page reallocation, are shown in Tables 2 and 3. We observe that the new buffer pool allocation improves the average response times of 3 of the transaction classes and slightly degrades the response time of the other two. In this case we have specified QoS goals for one class only. The goals for the other transaction classes remain best effort so although some transactions benefit from the additional pages in BP_DATA2 and BP_INDEX, we are not concerned by the increase in the response time for Order Status and Stock Level. The second experiment demonstrates how DRF can be used to automatically adjust buffers to maintain QoS requirements when there is a change in the workload. In the initial state of operation, which is labeled the "Before" state in Table 4, the New Order and Delivery transaction classes are meeting their QoS goals, which are each set at 2.5 seconds. We assume that the other transaction classes have "best effort" goals. Table 4 shows the average response times and the percentage of the workload for each transaction Martin, Powley, Li and Romanufa 14

15 Transaction Class Response Time (sec) Before State Shift State After State % of Workload Response Time (sec) % of Workload Response Time (sec) % of Workload New Order Delivery Payment Order Line Stock Level Table 4: Experiment 2 - Response Times and Workload Mix class in the "Before" state. In both the "Before" state and the "Shift" state the database server has a buffer pool configuration of 5000, 5000 and pages to BP_DATA1, BP_DATA2 and BP_INDEX, respectively. We then shift the contents of the workload so that the percentage of the New Order class transactions increases from 45% to 90% while percentages of the other transactions decrease. The effect of this shift in the workload is shown under the "Shift" state in Table 4. The average response times for New Order and Delivery increase to 2.87 seconds and 3.35 seconds, respectively, so that both classes are no longer meeting their goals. Table 5 shows that the AI for both transaction classes in the "Shift" state is less than 1. We run DRF for the new workload and the old goals and receive a new buffer pool allocation of 500, and pages to BP_DATA1, BP_DATA2 and BP_INDEX, respectively. The results of running the new workload with the new configuration are shown in the "After" state in Tables 4 and 5. Both the New Order and Delivery transaction classes meet their original average response time requirements. State Shift After Transaction Class Average Response Time (sec) AI New Order Delivery New Order Delivery (BP_DATA1, BP_DATA2, BP_INDEX) (5000, 5000, 90000) (500, 23000, 76500) Table 5: Experiment 2 - Tuning Details The two experiments show that dynamic resource management, as provided by Quartermaster and DRF, can be used to manage database server performance. The server can, in turn, meet the QoS requirements presented to it by an electronic commerce server. Martin, Powley, Li and Romanufa 15

16 The experiments demonstrate the effectiveness of DRF to manage performance by reallocating buffer pages in the face of shifting demands and shifting workloads. 6. Related Work The tasks of configuring and tuning a DBMS, which are currently primarily manual exercises, are necessary to ensure that the DBMS can meet changing QoS requirements. The problem of dynamic reconfiguration, or automatic administration, is starting to receive more attention because of new important applications like electronic commerce. DBMS vendors, like Microsoft [6] and IBM [16], are addressing the physical design aspects of the problem. The case for goal-oriented resource management has been argued for distributed computing systems in general [15] and database management systems in particular [3][4][5][7]. While a large amount of research exists on the allocation of memory and processors in a DBMS, the vast majority of the work is directed towards optimizing some system-wide objective. A system-wide objective will not, in general, satisfy a set of classspecific goals. It is also true that most of this work focuses on the algorithms for resource allocation and does not deal explicitly with goal-oriented resource management. The work on goal-oriented resource management in DBMSs has focused on memory management [4][5][7][20]. Brown et. al. studied the problem of managing memory resources and multiprogramming level [3] and the COMFORT project on automatic tuning [19][20] has similar goals to our project. 7. Summary In this paper we have examined the role of a database server in an electronic commerce system and discussed how it can meet its anticipated performance requirements. We arrived at a set of performance requirements for the database server by first studying the characteristics of the workload presented to an electronic commerce system. The workload is generated by three types of applications: business-to-consumer, business-to-business and intra-business applications. It consists of a mixture of typical OLTP type transactions, decision-support type queries and browsing queries. The OLTP transactions are high frequency, medium-weight read-write transactions. The decisionsupport type queries are low-frequency heavyweight read-only transactions. The browsing queries are high-frequency medium-weight read-only transactions with occasional heavyweight read-only transactions. We also observed that transactions may involve multimedia data and may have QoS requirements that must be satisfied. Based on our examination of the workload, we proposed a set of performance requirements for a database server in order to meet the anticipated range of QoS demands from an electronic commerce system. The performance requirements are the following: The database server must support a variety of transaction classes with different performance goals and resource requirements. The database server must be able to process transactions that require the presentation of multimedia data from the database. Martin, Powley, Li and Romanufa 16

17 The database server must be able to efficiently process a workload whose characteristics and demands may vary significantly over time. More particularly, transaction volumes will vary widely due to the unpredictability of the Web client interface. Database server performance is controlled by how the server's resources are allocated to active transactions. We argued that the facilities available to manage local resources in current DBMSs, which only allow relatively static resource allocations across all transactions, are not adequate to meet the performance requirements of an electronic commerce system. We argued for a more dynamic resource allocation mechanism that takes into account the varying performance goals of different transaction classes. We then described a goaloriented resource management system, called Quartermaster, for DB2/UDB, which will dynamically allocate the global resources to ensure that performance goals of the transaction classes are met. We described a specific example of dynamic resource management, namely managing the buffer pools in a database server, and demonstrated how it can be used to meet QoS requirements. We presented the Dynamic Reconfiguration algorithm for managing buffer pool allocations. We then discussed two experiments that use an implementation of DRF for DB2/UDB and the TPC-C database and workload. The experiments show how DRF can be used to either meet changing QoS requirements or maintain a constant level of QoS in the face of a changing workload. Thus a system like Quartermaster can help a database server to satisfy two of our performance requirements, namely to handle workloads with a variety of demands and that change over time. Electronic commerce systems offer many technical challenges to system developers. The challenge of providing adequate levels of performance for the various types of users of these systems is an important one since it is vital to their ultimate success. There is much work to be done in understanding and characterizing the workloads of electronic commerce systems, interpreting what impact these workloads have on the components of the system, and on the interactions between the components. References [1] L. Belady. A Study of Replacement Algorithms for a Virtual-Storage Computer, IBM Systems Journal 5(2), July 1966 [2] D. Bourne. Net.Commerce Performance Scalability, Technological Challenges of Electronic Commerce, edited by W. Kou and Y. Yesha, [3] K. Brown, M. Mehta, M. Carey and M. Livny. Towards Automated Performance Tuning For Complex Workloads, Proc. of 20th Int. Conf. on Very Large Databases, Santiago, Chile, [4] K. Brown, M. Carey and M. Livny. Goal-Oriented Buffer Management Revisited, Proc. of the 1996 ACM SIGMOD Int. Conf. on Management of Data, Montreal, June 1996, Martin, Powley, Li and Romanufa 17

18 [5] K. Brown, M. Carey and M. Livny. Managing Memory to Meet Multiclass Workload Response Time Goals, Proc. of 19 th Int. Conf. on Very Large Databases, Dublin, August 1993, pp [6] S. Chaudhuri, E. Christensen, G. Graefe, V. Narasayya and M. Zwilling. Self-Tuning Technology in Microsoft SQL Server, IEEE Data Engineering Bulletin 22(2), June 1999, pp [7] J.-Y. Chung, D. Ferguson, G. Wang, C. Nikolaou and J. Teng. Goal-oriented dynamic buffer pool management for data base systems, Proc. of Int. Conf. on Engineering of Complex Systems (ICECCS 95), November [8] CommerceNet. An Introduction to Electronic Commerce, [9] IBM. DB2 Universal Database Administration Guide Version 5, IBM Corp., [10] C. Janacek and D. Snow. DB2 Universal Database Certification Guide (2 nd Edition), Prentice-Hall Inc., [11] A. Kambil. Doing Business in the Wired World, IEEE Computer 30(5), May 1997, pp [12] S.T. Leutenegger and D. Dias. A Modeling Study of the TPC-C Benchmark, Proc. of the 1993 ACM SIGMOD International Conference on Management of Data, Washington D.C., 1993, pp [13] H. Li. Dynamically Reconfiguring Multiple Buffer Pools, M.Sc. thesis, Dept. of Computing and Information Science, Queen's University, [14] K. Nahrstedt. End-to-End QoS Guarantees in Networked Multimedia Systems, ACM Computing Surveys 27(4), December 1995, pp [15] C. Nikolaou, D. Ferguson, P. Constantopoulos. Towards Goal-Oriented Resource Management, IBM Research Report RC17919, April [16] B. Schiefer and G. Valentin. DB2 Universal Database Performance Tuning, IEEE Data Engineering Bulletin 22(2), June 1999, pp [17] J. Tenenbaum, T. Chowdhry and K. Hughes. Eco System: An Internet Commerce Architecture, IEEE Computer 30(5), May 1997, pp [18] Transaction Processing Performance Council, TPC Benchmark W (Web Commerce), Draft Specification D-5.1, August 18, 1999, [19] G. Weikum, C. Hasse, A. Moenkeberg and P. Zabback. The COMFORT Automatic Tuning Project, Information Systems 19(5), [20] G. Weikum, A. Christian, A. Kraiss and M. Sinnwell. Towards Self-Tuning Memory Management for Data Servers, IEEE Data Engineering Bulletin 22(2), June 1999, pp Martin, Powley, Li and Romanufa 18