Sizing and Capacity Analysis of Oracle E-Business Suite running on Dell Servers
EMEA Application Solution Centre (ASC)
Dell White Paper
By John Page
March 2004
Contents
Introduction 3
Executive Summary 5
Test Infrastructure 8
Load Generation Hardware 8
Application Layer 8
Database Servers 8
Shared Storage 8
Networking Equipment 9
Load Generation Software 9
Application Software 9
Database Software 9
Test Data 9
Hardware Layout 10
Workload Characteristics 11
Data Collection and Analysis 14
Results 16
Cycle 1: One PowerEdge 2650 running 11iApps and 9i Database. 17
Cycle 2: One PowerEdge 2650 in Apps Layer, One PowerEdge 2650 in DB Layer 18
Cycle 3: Two PowerEdge 2650s in Apps Layer, One PowerEdge 2650 in DB Layer 20
Cycle 4: 3xPE2650s in App Layer, 1xPE6650 (8G) in DB Layer 21
Cycle 5: 5xPE2650s in App Layer, 1xPE6650 (16G) in DB Layer 22
Cycle 6: 10 x PowerEdge 2650s in App Layer, 2 x PowerEdge 6650 (16G) in DB Layer 23
Cycle 7: 15xPE2650s in App Layer, 3xPE6650(16G) in DB Layer 24
Conclusions 27
Section 1
Introduction
Almost all businesses of any size depend to a greater or lesser extent on their IT infrastructure. One of the key demands placed by the business on this infrastructure is to scale easily as the business grows, so that it can handle increasing user and transaction volumes.
To support this requirement, Dell emphasizes the idea of “scaling out” an application. This means running an application on a number of relatively small servers, and adding extra servers in parallel as the business requirements grow. This is in contrast to a “scale-up” strategy, whereby customers move their applications to larger and faster machines to handle increasing levels of usage.
Of course, the software application must also be capable of using multiple machines in parallel, if the full benefits of a scale-out strategy are to be realized. One example of an application that can scale out easily is the Oracle E-Business Suite 11i with Oracle Applications. As more users are added, extra servers can be added as required.
The applications that comprise Oracle E-Business Suite 11i use the Oracle9i™ database for data storage. As well as scaling out the application layer, it must also be possible to scale out the database layer. Oracle9i Database is capable of scaling out through Oracle’s Real Application Clusters (RAC) technology. An Oracle RAC cluster can easily scale out if extra servers are added to the cluster. This means that extra users can be accommodated without having to move everything to larger and more powerful servers when the limits of the existing servers are reached.
To support this scale-out strategy based on Dell servers and Oracle software, Dell and Oracle undertook a joint project to find out how many users could be supported on different hardware configurations. The key requirement of this project, from Dell’s point of view, was to produce data that would demonstrate to customers the value of the scale-out strategy.
The project was hosted at Dell’s Application Solution Centre in Limerick, Ireland. Oracle E-Business Suite 11i Apps and Oracle9i RAC were installed on Dell™ PowerEdge™ 2650 and 6650 servers respectively, and a simulated user load was applied to Oracle11iApps. Each configuration was stressed to its maximum limit. The configuration was then “scaled out” with extra servers, stressed again to its maximum limit, and then scaled out again. This process continued for the duration of the project. See Section 5 for discussion of the workloads used in the tests.
The results achieved, which are discussed at length in this white paper, will be used by Dell to illustrate how a mission-critical enterprise application such as E-Business Suite 11i Apps can run on Dell servers and storage and support thousands of users, and to demonstrate the advantages of choosing a scale-out strategy over a scale-up strategy.
In all cases the PowerEdge servers used in these tests were running Red Hat® Linux® Advanced Server 2.1 as the OS.
Section 2
Executive Summary
The project was run in seven cycles, with a different configuration supporting a different number of users in each cycle. Each configuration consisted of three physical tiers or layers: an application layer; a database layer; and a shared storage layer. The application tier was made up of one or more PowerEdge 2650 servers for every cycle. The shared storage layer was hosted on a Dell™/EMC® CX600 in all cases. The database layer consisted of PowerEdge 2650 servers for the first three cycles, and PowerEdge 6650 servers for the last four cycles. Note that for the first cycle the database and application layers were hosted on one physical machine (a PowerEdge 2650). The results obtained are summarized below in Table 1.
Note also that “Users” in Table 1 refers to concurrent users. For example, where the table states that 160 users are supported in Cycle 1, this refers to 160 concurrent users who were logged on and processing transactions for the entire duration of the test.
Cycle No. / PowerEdge Server used in Database Layer / PowerEdge Server used in Mid-Tier Layer / DB memory / Max Users / 70% Max1 / 1 x 2650 / N/A / 6 GB / 160 / 112
2 / 1 x 2650 / 1 x 2650 / 6 GB / 280 / 200
3 / 1 x 2650 / 2 x 2650 / 6 GB / 560 / 400
4 / 1 x 6650 / 3 x 2650 / 8 GB / 840 / 600
5 / 1 x 6650 / 5 x 2650 / 16 GB / 1400 / 1000
6 / 2 x 6650 / 10 x 2650 / 16 GB / 2800 / 2000
7 / 3 x 6650 / 15 x 2650 / 16 GB / 3920 / 2750
Table 1: Overall Results of E-Business Suites 11i Apps Tests
In Table 1, the column “DB memory” refers to the amount of memory in the database server for a particular cycle. The application servers had 6GB of memory in all cases. Also, the “Max Users” column is the actual maximum number of users achieved in the cycle, whereas the “70% Max” column is a recommendation as to how many users a particular configuration might support in production, while still allowing some headroom for an increase in user numbers. The following discussion and graphs are in relation to the maximum user counts.
The key findings from this table are as follows:
· A single PowerEdge 2650 server running both E-Business Suite 11i and Oracle9i Database supported a maximum of 160 users during the test.
· A single PowerEdge 2650 server running E-Business Suite 11i Apps supported up to 280 users when the database was running on another machine.
· A single PowerEdge 2650 server running Oracle9i Database supported a total of two application servers with 280 users each, giving a maximum of 560 users for a configuration that uses a PowerEdge 2650 with 6GB of memory to run the database software.
· By switching the database to a PowerEdge 6650 server with 8GB memory rather than a PowerEdge 2650 server, the maximum number of supported users rose to 840 (i.e., three connected app servers with 280 users each).
· By increasing the memory in the PowerEdge 6650 server from 8GB to 16GB, a maximum of 1,400 users were supported (i.e., five connected app servers with 280 users each).
· By adding a second PowerEdge 6650 server into a RAC cluster along with the first PowerEdge 6650 server, the maximum number of supported users doubled to 2,800. This is a scalability factor of 1.
· By adding a third PowerEdge 6650 server to the RAC cluster, the maximum number of supported users increased to 3,920. This is a scalability factor of 0.80.
The results obtained in Table 1 emphatically support the scale-out strategy. The following two graphs illustrate this even more clearly. Figure 1 is a plot of user count versus the number of servers in the configuration.
Figure 1: User Count versus Number of Machines
Figure 1 clearly shows the maximum number of supported users increasing almost in a straight line as the number of servers was increased. This is exactly what we would expect from a system that is capable of scaling out.
Section 3
Test Infrastructure
The following are the key components of the test infrastructure:
Load Generation Hardware
Between one and seven PowerEdge 2650 servers were used during the test to simulate the user load. Each server had two 2.8GHz Pentium® Xeon™ processors, five hard disks configured as RAID 1 and RAID 5, and 6GB of memory. These servers supported approximately 600 users each. The operating system was Windows® 2000 Advanced Server.
Application Layer
Between one and fifteen PowerEdge 2650 servers, supporting 280 users each (except for cycle 1) were used to apply the load. Each server had two 2.8GHz Pentium Xeon processors, five hard disks configured as RAID 1 and RAID 5, and 6GB of memory. The operating system was Red Hat Linux Advanced Server 2.1, with kernel level 2.4.9e25.
Database Servers
Cycles 1 to 3 consisted of between one and two PowerEdge 2650 servers with the same specs as the Application Layer servers. On cycles 4 to 7, we used between one and three PowerEdge 6650 servers with four 2.0GHz Pentium Xeon MP processors and five hard drive disks configured as RAID 1 and RAID 5. The PowerEdge 6650 in cycle 4 used 8GB of memory, while 16GB of memory was used in the remaining cycles.
All of the servers that were running the database were installed with two QLA2340 Qlogic Host Bus Adapters (HBAs).
The operating system in all cases was Red Hat Linux Advanced Server 2.1, with kernel level 2.4.9e25.
Shared Storage
The shared storage was on a Dell/EMC CX600 with 2GB of cache per storage processor. The Oracle data was stored on a 70GB RAID 10 volume. The database servers were connected to the SAN through a pair of 16-port EMC fabric switches.
Networking Equipment
All servers (load generators, application layer servers, database layer servers) were networked together using a Dell PowerConnect 5224 switch. One of the two embedded Broadcom NICs was used to connect each server to the network. The database servers had a separate private interconnect for the cluster, which was through a separate Dell PowerConnect 5212 switch.
Load Generation Software
Mercury Interactive Loadrunner was used to simulate the required number of concurrent users for each cycle. The Loadrunner scripts were specifically created by Oracle for this project.
Application Software
Oracle11iApps Version 11.5.8
Database Software
Oracle9i Release 2 (9.2.0.3)
Test Data
A sample database of Oracle E-Business Suite 11i application data, called the Vision database, was pre-loaded onto the Oracle9i database in advance of the test. The user scripts depended on this data in order to run correctly.
Section 4
Hardware Layout
The hardware configuration is shown below in Figure 2.
Figure 2: Hardware Configuration for Oracle Tests
The shared storage layer was constant throughout the test. The load generation layer, application layer and database layer were all added to and scaled out with each succeeding test cycle.
Section 5
Workload Characteristics
The results obtained in this project were required by Oracle for engineering sizing purposes. To support this requirement, Oracle generated test scripts which simulated a very heavy and realistic user workload. In this way Oracle worked to ensure that the results could be applied with confidence to real-world situations.
The workload consisted of a set of scripts that simulated Oracle Applications users. These scripts were specifically developed for this project. They were intended to be as realistic as possible in terms of representing the activity of a typical Oracle Apps user.
The workload covered five core modules from the Financials and Supply Chain Management (SCM) product suites:
· Accounts Receivable (AR)
· Fixed Assets (FA)
· Inventory (INV)
· Order Entry (OE)
· Purchasing (PO)
The workload also included Pricing (QP) transactions that provided cross-functional testing of the Order Entry (OE) and Inventory (INV) modules.
The workload mix consisted of 22 business transactions. This was made up of 16 OLTP transactions and 6 transactions that submitted concurrent requests. These are described fully in Table 2.
The sample Vision database was populated with thousands of rows of seeded data, totaling about 50GB of data. This database was loaded from tape onto the Oracle9i Database.
The scripts represented the activity of 40 different users. Each user executed a transaction a particular number of times to produce an overall total number of transactions. This is also explained in Table 2. The columns of this table are as follows:
Base User Count: The number of Oracle Apps users running this transaction
Iterations Per User Per Hour: The number of times a single user executes this transaction
Business transaction Total: The Base User Count multiplied by Iterations per user.
Note that the user counts in Table 1 are always divisible by 40. In other words, as the load being applied to the system was increased, users were added to the test in groups of 40. Because each group of 40 users had the profile described in Table 2, the overall characteristic of the workload remained constant regardless of the number of users being applied. In other words, the same ratio of AR, FA, INV, OE, PO and QP transactions were being applied regardless of the total number of users.
Transaction / Base User Count / Iterations per user per hour / Transaction TotalAccounts Receivable (AR)
AR Enter Customer / 2 / 10 / 20
AR Enter invoice / 3 / 10 / 30
AR Enter Inv Credit memo / 1 / 11 / 11
AR Enter Invoice Adjustment / 1 / 9 / 9
AR Enter Receipt / 1 / 10 / 10
AR AR_To_GL Transfer Request / 1 / 4 / 4
AR Print invoice Submittal / 1 / 4 / 4
AR Print Statement Submittal / 1 / 4 / 4
AR Totals / 11 / 62 / 92
Fixed Assets (FA)
FA Assets Inquiry / 4 / 10 / 40
FA Totals / 4 / 10 / 40
Inventory (INV)
INV Create an item / 4 / 12 / 48
INV View an Item / 3 / 11 / 33
INV Totals / 7 / 23 / 81
Order Entry (OE)
OE Insert an Order / 3 / 14 / 42
OE View an Order / 2 / 13 / 26
OE Totals / 5 / 27 / 68
Purchase Orders (PO)
PO Create a Supplier / 1 / 10 / 10
PO Create a Purchase Order / 2 / 12 / 24
PO View a Purchase Order / 2 / 10 / 20
PO Create a Requisition / 2 / 9 / 18
PO View a Requisition / 2 / 9 / 18
PO Totals / 9 / 50 / 90
Pricing (QP)
QP Price List Setup / 1 / 11 / 11
QP Adjust Price List / 1 / 9 / 9
QP Add Items to Price List / 1 / 10 / 10
QP Copy a Price List / 1 / 10 / 10
QP Totals / 4 / 40 / 40
Atomic Group Total / 40 / 212 / 411
Table 2: Workload Details