Memory Characterization of the Ecperf Benchmark
Total Page：16
File Type：pdf, Size：1020Kb
Memory Characterization of the ECperf Benchmark Martin Karlsson, Kevin E. Moore, Erik Hagersten, and David A.Wood Uppsala University University of Wisconsin Information Technology Department of Computer Sciences Department of Computer Systems 1210 W. Dayton St. P.O. Box 325, SE-751 05 Uppsala, Sweden Madison, WI 53706 Email: {martink, eh}@it.uu.se Email: {kmoore, david}@cs.wisc.edu Abstract the large market for application servers is evidence that they are an important workload for today’s servers. The quest for quantitative performance analysis in com- Several previous papers have characterized the perfor- puter architecture research and design led to many mance of other commercial workloads, most notably research papers based on the commercially important database systems, running the TPC benchmarks [1][2]. DSS and OLTP database applications. Today’s middle- Application servers, however, behave quite differently ware, and in particular application servers, are rapidly from database engines; they have much smaller data sets gaining popularity as a new workload for commercial than databases and generate much less disk traffic. multiprocessor servers. Therefore, it is important to Also, many commercial application servers are imple- expand architecture studies into this area. SPEC has mented in Java. Like other Java workloads, they are recognized the importance of application servers and influenced by the performance characteristics of the Java-Based middleware with its recent adoption of Java Virtual Machine (JVM) on which they run, includ- SPECjAppServer2001, formerly ECperf, as one of its ing automatic garbage collection and Just-In-Time benchmarks. In this paper, we present a detailed char- compilation. Unlike known Java benchmarks, applica- acterization of the memory system behavior of ECperf tion servers are optimized commercial applications. running on both commercial server hardware and in a simulated environment. We find that the working sets of We present a detailed characterization of the ECperf ECperf fit in a reasonably sized L2 cache, but that the benchmark run on a leading commercial application miss rate is very sensitive to associativity. Furthermore, server. ECperf is an appropriate benchmark for study- many of the L2 misses in ECperf are satisfied by data ing application server performance, because it models a from the cache of a neighboring processor. Based on 3-tiered system, and emphasizes the middle tier. Fur- these findings, we conclude that ECperf is an excellent thermore, in ECperf, each tier is run on a separate candidate for shared-cache memory systems, even when machine, making it easy to monitor the memory behav- the total cache size is limited. ior of the application server separately. SPEC recently acknowledged ECperf by incorporating it into its suite 1 Introduction of benchmarks as SPECjAppServer2001. We used a leading commercial application server to run ECperf on The rapid growth of internet-delivered services has two realistic hardware configurations. We measured the brought with it a new type of server workload, the appli- effect of scaling ECperf on the memory systems of two cation server. According to leading market research multiprocessor servers. We compliment our scaling companies Gigaweb Corporation and International Data results with cache miss rates from a full system simula- Corporation, the application server market grew 39% to tion of a shared-memory multiprocessor running 2.2 billion dollars in 2001 following several years of ECperf. Finally, based on our findings, we discuss the +100% growth. Although smaller than the market for architectural implications of this workload. databases (approximately 8.8 billion dollars in 2000), 2 Background This work is supported in part by the National Science Foun- dation, with grants EIA-9971256, CDA-9623632, and CCR- At the center of modern web-services applications is the 0105721, the PAMP research program supported by the Swed- ability to connect web pages to databases. For data- ish Foundation for Strategic Research, a Wisconsin Romnes Fellowships (Wood), and donations from Compaq Computer Corporation, Intel Corporation, IBM, and Sun Microsystems. 1 persistent storage mechanism. This tier is typically comprised of a single, or group of Database Manage- 3-Tiered Systems ment Systems (DBMS). Tier 1 Tier 2 Tier 3 Recently, web services have been deployed in an “N- Tier” architecture in which the presentation logic is sep- Web Server arated from the business rules. The presentation logic can be implemented by stateless servers and is some- Business times considered to be a first-tier application. N-Tiered Logic Browsers/ architectures allow the application server to focus Thin Clients Middleware entirely on the business logic. Internet Databases firewall LAN/WAN 2.1 ECperf Overview ECperf is a middle-tier benchmark designed to test the Figure 1 3-Tiered Systems performance and scalability of application servers and the computer systems that run them. It incorporates e- bases, connection to the web allows users to access data commerce, business-to-business, and supply chain man- without installing a client program; for web pages, data- agement transactions. The presentation layer is imple- bases provide dynamic content and permanent storage. mented with Java Servlets and the business rules are The software that implements the database-to-web con- built with Enterprise Java Beans. nection is known as “middleware.” Middleware can be stateless like a PERL script or Java Servlet, or a set of In order to make the benchmark realistic, the authors of component classes embedded in an application server ECperf modeled an on-line business using a “Just-In- that stores the session information for its clients locally. Time” manufacturing process (products are made only Component-based middleware hosted by application after orders are placed and supplies are ordered only servers reduce the burden on the database by not requir- when needed). The application is divided into four ing additional database transactions to manage session domains, which manage separate data and employ dif- information, and allow more complicated session data ferent business rules [11]. than is practical to pass with every web request. Appli- Customer Domain cation servers provide communication with both back- The Customer Domain models orders and customer end databases and front-end web clients in addition to interaction. Customers can create new orders, providing a framework to connect application specific make changes to existing orders, and inquire about “business rules,” that govern the interaction between the the completion status of their orders. The customer two. interactions are similar to On-Line Transaction Pro- cessing (OLTP) transactions. Today’s web-services applications are deployed on het- Manufacturing Domain erogeneous systems arranged in distinct tiers, each of The Manufacturing Domain implements the “Just- which has its own performance and state persistence In-Time” manufacturing process. As orders are requirements. Database systems have traditionally been filled, the status of customer orders and the supply built in a two-tiered, or Client/Server, architecture. That of each part used to fill the order are updated. two-tiered approach is not well suited to the web because web browsers communicate in HTML and data- Supplier Domain base servers communicate in SQL. Rather than add an The Supplier Domain models interactions with HTML translator to an already complicated database external suppliers. A supplier is chosen for each server, systems designers have added an additional tier purchase based on the number and type of the parts between the client and server (see Figure 1). This mid- being ordered and the required delivery date. The dle tier is responsible for implementing presentation parts inventory is updated as purchase orders are logic and business rules, both of which are specific to filled. the given application. Such systems are called “3-Tier.” Corporate Domain The first tier, or Tier 1, is the client, usually a web The Corporate Domain tracks customer, supplier browser. The second tier or, Tier 2, is an application and parts information. Most importantly, the Cor- server that hosts application-specific middleware. The porate Domain stores and updates credit informa- third tier, or Tier 3, is the data store, a highly reliable tion for each customer. 2 System Under Test Driver Application Server Order Agents Servlet Host EJB Container Database Mfg Agents Orders & Java Corp Corp DB Mfg Beans Orders Supplier Servlets Orders DB Emulator Mfg Mfg DB Supplier DTDs Servlets Supplier Supplier DB Emulator Presentation Logic Business Rules FigureServlet 2 ECperf Setup Figure 2 ECperf Setup The ECperf specification supplies the Enterprise Java and the connection between them. The driver and Sup- Beans that form the core of the application. These com- plier Emulators, which model the behavior of customers ponents implement the application logic that controls and external suppliers respectively, are not part of the the interaction between orders, manufacturing and sup- SUT and are therefore not included in the benchmark pliers. In particular, that interaction includes submitting measurements or cost calculations. ECperf has recently various queries and transactions to the database, and been adopted by the Standard Performance Evaluation exchanging XML documents with the Supplier Emula- Corporation (SPEC) and will be released as tor. SPECjAppServer2001 [12].