SPARC T3-4 Sets World Record Single Server Result on SPECjEnterprise2010 Benchmark

World Record Single Application Server System Performance

Oracle produced a single application server world record SPECjEnterprise2010 benchmark result using Oracle's SPARC T3-4 server for the application server and Oracle's SPARC T3-2 server for the database server.
  • A SPARC T3-4 server paired with a SPARC T3-2 server delivered a result of 9456.28 SPECjEnterprise2010 EjOPS for the SPECjEnterprise benchmark.

  • The SPARC T3-4 server running at 1.65 GHz demonstrated 32% better performance compared to the IBM Power 750 system result of 7172.93 SPECjEnterprise2010 EjOPS which used four POWER7 chips running at 3.55 GHz.

  • The 4-socket SPARC T3-4 server was 32% faster than a 4-socket IBM Power 750 system proving that IBM's per-core performance is irrelevant when compared to system performance.

  • The SPARC T3-4 server has 5% better computational density than the IBM Power 750 system.

  • The SPARC T3-4 server running SPARC T3 processors at 1.65 GHz demonstrated 84% better performance compared to the IBM x3850 X5 system result of 5140.53 SPECjEnterprise2010 EjOPS using four Intel Xeon chips at 2.27 GHz.

  • The SPARC T3-4 server has 47% better computational density than the IBM x3850 X5 system.

  • This world record result was achieved using Oracle Weblogic 10.3.3 application server and Oracle Database 11g R2.

  • Oracle Fusion Middleware provides a family of complete, integrated, hot plugable and best-of-breed products known for enabling enterprise customers to create and run agile and intelligent business applications. The Oracle WebLogic Server's on-going, record-setting Java application server performance demonstrates why so many customers rely on Oracle Fusion Middleware as their foundation for innovation.

  • To obtain this leading result a number of Oracle technologies were used: Oracle Solaris 10, Oracle Solaris Containers, Oracle Java Hotspot VM, Oracle Weblogic, Oracle Database 11gR2, SPARC T3-4 server, and SPARC T3-2 server.

  • The SPARC T3-4 server demonstrated less than 1 second average response times for all SPECjEnterprise2010 transactions and 90% of all transaction times took less than 1 second.

  • The two T-series systems occupied a total of 16 RU of space. This is less than half of the 37 RU of space used in the IBM Power 750 system result of 7172.93 SPECjEnterprise2010 EjOPS.

  • The SPARC T3-4 server result only used 61% of floor space compared to the IBM x3850 X5 system result of 5140.53 SPECjEnterprise2010 EjOPS which requires 26 RU of space.

Performance Landscape

Complete benchmark results are at the SPEC website, SPECjEnterprise2010 Results.

SPECjEnterprise2010 Performance Chart
as of 9/20/2010
Submitter EjOPS\* Application Server Database Server
Oracle 9456.28 1 x Oracle SPARC T3-4
4 x SPARC 1.65 GHz SPARC T3
Oracle WebLogic 10.3.3
1 x Oracle SPARC T3-2
2 x 1.65 GHz SPARC T3
Oracle 11g DB 11.2.0.1
IBM 7172.93 1 x IBM Power 750 Express
4 x 3.55 GHz POWER7
WebSphere Application Server V7.0
1 x IBM BladeCenter PS702
2 x 3.0 GHz POWER7
IBM DB2 Universal Database 9.7
IBM 5140.53 1 x IBM x3850 X5
4 x 2.2 GHz Intel X7560
WebSphere Application Server V7.0
1 x IBM x3850 X5
4 x 2.2 GHz Intel X7560
IBM DB2 Universal Database 9.7

\* SPECjEnterprise2010 EjOPS, Bigger is better.

Results and Configuration Summary

Application Server:

1 x Oracle SPARC T3-4 server
4 x 1.65 GHz SPARC T3 processors
256 GB memory
4 x 10GbE NIC
Oracle Solaris 10 9/10
Oracle Solaris Containers
Oracle WebLogic 10.3.3 Application Server - Standard Edition
Oracle Fusion Middleware
Oracle Java SE, JDK 6 Update 21

Database Server:

1x Oracle SPARC T3-2
2 x 1.65 GHz SPARC T3 processors
256 GB memory
2 x 10GbE NIC
2 x Sun Storage 6180 Array
Oracle Solaris 10 9/10
Oracle Database Enterprise Edition Release 11.2.0.1

Benchmark Description

The SPECjEnterprise2010™ benchmark is a full system benchmark which allows performance measurement and characterization of Java EE 5.0 servers and supporting infrastructure such as JVM, Database, CPU, disk and servers.

The workload consists of an end-to-end web-based order processing domain, an RMI and Web Services driven manufacturing domain and a supply chain model utilizing document-based Web Services. The application is a collection of Java classes, Java Servlets, Java Server Pages , Enterprise Java Beans, Java Persistence Entities (pojo's) and Message Driven Beans.

SPECjEnterprise2010 is the third generation of the SPEC organization's J2EE end-to-end industry standard benchmark application. The new SPECjEnterprise2010 benchmark has been re-designed and developed to cover the JEE 5.0 specification's significantly expanded and simplified programming model, highlighting the major features used by developers in the industry today. This provides a real world workload driving the Application Server's implementation of the Java EE specification to its maximum potential and allowing maximum stressing of the underlying hardware and software systems.

SPEC has paid particular attention to making this benchmark as easy as possible to install and run. This has been achieved by utilizing simplification features of the Java EE 5.0 platform such as annotations and sensible defaulting and by the use of the opensource Faban facility for developing and running the benchmark driver.

SPECjEnterprise2010's new design spans Java EE 5.0 including the new EJB 3.0 and WSEE component architecture, Message Driven beans, and features level transactions.

Key Points and Best Practices

  • Eight Oracle WebLogic server instances on the SPARC T3-4 server were hosted in 8 separate Oracle Solaris Containers to demonstrate consolidation of multiple application servers.

  • Each Oracle Solaris container was bound to a separate processor set, each containing 7 cores. This was done to improve performance by using the physical memory closest to the processors, thereby, reducing memory access latency. The default processor set was used for network and disk interrupt handling.

  • The Oracle WebLogic application servers were executed in the FX scheduling class to improve performance by reducing the frequency of context switches.

  • The Oracle database processes were run in 2 processor sets using the Oracle Solaris psrset utility and executed in the FX scheduling class. These were done to improve performance by reducing memory access latency and by reducing context switches.

  • The Oracle Log Writer process was run in a separate processor set containing 1 core and run in the RT scheduling class. This was done to insure that the Log Writer had the most efficient use of CPU resources.

See Also

Disclosure Statement

SPEC is a registered trademark and SPECjEnterprise is a trademark of Standard Performance Evaluation Corporation. Results from www.spec.org as of 9/20/2010. SPARC T3-4 9456.28 SPECjEnterprise2010 EjOPS. IBM Power 750 Express 7,172.93 SPECjEnterprise2010 EjOPS. IBM System x3850 X5 5,140.53 SPECjEnterprise2010 EjOPS.

IBM Power 750 Express (4RU each).
IBM BladeCenter H Chassis (9RU each).
IBM System x3850 X5 (4RU each).
IBM DS4800 Disk System Model 82 (4RU each).
IBM DS4000 EXP810 (3RU each).

http://www-03.ibm.com/systems/power/hardware/750/index.html
http://www-03.ibm.com/systems/x/hardware/enterprise/x3850x5/index.html
http://www-03.ibm.com/systems/bladecenter/hardware/chassis/bladeh/index.html
http://www-900.ibm.com/storage/cn/disk/ds4000/ds4800/TSD01054USEN.pdf
http://www-947.ibm.com/support/entry/portal/docdisplay?lndocid=MIGR-59552&brandind=5000028
http://www-03.ibm.com/systems/storage/disk/ds4000/exp810/

Comments:

If IBM claims the POWER7 cpu is faster, then IBM must compare cpu vs cpu. Not core vs core. IBM can not compare core vs core, and then conclude one CPU to be faster. Maybe one cpu uses 1.000 slow cores, then that cpu will surely be faster than a cpu with few fast cores. IBM is just twisting the truth when IBM says "one POWER core is faster, which means the cpu must be faster".

This shows in IBM benchmarks. IBM compare 32 POWER6 cores vs 32 Niagara cores and concludes it is a fair comparison which shows that POWER6 is faster than Niagara. It turns out that IBM compares 16 POWER6 dual core cpus, vs 4 eight core Niagara cpus. Hardly fair comparison to compare 16 cpus vs 4 cpus, heh?

Posted by kebabbert on September 21, 2010 at 12:09 AM PDT #

You don't get it. This is system to system.

The smallest IBM Power7 system you can buy is with ONE socket for Power7, this IBM has has 4 of them.
The smallest Oracle SPARC T3 system you can buy is with ONE socket for SPARC T3, this Oracle system has 4 of them.

#cores, #threads, #caches, #buffers, #transistors is irrelevant (only an implementation detail).

That is like saying your car is faster because you LOST the race but you only used 4 cylinder engine, and I used an 8 cylinder engine. YOU LOST.

Posted by system on September 21, 2010 at 01:20 AM PDT #

Interesting results. Throughput is fantastic but the max times for all response metrics are quite high in comparison to the other 12 entries currently in SPECjEnterprise (in the worst case, 300s for Oracle versus 2s for the mentioned IBM). Additionally, Oracle's average and 90% response is worse in most cases than IBM's. What caused the crazy high outliers and the general slower max percentiles, and how likely are they to occur on systems running less than full throttle and not uber-tweaked?

Posted by francisco on September 21, 2010 at 10:02 AM PDT #

@system

You dont seem to understand my post. I can explain again, but using simpler words so you can grasp the contents.

IBM claims the POWER7 is the faster and better cpu, then IBM has to compare cpu vs cpu. Not core vs core and then conclude the cpu is faster.

An analogy that makes it easier for you to understand: if I claim my car is faster than yours, then I can not talk about a minor part in the engine that is moving faster, and then conclude the entire car is faster. That is fail logic.

Did you understand know? Or should I try to explain again?

PS. Next year, T3 Niagara will get a new upgraded beefier core which has out-of-order execution, etc etc etc. This will result in thread performance being 3-5x faster than these T3 cores. The new T3 will be pin compatible so you just drop in the new cpus into these T3 servers. Those cpus will kill everything IBM can throw at it. :oP

Posted by kebabbert on September 21, 2010 at 11:52 AM PDT #

Dear sirs just ask yourselves a question.

Why Oracle processor metric for power6 and 7 equals 1 and Sparc processor equals 0.5

Posted by wsm on September 24, 2010 at 06:55 AM PDT #

@kebabbert

I am not sure why you consider throughput per CPU an important metric. Clearly IBM could glue together 2 Power7 CPUs to produce a faster CPU; but this wouldn't have any effect on the more important metrics: throughput per watt and throughput per dollar (or throughput per rack as mentioned in this article). On the other hand throughput per core is meaningful in some cases. Firstly some tasks aren't easily parallelizable, and throughput per core might give you an idea about how long it will take for those tasks to complete. Secondly, mainframes often run software that has a huge licensing cost per core and in such cases you can save money by having fewer but faster cores.

Posted by John on September 28, 2010 at 01:32 AM PDT #

Cores, CPU, But then there is the old I/O

And the encryption to boot.... again for free......

For me the difference is the System on a CHIP, a huge development cycle for the very nice internal Xbar for all that I/O.... I mean, if we put 128 Virtual machines on the chip, then low and behold it works......

And now thats a lot of I/O

I have to say, I see reports that tell me for maximum performance to turn my core on Intel OFF, doing so increase the Clocking speed of the remaining cores... Errrrrr...!!

Thanks Sun/Oracle for really understanding this.

Posted by Chris Parker on September 29, 2010 at 06:32 AM PDT #

Post a Comment:
Comments are closed for this entry.
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
« April 2014
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
29
30
   
       
Today