ORACLE S PEOPLESOFT GENERAL LEDGER 9.2 (WITH COMBO EDITING) USING ORACLE DATABASE 11g FOR ORACLE SOLARIS (UNICODE) ON AN ORACLE S SPARC T7-2 Server

Transcription

1 O R A C L E E N T E R P R I S E B E N C H M A R K R EV. 1.0 ORACLE S PEOPLESOFT GENERAL LEDGER 9.2 (WITH COMBO EDITING) USING ORACLE DATABASE 11g FOR ORACLE SOLARIS (UNICODE) ON AN ORACLE S SPARC T7-2 Server As a global leader in e-business applications, Oracle is committed to delivering high performance solutions that meet our customers expectations. Business software must deliver rich functionality with robust performance. This performance must be maintained at volumes that are representative of customer environments. Oracle benchmarks demonstrate our software s performance characteristics for a range of processing volumes in a specific configuration. Customers and prospects can use this information to determine the software, hardware, and network configurations necessary to support their processing volumes. The primary objective of our benchmarking effort is to provide as many data points as possible to support this important decision. Benchmark SUMMARY OF RESULTS PeopleSoft General Ledger 9.2 (Combo. Editing) Extra-Large Volume Model Edit & Post 201,000,000 lines minutes Journal Lines/Minute 10,752,688 per minute BENCHMARK PROFILE In August 2015, Oracle (PeopleSoft) conducted a benchmark in Burlington, MA to measure the batch performance of Oracle s PeopleSoft Enterprise Financials (FMS) 9.2 General Ledger (GL) Journal Edit and Post (with combination editing). The database server used Oracle Database 11gR2 running on an Oracle s SPARC T7-2 server, (1 chip, 32 cores, 256 vcpus) with Oracle Solaris Moreover, four of Oracle s Flash Accelerator F160 storage devices were used for data storage and redo log storage (~1000 GB). 201,000,000 Lines - General Ledger Batch DB-Tier #1 248 CPUs 2 Zones Chip 0 App-Tier #1 8 CPUs Logical Domain LDom#1 (256 CPUs) (Process Scheduler) Inactive Chip 1 The benchmark measured runtimes for one standard database model representing an extra-large organization. Testing was conducted in a controlled environment with no other applications running. The tuning changes, if any, were approved by PeopleSoft Development and will be generally available in a future release or update. The goal of this Benchmark was to obtain baseline results for PeopleSoft FMS 9.2 GL Batch with Oracle Database for Solaris on an Oracle SPARC T7-2 Server. 4 Flash Accelerator F160 Storage Devices Figure 1: Virtualization Resource Apportionment

2 METHODOLOGY PeopleSoft General Ledger 9.2 batch processes can be initiated either from a browser or on the server. For this benchmark, all jobs were initiated from a PeopleSoft process scheduler. The Edit process was executed in parallel streams and the Post process was executed in parallel streams for this benchmark. That is, the process scheduler ran two processes for each of the 160 parallel streams. Each (Application Engine) Edit process issued a call to its associated (Application Engine) Post process as it finished. In this benchmark, no errors were generated during the Journal Edit process. Edit Post 80 Streams Small Business Units 160 Streams Large Business Units BUSINESS PROCESSES The two General Ledger processes measured in this benchmark are as follows: Journal Edit (GL_JEDIT): Validates journal entries to ensure that each individual ChartField value is valid, the combination of chartfields values are correct, and the totals of debit and credit amounts are balanced. If a journal is flagged with an error status, it won t be posted until proper correction had been applied and the journal re-edited. The Combination Editing process uses 7 ChartField combination rules to validate combination of up to five chartfields ( Account, Department, Product, Operating_unit, Project). For journals that contain Inter-Unit activities, Journal Edit will call IU_Processor to validate the Inter-Unit transactions. Journal Post (GL_JP): Summarizes detail line activity of journals with a valid status and post the aggregated result to the detail ledger. There is one ledger row for each unique combination of ChartField values per accounting period, and fiscal year. In this benchmark, the Post process do 41% of update of the existing ledger rows and 59% inserts of new ledger rows. This is typical for companies that perform the edit and post functions on a frequent basis. BATCH RESULTS The table below contains the actual runtimes, in minutes, for each process. It also shows how many journal lines were executed per minute and, by linear extrapolation, per hour. 80 Streams Inter-Unit Transactions 201,000,000 Lines With Combo Edit Edit/Post Journal min. Journal Lines /Min 10,752,688 Figure 2: Job Stream Allocation Batch processes are background processes, requiring no operator intervention or interactivity. Results of these processes are automatically logged in the database. The runtimes are posted to the Process Request database table where they are stored for subsequent analysis. Journal Lines /Hr 645,161,280 Table 2: Process Runtimes The testing was conducted in a controlled environment with no other applications running. Performance may vary on other hardware and software platforms and with other data composition models. COPYRIGHT 2015 Oracle, Inc. All rights reserved. Page - 2

3 Running CPU SERVER PERFORMANCE Figure 3 shows the running CPU utilization for the server in this test. The CPU utilization shows that the 160 parallel job streams (160 2 = 320 total) used about two-thirds of the available 256 vcpus. DATA COMPOSITION DESCRIPTION The table below describes the standard data composition model for the extra-large database size tested in this benchmark. 80% (160,000,000) of the transactions are in 20% of its business units. 100 Oracle's PeopleSoft Enterprise 9.2 General Ledger Edit and Post Batch Figure 3: Server CPU Utilization % CPU User System I/O Wait Idle Average Table 3: Summary of CPU Utilization Avg. Memory Used GL Edit & Post GB Table 4: Average Memory Utilization I/O PERFORMANCE Four Oracle Flash Accelerator F160 cards were used for storage of tables and indexes. I/O performance is crucial to performance and is summarized as follows: Number of Extra-Large Business Units 250 Volume of Existing Ledger Data (3 years) 3.5 billion Current Journal Lines (online and/or uploaded 12/2013): Journal Headers 20,100 Average lines per header 10,000 Journal Lines 201,000,000 Adjustment Journal Lines (11/2013 & 12/2013 Journal Headers 600 Average lines per header 50 Journal Lines 30,000 Historical Journal Headers 750,000 Historical Avg. lines per header 325 Historical Journal Lines (1 year) 243,750,000 BUs that have InterUnit Activity (20% of total BUs) InterUnit Activity as a % of Journal Trans/run 48 16% ChartFields Operating Unit 5,000 Account 10,000 Department 20,000 Product 25,000 Project 250,000 Affiliate 1,500 Budget Reference 700 Multi-Currency as a % of Journal Trans/run 50% Currency Distribution USD 40% CAD 15% EURO 20% GBP 15% AUD 10% Table 6: Data Composition Average Reads/sec 10,735 Reads/sec KB 105,733 Writes/sec 21,407 Writes/sec KB 816,214 Service Time ms 0.3 Table 5: I/O Metrics COPYRIGHT 2015 Oracle, Inc. All rights reserved. Page - 3

4 BUSINESS UNITS Most of the GL BU s will have USD as base currency, but some BU s will use CAD, GBP, EURO and AUD as base currency for multicurrency Journals.. Additionally, all transactions are in the base currency of the GL BUs (USD). Open periods for the business units will be open through the entire 3 year range ( ) in order to allow seeded transactions to be processed through the subsystems before expanding the data. Prior to the start of the performance test, the open periods will be limited to 12/2013 and 1/2014 with adjustment periods defined for GL. The I/U Activity as a percent of trans/run represents the percentage of total activity that will be across BUs. For example, if General Ledger has 2,000 journals for a Large Model and 100 BUs, then 80% of the journals will be created in 20% of business units, i.e journals in 20 business units. Among the journals created for the 20 business units, 20% of them contain inter-unit transactions, i.e. 320 journals contain inter-unit activities. The remaining 80 business units have only non-iu journals. As a general rule, General Ledger will process 80% of its activity in 20% of its Business Units. InterUnit Setup will consist of the Direct method (Legal Entity will be turned off) with the InterUnit template of CORP being attached to all GL Business Units. Additionally, the Affiliate Method will be used; this means that all current inter-unit transactions will have the affiliate field populated. LEDGER COMPOSITION The volume of existing ledger rows represents the base level of the ledgers prior to transaction processing. This base level includes 3 ledgers (Local, Budget and Reporting), where Budget rows are equivalent to Local rows, and Reporting rows are equivalent to Local rows. However, the journal transactions were posted to a single ledger (Local) and only the actuals ledger (LOCAL) will be utilized for this benchmark. The number of ChartFields remained constant throughout the testing. The ChartFields are as follows: Operating Unit, Account, Department, Product, Project, and Affiliate. The ledger rows were distributed across three years of 12 periods for each year 2011, 2012 and Assume Local represents 1/3 of the total ledger rows and the remaining 2/3 are within the Budget and Reporting ledger. For example, in a total of 10,000,000 ledger rows 3,333,333 would be Local, 3,333,333 would be Budget, and 3,333,333 rows in a Reporting ledger. JOURNAL COMPOSITION The volume of current journal lines represents the transactions that will be processed thru the Edit and Post processes. The average journal lines per header determine the ratio of detail journal lines per header. For example, 20,000,000 journal lines would consist of 2,000 headers with 10,000 detail lines each. The volume of historical journal lines represents the base level prior to transaction processing. The average journal lines per header determine the ratio of detail journal lines per header. For example, 2,500,000 journal lines would consist of 250 unique journals headers with 10,000 detail lines each. Existing historical Journal Lines consists of data spread evenly over 250 business days from to COPYRIGHT 2015 Oracle, Inc. All rights reserved. Page - 4

5 BENCHMARK ENVIRONMENT HARDWARE CONFIGURATION Database Server: A single logical domain of an Oracle s SPARC T7-2 server was used for this test. 1 Oracle Solaris Zone with 31 cores was used as a database server. It was equipped with the following: GHz SPARC M7 Thirty-Two Core processors each with 16 Kilobytes of Instruction and 16 Kilobytes of Data Level-1 on core cache, 128 Kilobytes of shared Instruction and Data Level-2 cache per core, and 48 Megabytes of Level-3 on-chip cache (32 cores total 256 vcpus/threads) 512 Gigabytes of Memory (~487 GB used at peak load) GB SAS internal disks Four Oracle Flash Accelerator F160 PCIe Cards were used for the database, undo, and redo logs. They were equipped with the following: 1.6 Terabytes of total SSD Space available. Approximately 1 TB was used for the database. Application Server: 1 Oracle Solaris Zone with 1 core on an Oracle s SPARC T7-2 server was used as an application server to host the Process Scheduler. SOFTWARE VERSIONS Oracle s PeopleSoft Financials (FMS) and Supply Chain Management (SCM) 9.2 ( ) Oracle s PeopleSoft Enterprise (PeopleTools) Oracle Database 11g (64-bit) Oracle Solaris 11.3 (on the Database Server) Oracle Tuxedo (64-bit) Oracle WebLogic Server Java Standard Edition (SE) (build 1.7.0_45-b18) Java HotSpot 64-bit server VM (build b08, mixed mode) Oracle (PeopleSoft) Pleasanton 5815 Owens Drive P. O. Box 8018 Pleasanton, California Tel 925/ Fax 925/ info@peoplesoft.com World Wide Web Enterprise FMS 9.2 on SPARC T7-2 October 2015 Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA U.S.A. Worldwide Inquiries: Phone: Fax: Copyright 2015, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. UNIX is a registered trademark licensed through X/Open Company, Ltd oracle.com COPYRIGHT 2015 Oracle, Inc. All rights reserved. Page - 5