Tuesday Mar 26, 2013

SPARC T5-2 Scores Siebel CRM Benchmark World Record

Oracle set a new world record for the Siebel Platform Sizing and Performance Program (PSPP) benchmark using Oracle's SPARC T5-2 servers for the application server with Oracle's Siebel CRM 8.1.1.4 Industry Applications and Oracle Database 11g Release 2 running on Oracle Solaris.

  • The SPARC T5-2 servers running the application tier achieved 40,000 users with sub-second response time and with throughput of 333,339 business transactions per hour on the Siebel PSPP benchmark.

  • The SPARC T5-2 servers in the application tier delivered 2 times better performance on a per chip basis compared to earlier published SPARC T4 numbers.

  • The Siebel 8.1.1.4 PSPP workload includes Siebel Call Center and Order Management System.

  • The SPARC T5-2 server used Oracle Solaris Zones which provide flexible, scalable and manageable virtualization to scale the application within and across multiple nodes.

Performance Landscape

Application Server Transactions/
hour
Users Users/
Core
Call
Center
Order
Mgmt
Response Times (sec)
2 x SPARC T5-2 (2 x SPARC T5 3.6 GHz) 333,339 40,000 625 0.110 0.608
3 x SPARC T4-2 (2 x SPARC T4 2.85 GHz) 239,748 29,000 604 0.165 0.925
2 x IBM Power 750 (POWER7 3.55 GHz, 16 active cores) 176,185 21,000 656 0.052 0.250

Oracle:
Call Center + Order Management
Transactions: 273,786 + 59,553
Users: 28,000 + 12,000

IBM:
Call Center + Order Management
Transactions: 144,457 + 31,728
Users: 14,700 + 6,300

Configuration Summary

Application Server Configuration:

2 x SPARC T5-2 servers, each with
2 x SPARC T5 processors, 3.6 GHz
512 GB memory
6 x 300 GB SAS internal disks
Oracle Solaris 10 8/11
Siebel CRM 8.1.1.4 SIA

Web Server Configuration:

1 x SPARC T4-1 server
1 x SPARC T4 processor, 2.85 GHz
128 GB memory
Oracle Solaris 10 8/11
iPlanet Web Server 7

Database Server Configuration:

1 x SPARC T4-2 server
2 x SPARC T4 processors, 2.85 GHz
256 GB memory
Flash Storage
Oracle Solaris 10 8/11
Oracle Database 11g Release 2 (11.2.0.2)

Benchmark Description

Siebel PSPP benchmark includes Call Center and Order Management:

  • Siebel Financial Services Call Center – Provides the most complete solution for sales and service, allowing customer service and telesales representatives to provide superior customer support, improve customer loyalty, and increase revenues through cross-selling and up-selling.

    High-level description of the use cases tested: Incoming Call Creates Opportunity, Quote and Order and Incoming Call Creates Service Request. Three complex business transactions are executed simultaneously for specific number of concurrent users. The ratios of these 3 scenarios were 30%, 40%, 30% respectively, which together were totaling 70% of all transactions simulated in this benchmark. Between each user operation and the next one, the think time averaged approximately 10, 13, and 35 seconds respectively.

  • Siebel Order Management – Oracle's Siebel Order Management allows employees such as salespeople and call center agents to create and manage quotes and orders through their entire life cycle. Siebel Order Management can be tightly integrated with back-office applications allowing users to perform tasks such as checking credit, confirming availability, and monitoring the fulfillment process.

    High-level description of the use cases tested: Order & Order Items Creation and Order Updates. Two complex Order Management transactions were executed simultaneously for specific number of concurrent users concurrently with aforementioned three Call Center scenarios above. The ratio of these 2 scenarios was 50% each, which together were totaling 30% of all transactions simulated in this benchmark. Between each user operation and the next one, the think time averaged approximately 20 and 67 seconds respectively.

Key Points and Best Practices

  • No processor cores or cache were activated or deactivated on the SPARC T-Series systems to achieve special benchmark effects.

See Also

Disclosure Statement

Copyright 2013, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. Results as of 26 March 2013.

SPARC T5 Systems Produce Oracle TimesTen Benchmark World Record

The Oracle TimesTen In-Memory Database is optimized to run on Oracle's SPARC T5 processor platforms running Oracle Solaris 11. In this series of tests, systems with the new SPARC T5 processor were significantly faster than systems based on other processors. Two tests were run to explore TimesTen performance: a Mobile Call Processing test (based on customer workload) and Oracle's TimesTen Performance Throughput Benchmark (TPTBM). TimesTen version 11.2.2.4 was used for all tests.

  • On the TimesTen Performance Throughput Benchmark (TPTBM), SPARC T5-8 server produced a world record 59.9 million read transactions per second.

  • On the Mobile Call Processing test, the SPARC T5 processor achieves 2.4 times more throughput than the Intel Xeon E7-4870 processor. The two-chip SPARC T5-2 server is 22% faster than an x86 server with four Intel E7-4870 2.4 GHz processors.

  • On the TimesTen Performance Throughput Benchmark (TPTBM) read-only workload, the SPARC T5 processor achieves 2.2 times higher throughput than the Intel Xeon E7-4870 processor. On the same workload, the two-chip SPARC T5-2 server produces 10% more throughput than an x86 server with four Intel E7-4870 processors and has almost twice the performance of a 2-chip Intel E5-2680 system.

  • With the TPTBM read-only workload, the SPARC T5-8 server delivers 3.8x more throughput than a SPARC T5-2 Server, showing excellent scalability.

  • The SPARC T5 processor delivers over twice the performace of the previous generation SPARC T4 processor and over 4x the performace of the SPARC T3 processor, all in the same amount of space.

  • The SPARC T5-2 server delivers 2.4x the performace of the SPARC T4-2 server in the same 3U space. This is better performance than that of the SPARC T4-4 server which occupies 5U.

Performance Landscape

Mobile Call Processing Test Performance

Processor Tps
SPARC T5, 3.6 GHz 367,600
Intel Xeon E7-4870, 2.4 GHz 302,000
SPARC T4, 2.85 GHz 230,500

All systems measured using Oracle Solaris 11 and Oracle TimesTen In-Memory Database 11.2.2.4.1

TimesTen Performance Throughput Benchmark (TPTBM) Read-Only

System Processor Chips Tps Tps/
Chip
SPARC T5-8 SPARC T5, 3.6 GHz 8 59.9M 7.5M
SPARC T5-2 SPARC T5, 3.6 GHz 2 15.9M 7.9M
x86 Intel Xeon E7-4870, 2.4 GHz 4 14.5M 3.6M
SPARC T4-4 SPARC T4, 3.0 GHz 4 14.2M 3.6M
x86* Intel Xeon E5-2680, 2.7 GHz 2 8.5M 4.3
SPARC T4-2 SPARC T4, 2.85 GHz 2 6.5M 3.3M
SPARC T3-4 SPARC T3, 1.65 GHz 4 7.9M 1.9M
T5440 SPARC T2+, 1.4 GHz 4 3.1M 0.8M

All systems measured using Oracle Solaris 11 and Oracle TimesTen In-Memory Database 11.2.2.4.1

*Intel E5-2680 using Oracle Linux and Oracle TimesTen In-Memory Database 11.2.2.4.1

TimesTen Performance Throughput Benchmark (TPTBM) Update-Only

Processor Tps
SPARC T5, 3.6 GHz 1,031.7K
Intel Xeon E7-4870, 2.4 GHz 988.1K
Intel Xeon E5-2680, 2.7 GHz * 944.3K
SPARC T4, 3.0 GHz 678.0K

All systems measured using Oracle Solaris 11 and Oracle TimesTen In-Memory Database 11.2.2.4.1

*Intel E5-2680 using Oracle Linux and Oracle TimesTen In-Memory Database 11.2.2.4.1

Configuration Summary

Hardware Configurations:

SPARC T5-8 server
8 x SPARC T5 processors, 3.6 GHz
2 TB memory
1 x 8 Gbs FC Qlogic HBA
1 x 6 Gbs SAS HBA
2 x 300 GB internal disks
Oracle Solaris 11
TimesTen 11.2.2.4.1
1 x Sun Fire X4275 server configured as COMSTAR redo head (log)

SPARC T5-2 server
2 x SPARC T5 processors, 3.6 GHz
512 GB memory
1 x 8 Gbs FC Qlogic HBA
1 x 6 Gbs SAS HBA
2 x 300 GB internal disks
Oracle Solaris 11
TimesTen 11.2.2.4.1
1 x Sun Fire X4275 server configured as COMSTAR redo head (log)

SPARC T4-4 server
4 x SPARC T4 processors, 3.0 GHz
1 TB memory
1 x 8 Gbs FC Qlogic HBA
1 x 6 Gbs SAS HBA
6 x 300 GB internal disks
Oracle Solaris 11
TimesTen 11.2.2.4.1
Sun Storage F5100 Flash Array (80 x 24 GB flash modules)
1 x Sun Fire X4275 server configured as COMSTAR redo head (log)

SPARC T4-2 server
2 x SPARC T4 processors, 2.85 GHz
256 GB memory
1 x 8 Gbs FC Qlogic HBA
1 x 6 Gbs SAS HBA
4 x 300 GB internal disks
Oracle Solaris 11
TimesTen 11.2.2.4.1
Sun Storage F5100 Flash Array (40 x 24 GB flash modules)
1 x Sun Fire X4275 server configured as COMSTAR head

SPARC T3-4 server
4 x SPARC T3 processors, 1.6 GHz
512 GB memory
1 x 8 Gbs FC Qlogic HBA
8 x 146 GB internal disks
Oracle Solaris 11
TimesTen 11.2.2.4.1
1 x Sun Fire X4275 server configured as COMSTAR head

Intel Server x86_64
2 x Intel Xeon E5-2680 processors, 2.7 GHz
256 GB memory
4 x SSD SAS disks (log)
1 x 600 GB internal disks
Oracle Linux
TimesTen 11.2.2.4.1

Sun Server X2-4
4 x Intel Xeon E7-4870 processors, 2.4 GHz
512 GB memory
1 x 8 Gbs FC Qlogic HBA
6 x 146 GB internal disks
Oracle Solaris 11
TimesTen 11.2.2.4.1
1 x Sun Fire X4275 server configured as COMSTAR redo head (log)

Benchmark Descriptions

TimesTen Performance Throughput BenchMark (TPTBM) is shipped with TimesTen and measures the total throughput of the system. The benchmark workloads can be reads, inserts, updates, and delete operations, or a mix of them as required.

Mobile Call Processing is a customer-based workload for processing calls made by mobile phone subscribers. The workload has a mixture of read-only, update, and insert-only transactions. The peak throughput performance is measured from multiple concurrent processes executing the transactions until a peak performance is reached via saturation of the available resources.

Key Points and Best Practices

The Mobile Call Processing test utilized Oracle Solaris processor sets in all environments for optimum performance. This features isolates running processes from other processes in the system. Combined with parameters to limit memory pages to the lgroup within the processor set and isolating the processor set to a single processor within the system.

See Also

Disclosure Statement

Copyright 2013, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. Results as of 26 March 2013.

SPARC T5-8 Delivers Oracle OLAP World Record Performance

Oracle's SPARC T5-8 server delivered world record query performance with near real-time analytic capability using the Oracle OLAP Perf Version 3 workload running Oracle Database 11g Release 2 on Oracle Solaris 11.

  • The maximum query throughput on the SPARC T5-8 server is 1.6x higher than that of the 8-chip Intel Xeon E7-8870 server. Both systems had sub-second response time.

  • The SPARC T5-8 server with the Oracle Database demonstrated the ability to support at least 600 concurrent users querying OLAP cubes (with no think time), processing 2.93 million analytic queries per hour with an average response time of 0.66 seconds per query. This performance was enabled by keeping the entire cube in-memory utilizing the 4 TB of memory on the SPARC T5-8 server.

  • Assuming a 60 second think time between query requests, the SPARC T5-8 server can support approximately 49,450 concurrent users with the same 0.66 sec response time.

  • The SPARC T5-8 server delivered 4.3x times the maximum query throughput of a SPARC T4-4 server.

  • The workload uses a set of realistic BI queries that run against an OLAP cube based on a 4 billion row fact table of sales data. The 4 billion rows are partitioned by month spanning 10 years.

  • The combination of the Oracle Database with the Oracle OLAP option running on a SPARC T5-8 server supports live data updates occurring concurrently with minimally impacted user query executions.

Performance Landscape

Oracle OLAP Perf Version 3 Benchmark
Oracle cube base on 4 billion fact table rows
10 years of data partitioned by month
System Queries/
hour
Users* Average Response
Time (sec)
0 sec think time 60 sec think time
SPARC T5-8 2,934,000 600 49,450 0.66
8-chip Intel Xeon E7-8870 1,823,000 120 30,500 0.19
SPARC T4-4 686,500 150 11,580 0.71

Configuration Summary and Results

SPARC T5-8 Hardware Configuration:

1 x SPARC T5-8 server with
8 x SPARC T5 processors, 3.6 GHz
4 TB memory
Data Storage and Redo Storage
1 x Sun Storage F5100 Flash Array (with 80 FMODs)
Oracle Solaris 11.1
Oracle Database 11g Release 2 (11.2.0.3) with Oracle OLAP option

Sun Server X2-8 Hardware Configuration:

1 x Sun Server X2-8 with
8 x Intel Xeon E7-8870 processors, 2.4 GHz
512 GB memory
Data Storage and Redo Storage
3 x StorageTek 2540/2501 array pairs
Oracle Solaris 10 10/12
Oracle Database 11g Release 2 (11.2.0.2) with Oracle OLAP option

SPARC T4-4 Hardware Configuration:

1 x SPARC T4-4 server with
4 x SPARC T4 processors, 3.0 GHz
1 TB memory
Data Storage
1 x Sun Fire X4275 (using COMSTAR)
2 x Sun Storage F5100 Flash Array (each with 80 FMODs)
Redo Storage
1 x Sun Fire X4275 (using COMSTAR with 8 HDD)
Oracle Solaris 11 11/11
Oracle Database 11g Release 2 (11.2.0.3) with Oracle OLAP option

Benchmark Description

The Oracle OLAP Perf Version 3 benchmark is a workload designed to demonstrate and stress the ability of the OLAP Option to deliver fast query, near real-time updates and rich calculations using a multi-dimensional model in the context of the Oracle data warehousing.

The bulk of the benchmark entails running a number of concurrent users, each issuing typical multidimensional queries against an Oracle cube. The cube has four dimensions: time, product, customer, and channel. Each query user issues approximately 150 different queries. One query chain may ask for total sales in a particular region (e.g South America) for a particular time period (e.g. Q4 of 2010) followed by additional queries which drill down into sales for individual countries (e.g. Chile, Peru, etc.) with further queries drilling down into individual stores, etc. Another query chain may ask for yearly comparisons of total sales for some product category (e.g. major household appliances) and then issue further queries drilling down into particular products (e.g. refrigerators, stoves. etc.), particular regions, particular customers, etc.

While the core of every OLAP Perf benchmark is real world query performance, the benchmark itself offers numerous execution options such as varying data set sizes, number of users, numbers of queries for any given user and cube update frequency. Version 3 of the benchmark is executed with a much larger number of query streams than previous versions and used a cube designed for near real-time updates. The results produced by version 3 of the benchmark are not directly comparable to results produced by previous versions of the benchmark.

The near real-time update capability is implemented along the following lines. A large Oracle cube, H, is built from a 4 billion row star schema, containing data up until the end of last business day. A second small cube, D, is then created which will contain all of today's new data coming in from outside the world. It will be updated every L minutes with the data coming in within the last L minutes. A third cube, R, joins cubes H and D for reporting purposes much like a view might join data from two tables. Calculations are installed into cube R. The use of a reporting cube which draws data from different storage cubes is a common practice.

Query users are never locked out of query operations while new data is added to the update cube. The point of the demonstration is to show that an Oracle OLAP system can be designed which results in data being no more than L minutes out of date, where L may be as low as just a few minutes. This is what is meant by near real-time analytics.

Key Points and Best Practices

  • Update performance of the D cube was optimized by running update processes in the FX class with a priority greater than 0. The maximum lag time between updates to the source fact table and data availability to query users (what was referred to as L in the benchmark description) was less than 3 minutes for the benchmark environment on the SPARC T5-8 server.

  • Building and querying cubes with the Oracle OLAP option requires a large temporary tablespace. Normally temporary tablespaces would reside on disk storage. However, because the SPARC T5-8 server used in this benchmark had 4 TB of main memory, it was possible to use main memory for the OLAP temporary tablespace. This was done by using files in /tmp for the temporary tablespace datafiles.

  • Since typical BI users are often likely to issue similar queries, either with the same, or different, constants in the where clauses, setting the init.ora parameter "cursor_sharing" to "force" provides for additional query throughput and a larger number of potential users.

  • Assuming the normal Oracle initialization parameters (e.g. SGA, PGA, processes etc.) are appropriately set, out of the box performance for the OLAP Perf workload should be close to what is reported here. Additional performance resulted from (a)using memory for the OLAP temporary tablespace (b)setting "cursor_sharing" to force.

  • For a given number of query users with zero think time, the main measured metrics are the average query response time and the query throughput. A derived metric is the maximum number of users the system can support, with the same response time, assuming some non-zero think time. The calculation of this maximum is from the well-known "response-time law"

      N = (rt + tt) * tp

    where rt is the average response time, tt is the think time and tp is the measured throughput.

    Setting tt to 60 seconds, rt to 0.66 seconds and tp to 815 queries/sec (2,934,000 queries/hour), the above formula shows that the SPARC T5-8 server will support 49,450 concurrent users with a think time of 60 seconds and an average response time of 0.66 seconds.

    For more information about the "response-time law" see chapter 3 from the book "Quantitative System Performance" cited below.

See Also

Disclosure Statement

Copyright 2013, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. Results as of 03/26/2013.

SPARC T5-2 Achieves ZFS File System Encryption Benchmark World Record

Oracle continues to lead in enterprise security. Oracle's SPARC T5 processors combined with the Oracle Solaris ZFS file system demonstrate faster file system encryption than equivalent x86 systems using the Intel Xeon Processor E5-2600 Sequence chips which have AES-NI security instructions.

Encryption is the process where data is encoded for privacy and a key is needed by the data owner to access the encoded data.

  • The SPARC T5-2 server is 3.4x faster than a 2 processor Intel Xeon E5-2690 server running Oracle Solaris 11.1 that uses the AES-NI GCM security instructions for creating encrypted files.

  • The SPARC T5-2 server is 2.2x faster than a 2 processor Intel Xeon E5-2690 server running Oracle Solaris 11.1 that uses the AES-NI CCM security instructions for creating encrypted files.

  • The SPARC T5-2 server consumes a significantly less percentage of system resources as compared to a 2 processor Intel Xeon E5-2690 server.

Performance Landscape

Below are results running two different ciphers for ZFS encryption. Results are presented for runs without any cipher, labeled clear, and a variety of different key lengths. The results represent the maximum delivered values measured for 3 concurrent sequential write operations using 1M blocks. Performance is measured in MB/sec (bigger is better). System utilization is reported as %CPU as measured by iostat (smaller is better).

The results for the x86 server were obtained using Oracle Solaris 11.1 with performance bug fixes.

Encryption Using AES-GCM Ciphers

System GCM Encryption: 3 Concurrent Sequential Writes
Clear AES-256-GCM AES-192-GCM AES-128-GCM
MB/sec %CPU MB/sec %CPU MB/sec %CPU MB/sec %CPU
SPARC T5-2 server 3,918 7 3,653 14 3,676 15 3,628 14
SPARC T4-2 server 2,912 11 2,662 31 2,663 30 2,779 31
2-Socket Intel Xeon E5-2690 3,969 42 1,062 58 1,067 58 1,076 57
SPARC T5-2 vs x86 server 1.0x 3.4x 3.4x 3.4x

Encryption Using AES-CCM Ciphers

System CCM Encryption: 3 Concurrent Sequential Writes
Clear AES-256-CCM AES-192-CCM AES-128-CCM
MB/sec %CPU MB/sec %CPU MB/sec %CPU MB/sec %CPU
SPARC T5-2 server 3,862 7 3,665 15 3,622 14 3,707 12
SPARC T4-2 server 2,945 11 2,471 26 2,801 26 2,442 25
2-Socket Intel Xeon E5-2690 3,868 42 1,566 64 1,632 63 1,689 66
SPARC T5-2 vs x86 server 1.0x 2.3x 2.2x 2.2x

Configuration Summary

Storage Configuration:

Sun Storage 6780 array
4 CSM2 trays, each with 16 83GB 15K RPM drives
8x 8 GB/sec Fiber Channel ports per host
R0 Write cache enabled, controller mirroring off for peak write bandwidth
8 Drive R0 512K stripe pools mirrored via ZFS to storage

Sun Storage 6580 array
9 CSM2 trays, each with 16 136GB 15K RPM drives
8x 4 GB/sec Fiber Channel ports per host
R0 Write cache enabled, controller mirroring off for peak write bandwidth
4 Drive R0 512K stripe pools mirrored via ZFS to storage

Server Configuration:

SPARC T5-2 server
2 x SPARC T5 3.6 GHz processors
512 GB memory
Oracle Solaris 11.1

SPARC T4-2 server
2 x SPARC T4 2.85 GHz processors
256 GB memory
Oracle Solaris 11.1

Sun Server X3-2L server
2 x Intel Xeon E5-2690, 2.90 GHz processors
128 GB memory
Oracle Solaris 11.1

Switch Configuration:

Brocade 5300 FC switch

Benchmark Description

This benchmark evaluates secure file system performance by measuring the rate at which encrypted data can be written. The Vdbench tool was used to generate the IO load. The test performed 3 concurrent sequential write operations using 1M blocks to 3 separate files.

Key Points and Best Practices

  • ZFS encryption is integrated with the ZFS command set. Like other ZFS operations, encryption operations such as key changes and re-key are performed online.

  • Data is encrypted using AES (Advanced Encryption Standard) with key lengths of 256, 192, and 128 in the CCM and GCM operation modes.

  • The flexibility of encrypting specific file systems is a key feature.

  • ZFS encryption is inheritable to descendent file systems. Key management can be delegated through ZFS delegated administration.

  • ZFS encryption uses the Oracle Solaris Cryptographic Framework which gives it access to SPARC T5 and Intel Xeon E5-2690 processor hardware acceleration or to optimized software implementations of the encryption algorithms automatically.

  • On modern computers with multiple threads per core, simple statistics like %utilization measured in tools like iostat and vmstat are not "hard" indications of the resources that might be available for other processing. For example, 90% idle may not mean that 10 times the work can be done. So drawing numerical conclusions must be done carefully.

See Also

Disclosure Statement

Copyright 2013, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. Results as of March 26, 2013.

SPARC T5-2 Obtains Oracle Internet Directory Benchmark World Record Performance

Oracle's SPARC T5-2 server running Oracle Internet Directory (OID, Oracle's LDAP Directory Server) on Oracle Solaris 11 achieved a record result for LDAP searches/second with 1000 clients.

  • The SPARC T5-2 server running Oracle Internet Directory on Oracle Solaris 11 achieved a result of 944,624 LDAP searches/sec with an average latency of 1.05 ms with 1000 clients.

  • The SPARC T5-2 server running Oracle Internet Directory demonstrated 2.7x better throughput and 39% better latency improvement over similarly configured OID and SPARC T4 benchmark environment.

  • The SPARC T5-2 server running Oracle Internet Directory demonstrates 39% better throughput and latency for LDAP searches on core-to-core comparison over an x86 system configured with two Intel Xeon X5675 processors.

  • Oracle Internet Directory achieved near linear scaling on the SPARC T5-2 server with 68,399 LDAP searches/sec with 2 cores to 944,624 LDAP searches/sec with 32 cores.

  • Oracle Internet Directory and the SPARC T5-2 server achieved up to 12,453 LDAP modifys/sec with an average latency of 3.9 msec for 50 clients.

Performance Landscape

Oracle Internet Directory Tests
System c/c/th Search Modify Add
ops/sec lat (msec) ops/sec lat (msec) ops/sec lat (msec)
SPARC T5-2 2/32/256 944,624 1.05 12,453 3.9 888 17.9
SPARC T4-4 4/32/256 682,000 1.46 12,000 4.0 835 19.0

In order to compare the SPARC T5-2 to a 12-core x86 system, only 1 processor and 12 cores was used in the SPARC T5-2.

Oracle Internet Directory Tests – Comparing Against x86
System c/c/th Search Compare Authentication
ops/sec lat (msec) ops/sec lat (msec) ops/sec lat (msec)
SPARC T5-2 1/12/96 417,000 1.19 274,185 1.82 149,623 3.30
x86 2 x Intel X5675 2/12/24 299,000 1.66 202,433 2.46 119,198 4.19

Scaling runs were also made on the SPARC T5-2 server.

Scaling of Search Tests – SPARC T5-2
Cores Clients ops/sec Latency (msec)
32 1000 944,624 1.05
24 1000 823,741 1.21
16 500 560,709 0.88
8 500 270,601 1.84
4 100 145,879 0.68
2 100 68,399 1.46

Configuration Summary

System Under Test:

SPARC T5-2
2 x SPARC T5 processors, 3.6 GHz
512 GB memory
4 x 300 GB internal disks
Flash Storage (used for database and log files)
1 x Sun Storage 2540-M2 (used for redo logs)
Oracle Solaris 11.1
Oracle Internet Directory 11g Release 1 PS6 (11.1.1.7.0)
Oracle Database 11g Enterprise Edition 11.2.0.3 (64-bit)

Benchmark Description

Oracle Internet Directory (OID) is Oracle's LDAPv3 Directory Server. The throughput for five key operations are measured — Search, Compare, Modify, Mix and Add.

LDAP Search Operations Test

This test scenario involved concurrent clients binding once to OID and then performing repeated LDAP Search operations. The salient characteristics of this test scenario is as follows:

  • SLAMD SearchRate job was used.
  • BaseDN of the search is root of the DIT, the scope is SUBTREE, the search filter is of the form UID=, DN and UID are the required attribute.
  • Each LDAP search operation matches a single entry.
  • The total number concurrent clients was 1000 and were distributed amongst two client nodes.
  • Each client binds to OID once and performs repeated LDAP Search operations, each search operation resulting in the lookup of a unique entry in such a way that no client looks up the same entry twice and no two clients lookup the same entry and all entries are searched randomly.
  • In one run of the test, random entries from the 50 Million entries are looked up in as many LDAP Search operations.
  • Test job was run for 60 minutes.

LDAP Compare Operations Test

This test scenario involved concurrent clients binding once to OID and then performing repeated LDAP Compare operations on userpassword attribute. The salient characteristics of this test scenario is as follows:

  • SLAMD CompareRate job was used.
  • Each LDAP compare operation matches user password of user.
  • The total number concurrent clients was 1000 and were distributed amongst two client nodes.
  • Each client binds to OID once and performs repeated LDAP compare operations.
  • In one run of the test, random entries from the 50 Million entries are compared in as many LDAP compare operations.
  • Test job was run for 60 minutes.

LDAP Modify Operations Test

This test scenario consisted of concurrent clients binding once to OID and then performing repeated LDAP Modify operations. The salient characteristics of this test scenario is as follows:

  • SLAMD LDAP modrate job was used.
  • A total of 50 concurrent LDAP clients were used.
  • Each client updates a unique entry each time and a total of 50 Million entries are updated.
  • Test job was run for 60 minutes.
  • Value length was set to 11.
  • Attribute that is being modified is not indexed.

LDAP Mixed Load Test

The test scenario involved both the LDAP search and LDAP modify clients enumerated above.

  • The ratio involved 60% LDAP search clients, 30% LDAP bind and 10% LDAP modify clients.
  • A total of 1000 concurrent LDAP clients were used and were distributed on 2 client nodes.
  • Test job was run for 60 minutes.

LDAP Add Load Test

The test scenario involved concurrent clients adding new entries as follows.

  • Slamd standard add rate job is used.
  • A total of 500,000 entries were added.
  • A total of 16 concurrent LDAP clients were used.
  • Slamd add's inetorgperson objectclass entry with 21 attributes (includes operational attributes).

See Also

Disclosure Statement

Copyright 2013, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. Results as of 26 March 2013.

SPARC T5-2 Scores Oracle FLEXCUBE Universal Banking Benchmark World Record Performance

Oracle's SPARC T5-2 server running Oracle FLEXCUBE Universal Banking Release 12 along with Oracle Database 11g Release 2 on Oracle Solaris 11 produced record results.

  • A SPARC T5-2 server running Oracle FLEXCUBE Universal Banking Release 12 and Oracle Real Application Clusters (RAC) Database 11g Release 2 processed 25 million accounts in 150 minutes for the End of Month workloads with an average utilization of 55% and 196 minutes utilizing 20 cores with an average cpu utilization of 85%.

  • A SPARC T5-2 server running Oracle FLEXCUBE Universal Banking Release 12 and Oracle Real Application Clusters (RAC) Database 11g Release 2 processed 25 million accounts in 56 minutes for the End of Day workload utilizing just 20 cores.

  • A SPARC T5-2 server running Oracle FLEXCUBE Universal Banking Release 12 achieved twice the throughput compared to a SPARC T4-4 server (which has twice the number of processors) for End of Month batch processing.

  • A SPARC T5-2 server running Oracle FLEXCUBE Universal Banking Release 12 achieved a record result processing 10.14 million accounts in 28 minutes for the End of Day workload with an average cpu utilization of 72% on a single server.

  • These results demonstrate how SPARC T5 processor systems along with Oracle Solaris 11 can benefit global, private and corporate financial institutions who are running Oracle FLEXCUBE Universal Banking. The uniquely co-engineered Oracle software and SPARC T5 processor based system unlock unique agile capabilities demanded by modern business environments.

  • The SPARC T5-2 system along with Oracle Solaris is able to provide a combination of uniquely essential characteristics that resonate with core values for a modern financial services institution.

  • The SPARC T5 processor based systems are capable of delivering higher performance and lower total cost of ownership (TCO) than older SPARC infrastructure, without introducing the unseen tax and risk of migrating applications away from older SPARC systems.

Performance Landscape

Oracle FLEXCUBE Universal Banking Release 12
End of Month Batch Processing
System Customer
Accounts
Time in Minutes Notes
SPARC T5-2 25M 150.66 RAC (two systems)
SPARC T5-2 10.14M 101.92 single instance
SPARC T4-4 10.14M 108.77 single instance
SPARC T4-4 5M 106.18 single instance, two chips

Oracle FLEXCUBE Universal Banking Release 12
End of Day Batch Processing
System Customer
Accounts
Time in Minutes Notes
SPARC T5-2 25M 56.05 RAC (two systems)
SPARC T5-2 10.14M 27.87 single instance

Configuration Summary

SPARC T5 Configuration:

1 x SPARC T5-2 with
2 x SPARC T5 processors, 3.6 GHz
512 GB memory
1 x SPARC T5-2 with
2 x SPARC T5 processors, 3.6 GHz
256 GB memory
Oracle Solaris 11 11/11
Oracle Database 11g Release 2 (RAC/ASM 11.2.0.3.0)
Oracle FLEXCUBE Universal Banking Release 12.0.1

SPARC T4 Configuration:

2 x SPARC T4-4, each with
4 x SPARC T4 processors, 3.0 GHz
512 GB memory
Oracle Solaris 11 11/11
Oracle Database 11g Release 2 (RAC/ASM 11.2.0.3.0)
Oracle FLEXCUBE Universal Banking Release 12.0.1

Storage Configuration:

3 x Sun Storage 6180 Array with
16 x 300 GB disks, 15K RPM (total of 48)
4 x Sun Storage CSM200 Expansion Trays, each with
16 x 73 GB disks, 15K RPM (total of 64)
Configured as RAID0, ASM external redundancy
Tests run with single instance DB (single node) and with ASM two nodes
ASM configuration identical on both 2 machines
Oracle Database 11g Release 2 ASM 11.2.0.3.0 64bit (19 TB)

Benchmark Description

The Oracle FLEXCUBE Universal Banking Release 12 benchmark models an actual customer bank with End of Cycle transaction batch jobs which typically execute during non-banking hours. This benchmark includes end of day accrual for savings and term deposit accounts, interest capitalization for saving accounts, and interest pay out for term deposit accounts. The results of the benchmark are certified by Oracle and a white paper is published.

End of cycle batch tests are conducted to measure the throughput capabilities of the system. It helps banks to decide the end of cycle processing window required to do the back office processing. The End of Day (EOD) batch test includes the following:

  • Mark End of Transaction Input
  • Value Dated Balance update
  • Interest and Charges (IC) Batch
  • Mark End of Financial Input
  • Mark End of Day
  • Date Change
  • Mark Transaction Input
The End of Month (EOM) batch test includes additional tests. These batches typically execute during non-banking hours. The goal is to ensure that the system is able to complete the batch operations for the planned volumes End of Day (EOD) within 60 minutes and End of Month (EOM) including interest and charges liquidation within 180 minutes.

 

See Also

Disclosure Statement

Copyright 2013, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. Results as of 26 March 2013.

SPARC T5-1B Performance Running Oracle Communications ASAP

Oracle's SPARC T5-1B server module delivered outstanding results on Oracle Communications ASAP. The SPARC T5-1B server module ran Oracle Solaris 11 with Oracle Database 11g Release 2, Oracle WebLogic Server 11g and Oracle Communications ASAP version 7.2.

  • Running Oracle Communications ASAP, the SPARC T5-1B server module achieved 1,722 ASDLs (atomic network activation actions) per second, the highest throughput that has been achieved in the 12NEP test for a single Oracle Communications ASAP instance across any SPARC architecture.

  • The SPARC T5-1B server module running a single instance of the Oracle Communications ASAP application, with both the application and database tiers consolidated onto a single machine, easily supported the service activation volumes of 1,722 ASDLs/sec which is representative of a typical mobile operator with more than 100 million subscribers.

  • Oracle Communications ASAP v7.2 delivered 48% higher throughput on a the SPARC T5-1B server module when compared to the SPARC T4-2 server.

  • The SPARC T5 processor delivered over 2 times the throughput compared to the previous generation SPARC T4 processor.

Performance Landscape

ASAP 7.2.0 12NEP Test Results
System ASDLs/sec CPU Usage
SPARC T5-1B 1,722.2 44.8%
SPARC T4-2 1,114.3 42.7%

Configuration Summary

Hardware Configuration:

SPARC T5-1B server module
1 x SPARC T5 processor at 3.6 GHz
256 GB memory

SPARC T4-2 server
2 x SPARC T4 processors at 2.85 GHz
256 GB memory

Storage Configuration:

Pillar Axiom

Software Configuration:

Oracle Solaris 11.1
Oracle Database 11g Release 2 (11.2.0.3.0)
Oracle WebLogic Server 10.3.6.0
Oracle Communications ASAP 7.2.0 (SR2B23)
Oracle JDK 7 update 7

Benchmark Description

Oracle Communications ASAP is used to activate a variety of services including data, video, voice and content services across mobile, fixed and satellite networks. Typical activities performed include activating new subscribers and services, moving / adding / changing / deleting services of existing subscribers and deleting existing subscribers and services.

The throughput of ASAP is measured in atomic actions per second (or ASDLs/sec). An atomic action is a single command or operation that can be executed on a network element. Atomic actions are grouped together to form a common service action, where each service action typically relates to an orderable item, such as "GSM voice" or "voice mail" or "GSM data". One or more service actions are invoked by an order management system via an activation work order request.

The workload resembles a typical mobile order to activate a GSM subscriber. A single service action to add a subscriber consists of seven atomic actions where each atomic action executes a command on a network element. Each network element was serviced by a dedicated Network Element Processor (NEP). The ASAP benchmark can vary the number of NEPs, which correlate to the complexity of a Telco operator's environment.

See Also

Disclosure Statement

Copyright 2013, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. Results as of 26 March 2013.

About

BestPerf is the source of Oracle performance expertise. In this blog, Oracle's Strategic Applications Engineering group explores Oracle's performance results and shares best practices learned from working on Enterprise-wide Applications.

Index Pages
Search

Archives
« February 2015
SunMonTueWedThuFriSat
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
       
       
Today