by Randal Sagrillo
This is the first in a series of articles describing test results from running Oracle FLEXCUBE on Oracle's SPARC servers and engineered systems.
|
Introduction
Oracle Optimized Solution for Oracle FLEXCUBE is a secure, highly efficient, highly scalable, multimillion-customer-account online banking platform that delivers high availability out of the box. This solution features Oracle FLEXCUBE Release 12 on the latest SPARC servers from Oracle running Oracle Solaris 11 with built-in low-overhead virtualization, Oracle ZFS Storage Appliance systems, and Oracle's high-speed networking technology. The entire solution, from applications to disk, is supported end to end by Oracle, and it has already achieved a world record on SPARC T5-2 servers and another world record on SPARC T7-1 servers.
This article presents the latest performance testing and benchmark results running new, relevant, and more-real-world workloads on Oracle's SPARC T7-1 servers. Test results using these new workloads were also run against Oracle's SPARC T5-2 servers to provide apples-to-apples generational performance comparisons.
These results show that upgrading to SPARC T7-1 servers, with their Software in Silicon capabilities, can improve measured per-core throughput by over 1.6x compared to SPARC T5-2 servers on batch workloads typical for a real bank.
| |
|
Oracle Optimized Solutions provide tested and proven best practices for how to run software products on Oracle systems. Learn more.
|
|
Table of Contents
SPARC T7-1 Server
The SPARC T7-1 server is based on Oracle's innovative SPARC M7 processor, which implements Oracle's Software in Silicon technology. Specialized acceleration engines on each SPARC M7 processor provide specific software functions that can have a dramatic impact on applications. For example, Data Analytics Accelerator (DAX) units offload Oracle Database In-Memory database query processing and perform real-time data decompression on-chip. In-Memory Query Acceleration, another feature of the SPARC M7 processor, delivers performance that is up to 10 times faster than other processors, while In-Line Decompression allows up to 2 times more data to be stored in the same memory footprint without any performance penalty. And, the SPARC M7 processor's Silicon Secured Memory feature provides real-time data integrity checking to guard against pointer-related software errors and malware.
The SPARC M7 processor also provides improved per-thread performance; reliability, availability, and serviceability (RAS) capabilities; increased power efficiency; and double the memory and I/O bandwidths compared to previous SPARC processors.
Each SPARC T7-1 server used in these tests contained a single 4.13 GHz SPARC M7 processor with 32 cores and up to 8 threads per core. For the test results for SPARC T7-1 servers described in this article, Oracle Database In-Memory was not used. As such, DAX offload was not used. Oracle Database In-Memory is for optimizing analytic queries. But the typical banking workloads running Oracle FLEXCUBE described in this article focus on transactional and data manipulation language (DML) batch workloads. So the small amount of improvement that Oracle Database In-Memory demonstrated during initial testing indicated these workloads were not worth the added cost of using Oracle Database In-Memory. The SPARC M7 processor's Silicon Secured Memory feature was used during all testing as part of all processing done with Oracle Database Release 12.1.
Banking Workloads
The workloads used in these tests simulate and measure the performance and scalability of daily and monthly batch processing scenarios typical of a real bank. They include end-of-day (EOD) and end-of-month (EOM) reconciliation calculations of bank assets (loan accounts) and bank liabilities (savings and money market accounts), as well as online banking transactions (OLTP). Batch workload tests include data for customers, accounts, and transactions. One of the big changes in this the tests described in this article is the addition of bank assets (loan processing) to the workloads. This makes the workloads described here more demanding and also more real-world. In the past, before these workloads were available for use by Oracle Financial Services for performance testing, the world record results mentioned at the beginning of this article were for both batch and OLTP liability-only workloads.
Additionally, experience shows most banking operations are much more concerned with EOD batch processing: it happens every day and is one of the most demanding time-critical workloads. Although EOM and end of year (EOY) workloads are more demanding—and, hence, take longer to run—they obviously happen much less often. Finally, OLTP is part of everyday bank operations and uses more application tier resources than batch processing, which, practically speaking, uses only database tier resources. However, OLTP uses fewer database resources less intensively, which means it is much easier to design deployment solutions that readily meet bank performance service-level objectives.
OLTP Workload
For the online testing, OLTP transactions can be performed as part of an Oracle FLEXCUBE deployment in the following ways:
- Through Oracle FLEXCUBE host calls
- Through gateway/web service calls
- Through the Automated Teller Machine (ATM) switch interface gateway
The OLTP transactions for this benchmark were performed through gateway calls, including the following:
- Retail teller
- Consumer loans
- Standing instructions
- Funds transfer
- Current account and savings account (CASA) operations
- ATM
- Single-customer view
The workload generators simulating about 200 concurrent users create a transactional banking workload mix consisting of a variety of queries along with deposits, withdrawals, and transfer transactions.
Table 1. Workload characteristics
| Workload Characteristic | Value |
| Number of branches | 200 |
| Number of customers | 19,450,000 |
| Number of customer accounts | 25,000,000 |
| Number of connected users | 1,500 |
| Number of concurrent users | ~200 |
| Test duration (in minutes) | 60 |
| Load mix | 70% transaction
30% query |
End-of-Day and End-of-Month Batch Workloads
EOD batch runs include processing for the following:
- Interest and charges
- Consumer loans
- Standing instructions
- Funds transfer
This processing includes interest capitalization and interest payout. EOM batch runs also include customer account accruals and liquidation. For each account, interest is calculated for accrual and liquidated for credit during batch runs. The interest is calculated according to the interest calculation rule and mapped to the products within each customer account.
As with OLTP above, all 25 million accounts—including savings, current, and term deposit (TD) accounts—are created for a base of 19.5 million customer IDs with 200 branches. Two million consumer loans are also created as part of the base volume.
The total data volume is distributed using a specific pattern among the 200 branches, 25 million accounts, and 19.5 million customers used to test and demonstrate the EOD and EOM batch processing performance. For example, some branches have a high number of CASA accounts, some have a higher number of TD accounts than the rest, some have a large number of long-term loans, and some have a large number of short-term loans. This distribution provides a realistic mix of data volumes for a bank. An approximately equal number of transactions are performed for all branches, covering standing instructions, retail teller, data entry, and ATM teller modules.
Solution Configuration
The test workloads were run against a pair of SPARC T7-1 servers. To build redundancy into the system under test and to eliminate any single point of failure—as in a real production environment—the configuration under test was built with two database nodes in an Oracle Real Application Clusters (Oracle RAC) configuration with two application server nodes, each running Oracle FLEXCUBE. Additionally, the solution under test had redundant network connectivity across all these components for connected clients, application servers, and database servers, Oracle RAC private interconnects, and Oracle RAC shared storage interconnects.
Both of the Oracle FLEXCUBE Release 12.1.0 application instances were deployed on Oracle WebLogic Server 10.3.6, each running on Oracle Solaris 11. For the database tier, two Oracle Database 12.1.0.2 nodes were deployed on two SPARC T7-1 servers running Oracle Solaris 11. The database files were deployed an Oracle ZFS Storage Appliance system. Additionally, there was an Oracle Cluster Registry (a component of Oracle Clusterware) LUN for use by Oracle Clusterware. The configuration and core allocations tested under the OLTP workload are depicted in Figure 1. For the apples-to-apples EOM batch comparisons between SPARC T7-1 and T5-2 servers, all 64 cores in both solution configurations were allocated to the database logical domains (LDoms) to stress scaling while determining per-core batch throughput.
Figure 1. Oracle FLEXCUBE configuration on a pair of SPARC T7-1 servers
Measured Performance Results
OLTP Results
For 25 million accounts, 19.45 million customers, and 200 concurrent users, the system processed 6.9 million transactions averaging 1,904 transactions per second. Average 90th percentile response times for all transactions except fund transfers, create-contract operations, and create-loan operations were under 200 milliseconds. ATM queries demonstrated average 90th percentile response times of 16 milliseconds. Only create-loan operations took longer than one second with an average 90th percentile response time of 10.95 seconds. Additionally, average CPU utilization in the database tier was only 50 percent, while the application tier showed only a 15 percent average CPU utilization. While not an apples-to-apples workload comparison between SPARC T7-1 and T5-2 servers, especially considering the addition of loan processing, the results demonstrated on SPARC T7-1 servers were significantly better compared to results from tests using the same number of cores on SPARC T5-2 servers.
EOD and EOM Batch Results
Batch job builds and layout optimizations are part of the Oracle FLEXCUBE application and are dependent upon execution in the application tier. However, the execution of the batch jobs themselves is solely within the database tier.
For 25 million accounts and almost 20 million customers, EOD processing—using 64 cores—completed in 53 minutes. This is an impressive result with any workload at this scale of accounts. EOM processing completed in 2 hours and 50 minutes (170 minutes) on 64 cores at 70 percent average CPU utilization.
Batch Results Comparison with SPARC T5-2 Servers
An apples-to-apples comparison pitting a pair of SPARC T7-1 servers against a pair of SPARC T5-2 servers was run using the exact same workloads and configurations. Results show the identical EOM processing run described above for the SPARC T7-1 servers took 281 minutes on the SPARC T5-2 servers with 70 percent average CPU utilization. Again, this was with 25 million accounts, 200 branches, and each system using 64 cores in the database running the batch processing. The figures below show the dramatic difference in the time required to complete the same work and batch throughout per core for identical workloads. These results represent a 1.65 times higher throughput per core just by upgrading to a SPARC T7-1 server and its Software in Silicon SPARC M7 processor.
Figure 2. EOM processing times in minutes
Figure 3. Accounts processed per minute
Conclusion
The continued coengineering of Oracles systems to optimize the operation of Oracle Database is showing ever-increasing benefits for database-intensive workloads such as those performed by Oracle FLEXCUBE. Additionally, deeper coengineering between Oracle systems and Oracle Financial Services products such as Oracle FLEXCUBE is further increasing the benefits that financial institutions can reap running Oracle software on Oracle hardware. This article demonstrated the following:
- Oracle Optimized Solution for Oracle FLEXCUBE running on Oracle's SPARC T7-1 servers ran an EOM batch workload with over 1.6X better throughput per core compared to SPARC T5-2 servers, providing improved back office productivity and OLTP response times, which indicate an improved customer experience.
- Using Oracle's SPARC T7-1 servers rather than Oracle's SPARC T5-2 servers saves money by reducing infrastructure acquisition costs and lowering software licensing costs per core, dramatically raising the value of running Oracle FLEXCUBE on Oracle's latest SPARC servers.
- Reduced operational risk, high-availability fault handing, and improved Security in Silicon features can be attained while also reducing the deployment risk of running Oracle FLEXCUBE due to its extensive pretesting and efficient sizing.
Stay tuned for additional articles showing the advantages and benefits of running Oracle FLEXCUBE on Oracle's SPARC servers.
See Also
About the Author
Randal Sagrillo is a solutions architect for Oracle. He has over 35 years of IT experience and is an expert in storage and systems performance, most recently applying this expertise to next-generation data center architectures, integrated systems, and Oracle engineered systems. Randal is also a frequent and well-attended speaker on database platform performance analysis and tuning and has spoken at several industry conferences including Oracle OpenWorld, Collaborate, Computer Measurements Group, and Storage Networking World. In his current role, he is a solution architect in the Oracle Optimized Solutions group and focuses on solutions concerning database performance. Before joining Oracle, Sagrillo held a variety of leadership roles in product management, program management, and hardware/software product development engineering.