Skip to Content
Benchmark Procedure
APO
Cloud
Concurrent
CRM
ERP
Industries
Netweaver
Power
Archive
Businesswoman presenting Benchmarks on graphical screens

SAP Standard Application Benchmarks

SAP Standard Application Benchmarks help customers and partners find the appropriate hardware configuration for their IT solutions. Working in concert, SAP and our hardware partners developed the SAP Standard Application Benchmarks to test the hardware and database performance of SAP applications and components.

Industries

Transaction Banking (TRBK)

The Transaction Banking (TRBK) Benchmark is divided into two business scenarios. 

The first scenario, day processing, reflects usage by users and integrated systems that generally occurs during the daytime. The second scenario, night processing, reflects account balancing that generally occurs overnight in batch mode. This benchmark replaced the Bank Customer Accounts Benchmark.

During the day processing scenario, the benchmark program simulates typical daily volumes of a retail bank, including the quantity of payment transaction operations received from external payment transaction systems, single real-time payment transactions received from ATM machines, real-time account statements, as well as the quantity of account information read from the system. The scenario was constructed to mirror a distribution of typical banking tasks. Since the usual integration into the bank IT infrastructure takes place via real-time interfaces (BAPIs) rather than SAPGUI, the simulation consists of a sequence of BAPI calls.The following table shows in detail the sequence of all calls.

  1. . Create 30 postings in one call
  2. . Create 1 posting
  3. . Create 1 bank statement for account
  4. . Read postings for account
  5. . Read details of a posting
  6. . Create 1 posting
  7. . Create 1 bank statement for account
  8. . Create 1 posting
  9. . Create 1 bank statement for account
  10. . Create 1 payment order
  11. . Read balances of account
  12. . Create 1 posting
  13. . Create 1 bank statement for account
  14. . balances of account
  15. . Read account master data

In one loop a total of 35 postings are created in steps 1, 2, 6, 8, 10 (in this step one posting for sender part only), and 12.The simulation works in such a way that a configurable amount of simulation agents simultaneously repeat the complete loop of all steps several times. During every loop, a set of 20 different accounts is accessed. This means that, as in real life, the system does not repeat operations on the same set of accounts.

In the night processing scenario, account balancing is performed at regular intervals to settle an account. The benchmark simulates account balancing by calculating interest and charges for each account across 20 value date days. While the system triggers account balancing periodically, it is also possible to set the time periods manually.

During account balancing, the system performs the following tasks:

  • Determines balances
  • Calculates balancing-dependent interest and charges in accordance with the conditions assigned to the account and updates on the respective account
  • Increases the balancing date stored in the account master to the next date
  • Forwards the interest to the component to calculate interest-based income tax for further processing
  • Adjusts balancing of previous periods, when necessary, if there were value dates in the past or postings in the former account to already balanced periods

SAP TRBK Standard Application Benchmark Results, SAP for Banking - Account Management 3.0, Deposits Management 4.0 

 

Date of Certification (mm/dd/yyyy) Technology Partner Throughput / Hour Operating System - Release RDBMS Release SAP Release DB Server DB Server Memory (MB) Amount & Type of Application Servers Certification Number
9/12/2011 IBM Day Processing:
Number of postings to bank accounts: 56,518,000

Night Processing:
Number of balanced accounts: 22,382,000		 SUSE Linux Enterprise Server 11 SP1 IBM DB2 9.7 ESE with pureScale feature SAP Deposits Management (Banking Services Release 7.0) (total 5) 1 CF, 4 Members: IBM x3690 X5, 2 processors / 20 cores / 40 threads, Intel Xeon Processor E7-2870, 2.40 GHz, 64 KB L1 cache and 256 KB L2 cache per core, 30 MB L3 cache per processor 5 x 262144 (total 21) 1 Dialog/Batch/Message/Enq. Server, 20 Dialog/Batch servers: IBM BladeCenter HS22, 2 processors / 8 cores / 16 threads, Intel Xeon Processor X5570, 2.93 GHz, 64 KB L1 cache and 256 KB L2 cache per core, 8 MB L3 cache per processor, 48 GB main memory 2011035
8/20/2007 IBM Day Processing:
Number of postings to bank accounts: 15,519,000

Night Processing:
Number of balanced accounts: 7,429,000		 AIX 5L Version 5.3 DB2 9 Deposits Management 4.0 IBM System p 570, 2 processors / 4 cores / 8 threads, POWER6, 4.7 GHz, 128 KB L1 cache and 4 MB L2 cache per core, 32 MB L3 cache per processor 65,536 (total 3) 1 Dialog/Batch/Message/Enq. server: IBM System p 570, 16 processors / 16 cores / 32 threads, POWER5+, 2.2 GHz, 32 KB(D) + 64 KB(I) L1 cache per processor, 1.92 MB L2 cache and 36 MB L3 cache per 2 processors, 128 GB main memory; 2 Dialog/Batch server: IBM System p 570, 16 processors / 16 cores / 32 threads, POWER5+, 2.2 GHz, 32 KB(D) + 64 KB(I) L1 cache per processor, 1.92 MB L2 cache and 36 MB L3 cache per 2 processors, 128 GB main memory 2007050
4/13/2006 Sun Day Processing:
Number of postings to bank accounts: 10,012,000

Night Processing:
Number of balanced accounts: 6,664,000		 Solaris 10 Oracle 10g Account Management 3.0 Sun Fire Model E6900, 8 processors / 16 cores / 16 threads, UltraSPARC IV+, 1500 MHz, 128 KB(D) + 128 KB(I) L1 cache, 2 MB L2 cache on-chip, 32 MB L3 cache off-chip 57344 (total 6) 1 Message/Enq. server: Sun Fire Model V490, 4 processors / 8 cores / 8 threads, UltraSPARC IV, 1350 MHz, 128 KB(D) + 64 KB(I) L1 cache, 16 MB L2 cache, 16 GB main memory;
1 Dialog/Batch server: Sun Fire Model E6900, 16 processors / 32 cores / 32 threads, UltraSPARC IV+, 1500 MHz, 128 KB(D) + 128 KB(I) L1 cache, 2 MB L2 cache on-chip, 32 MB L3 cache off-chip, 96 GB main memory;
2 Dialog/Batch servers: Sun Fire Model E6900, 24 processors / 48 cores / 48 threads, UltraSPARC IV, 1200 MHz, 128 KB(D) + 64 KB(I) L1 cache, 16 MB L2 cache, 96 GB main memory;
2 Dialog servers: Sun Fire Model T2000, 1 processor / 8 cores / 32 threads, UltraSPARC T1, 1000 MHz, 64 KB(D) + 128 KB(I) L1 cache, 16 MB L2 cache, 32 GB main memory		 2006018
12/22/2005 HP Day Processing:
Number of postings to bank accounts: 8,279,000

Night Processing:
Number of balanced accounts: 4,270,000		 Windows Server 2003 Datacenter Edition (DB), Windows Server 2003 Enterprise Edition (32-bit) (Apps) SQL Server 2005 Account Management 3.0 (32 bit) HP Integrity Model rx8620,16 processors / 16 cores / 16 threads, HP mx2 dual-processor modules with 1.1 GHz Intel Itanium 2 processors, 32 KB L1 cache, 256 KB L2 cache, 4 MB L3 cache per processor, and 32 MB L4 cache per module 65,536 (total 33) 32 Dialog/Batch servers: HP ProLiant Model DL 360 G4p,2 processors / 2 cores / 4 threads, Intel XEON, 3.4 GHz, L1 Execution Trace Cache, 2 MB L2 cache, 3 GB main memory;
1 Message/Enq. server: HP ProLiant Model DL 360 G4p, 2 processors / 2 cores / 4 threads, Intel XEON, 3.4 GHz, L1 Execution Trace Cache, 2 MB L2 cache, 3 GB main memory		 2005052

Enlarge
View table

SAP for Utilities (ISU)

The SAP for Utilities Benchmark as the predecessor of the Customer Care and Service (IS-U/CCS) Benchmark simulates typical processes of a deregulated utility company.

The benchmark contains the main batch process of a typical utility company in a deregulated market and an additional online simulation. The batch process starts with metering and covers billing, revenue collection (FI-CA) and data transmission to market partners.

The throughput of the SAP for Utilities benchmark is measured in utilities reference customers (URC) per hour. A URC is the specific representation of a typical customer of a utility company in the ISU/CCS data model. In terms of this data model, a URC consists of one business partner with one contract account and one contract.

For each contract there is one installation with one device. Half the contracts are assigned to a different service provider to which usage information has to be sent.

The throughput unit URCs per hour describes how many URCs can be processed in one hour, assuming optimal usage of time. URC processing consists of:

  • Creation of meter reading orders
  • Download of meter reading orders
  • Uploading meter reading results
  • Billing, Invoicing and Bill Print
  • Payment run
  • Creation of dunning proposals
  • Execution of dunning run
  • Correspondence print
  • Sending IDocs with consumption data and electronic bills
  • Online simulation

SAP for Utilities Standard - Two-Tier

Date of Certification (mm/dd/yyyy) Technology Partner Utility Reference Customers (URCs) CPU Utilization Operating System - Release RDBMS Release SAP for Utilities Release Central Server Cert. Number
05/25/2012 Fujitsu 298,644 98% SuSE Linux Enterprise Server 11 Oracle 11g Real Application Clusters (RAC) SAP for Utilities using SAP ERP 6.0 Enhancement Package 5 Fujitsu PRIMERGY RX300 S6, 2 processors / 12 cores / 24 threads,
Intel Xeon Processor X5690, 3.46 GHz, 64 KB L1 cache and
256 KB L2 cache per core, 12 MB L3 cache per processor,
144 GB main memory		 2012025

Enlarge
View table

SAP for Utilities Standard - Three-Tier

Date of Certification (mm/dd/yyyy) Technology Partner Utility Reference Customers (URCs) CPU Utilization Operating System - Release RDBMS Release SAP for Utilities Release Number & Type of Database/Application Servers Cert. Number
05/25/2012 Fujitsu 590,035 95% SuSE Linux Enterprise Server 11 Oracle 11g Real Application Clusters (RAC) SAP for Utilities using SAP ERP 6.0 Enhancement Package 5 2 x Fujitsu PRIMERGY RX300 S6, 2 processors / 12 cores / 24 threads,
256 KB L2 cache per core, 12 MB L3 cache per processor,
144 GB main memory		 2012024

Enlarge
View table

Customer Care and Services (ISU/CCS)

The Customer Care and Service (ISU/CCS) Benchmark simulates typical processes in a utilities company. 

The core business processes can be divided into two main processes: consumption and revenue collection. For the consumption process, three batch jobs are utilized for collecting information – meter-reading orders have to be created and printed, and the results have to be uploaded into the system. To collect revenues, additional batch jobs – billing the customer, invoicing, and printing the bill – produce load on the system.

The throughput of the ISU/CCS Benchmark is measured in Utilities Reference Customers (URC) per hour. A URC is the specific representation of a typical customer of a utility company in the ISU/CCS data model. In terms of this data model, a URC consists of one business partner with one contract account and two contracts.

For each contract there is one installation with one device.

The throughput unit URCs per hour describes how many URCs can be processed in one hour, assuming optimal usage of time. URC Processing consists of:

  • Creating meter reading orders
  • Outputting meter reading orders
  • Uploading meter reading results
  • Billing
  • Invoicing
  • Printing the bill

SAP ISU/CCS Standard Application Benchmark Results, SAP for Utilities -  Customer Care and Service

Date of Certification (mm/dd/yyyy) Technology Partner Utility Reference Customers (URCs) Meter Reading Order:
Creation / Output		 Meter Results Upload Contract Billings Contract Accounts: Invoicing / Printing Operating System Release RDBMS Release ISU/CCS Release Central Server DB server memory (MB) Cert. Number
03/11/2003 Fujitsu Siemens Computers 108,551 2,177,200 / 1,285,255 1,815,431 1,809,045 723,037 / 317,741 Solaris 8 Oracle 9i 4.64 Fujitsu Siemens Computers PRIMEPOWER 900, 16-processors SMP, SPARC64TM V, 1.35 GHz, 256 KB L1 cache, 2 MB L2 cache 65,536 2003013
12/03/2002 HP 56,156 1,110,254 / 582,006 897,980 945,751 354,087 / 185,061 HP-UX 11i Oracle 9i 4.64 hp server rp8400, 16-processors SMP, PA-RISC 8700 750 MHz, 1.5 MB L2 cache 65,536 2002066
06/01/2001 HP 19,893 201,624 / 417,949 236,004 414,269 143,672 / 96,920 HP-UX 11 Oracle 8.0.6 4.61 HP 9000 N4000 Enterprise Server, 8-processors SMP, PA86000 550, 1.5 MB L2 cache 16,384 2001019
07/12/2000 Sun 27,488 474,760 / 332,480 578,440 313,930 166,600 / 96,920 Solaris 7 Oracle 8.0.5 1.2 B SUN Enterprise E6500K, 22-way SMP, UltraSPARC II, 400 MHz, 4 MB L2 cache 22,528 2000018

Enlarge
View table

Retail - POS Inbound

The POS Inbound Benchmark measures the throughput of the point-of-sale (POS) interface-inbound for aggregated sales data. This is a critical time process in a real business scenario. The data will be ported to materials management, sales and distribution, or financials and is the basis for replenishment.

  • 0. Logon
  • 1. Main screen
  • 2. Call /nWPUK (POS simulation: selection)
  • 3. Choose Aggregated sales4. Choose Settings
  • 4. Choose Repeats
  • 5. Enter data and choose Continue
  • 6. Choose Save
  • 7. Choose IDOC status
  • 8. Choose Continue
  • 9. Call /nend
  • 10. Confirm log off

User interaction steps 2 - 9 are repeated n times (eight user interaction steps).
Sales data line items per loop = 96; posted documents = inventory management, billing, financials

SAP Retail Standard Application Benchmark Results - POS Inbound

Date of Certification (mm/dd/yyyy) Technology Partner Processed Sales Data Line Items (POS Inbound) Average DB Request Time (sec) Dia / Upd Operating System - Release RDBMS Release R/3 Release Database Server DB server memory (MB) Amount & Type of Application Servers Cert. Number
11/17/1999 Compaq 3,165,000 0.734 / 0.836 Windows 2000 SQLServer 7.0 4.5 B Compaq ProLiant 8000 6/550-2M, 8-way SMP, Pent III Xeon, 550 MHz, 2MB L2cache 4,096 (total: 28) 16 x Proliant 8500 6/550-2M, 8-way, 10 x ProLiant 8000 6/550-2M, 8-way 2 x ProLiant 7000 6/500 1999037
09/14/1999 Compaq 3,014,000 0.694 / 0.031 Windows NT 4.0 SQLServer 7.0 4.5 B Compaq ProLiant 8500 6/550-2M, 8-way SMP, Pent III Xeon, 550 MHz, 2MB L2cache 4,096 (total: 26) 16 x Proliant 8500 6/550-2M, 8-way, 10 x ProLiant 8000 6/550-2M 1999029
06/29/1999 SUN 2,412,000 2.066 / 0.044 Solaris 2.6 Oracle 8.0.5 4.0 B Sun Ultra-Enterprise Server 10000, 32-way SMP, Ultrasparc II, 400MHz, 4MB L2 cache 4,096 (total: 3) 2 x (Dia) Sun Ultra-Enterprise Server 10000, 60-way SMP, Ultrasparc II, 400MHz, 4MB L2 cache 1999018
03/12/1999 Data General 816,000 1.552 / 0.416 Windows NT 4.0 Oracle 8.0.4 4.0 B Data General AV8700, 4-way SMP, Pentium II Xeon 450 MHz, 2 MB L2 Cache 4,096 (total: 17) 16 x Data General AV3700R, 4-way SMP, Pentium II Xeon 400 MHz, 1 MB L2 Cache 1999005
11/02/1998 IBM 1,345,000 1.049 / 0.159 OS/400 V4R3 DB2/400 V4R3 4.0 B AS/400e, Model S40-2207, 8-way SMP, PowerPC 262MHz 20,480 (total: 11) 11 x AS/400e, 9 x Model s40-2208 12-way SMP, 262MHz 1998038

Enlarge
View table

Retail - Store Replenishment

The Store Replenishment Benchmark is more comprehensive than the POS Inbound Benchmark. It comprises a pre-step for point-of-sale (POS) upload that provides the sales data for the replenishment process.

The Store Replenishment Benchmark consists of the following business scenario:

  • POS Upload: The sales data from the stores is uploaded and posted into the central retail system. Note that this is only a pre-step of the POS upload in the POS Inbound Benchmark. In the Store Replenishment Benchmark, only the quantitative information of sold articles into specific database tables used for the replenishment run is updated.
  • Requirement calculation: On the basis of sales data, forecast data, and stock data, a requirement calculation is conducted.
  • Follow-on document creation: The results of the second step are taken to create follow-on documents such as purchase orders for external vendors and delivery and transfer orders for internal distribution centers.

The steps, above, are run for 1,000 stores. Every store contains 10,000 articles, distributed into 100 merchandise categories with 100 articles each. One half of the articles are received from 50 external vendors. The other half comes from internal distribution centers (DC). There are 10 DCs in total, and 100 stores are associated with each DC.

In the POS upload step, 100 IDOCs (WPUBON) with 1,000 line items have to be processed for each store. Every IDOC contains sales data for the 100 articles of a merchandise category. This means that 100,000 IDOCs with 100 million line items have to be processed in total. For each article, there are 10 line items in different receipts of an IDOC, so that aggregation reduces the data volume by a factor of 10. Due to the sales information in the IDOC, 2,000 articles must be replenished in every store.

During requirements calculation, the system checks the number of sold articles in every store (each with 10,000 articles) to determine whether a replenishment is required. As mentioned above, this will be the case for 20 percent of all articles (2,000) in every store.

In the final step, follow-on documents – purchase orders, deliveries, and transfer orders – are created for all articles determined in step 2. For the 1,000 articles that are delivered from an internal DC to a store, 10 deliveries with 100 items each are created. This triggers the creation of 10 corresponding transfer orders with 100 items. For the articles coming from external vendors, 50 purchase orders with 20 lines are created for each store. Consequently, 10,000 deliveries, 10,000 transfer orders, and 50,000 purchase orders are created in total.

SAP Retail Standard Application Benchmark Results - Replenishment

Date of Certification (mm/dd/yyyy) Technology Partner Fully Processed Stores / Hour Step Throughput Data / hour Operating System - Release RDBMS Release R/3 Release Central Server Memory (MB) Cert. Number
01/21/2002 HP 676 Step 1: Upload


Step 2: Replenishment


Step 3: Follow-on doc. creation		 Line items: 531,757,755

Article/store comb:
44,117,647

Line items:
2,819,843		 HP-UX 11i Oracle 9i 4.6 C HP SuperDome Enterprise Server SD64000, 64-way SMP, PA-RISC 8600, 550 MHz, 1.5 MB L2 cache 65,536 2002004

Enlarge
View table
Back to top