Java Performance

The SPECjbb 2015 benchmark has "a usage model based on a world-wide supermarket company with an IT infrastructure that handles a mix of point-of-sale requests, online purchases, and data-mining operations." It uses the latest Java 7 features and makes use of XML, compressed communication, and messaging with security.

We tested SPECjbb with four groups of transaction injectors and backends. The reason why we use the "Multi JVM" test is that it is more realistic: multiple VMs on a server is a very common practice. 

The Java version was OpenJDK 1.8.0_131. We applied relatively basic tuning to mimic real-world use, while aiming to fit everything inside a server with 128 GB of RAM:

"-server -Xmx24G -Xms24G -Xmn16G -XX:+AlwaysPreTouch -XX:+UseLargePagesIndividualAllocation

The graph below shows the maximum throughput numbers for our MultiJVM SPECJbb test.

SPECJBB 2015-Multi Max-jOPS

Even though our testing is not the ideal case for AMD (you would probably choose 8 or even 16 back-ends), the EPYC edges out the Xeon 8176. Using 8 JVMs increases the gap from 1% to 4-5%. 

The Critical-jOPS metric is a throughput metric under response time constraint.

SPECJBB 2015-Multi Critical-jOPS

With this number of threads active, you can get much higher Critical-jOps by significantly increasing the RAM per JVM. However, we did not want that as this would mean we can not compare with systems that can only accommodate 128 GB of RAM. 

Database Performance: MySQL Percona Server 5.7.0 Big Data benchmarking
POST A COMMENT

219 Comments

View All Comments

  • TheOriginalTyan - Tuesday, July 11, 2017 - link

    Another nicely written article. This is going to be a very interesting next couple of months. Reply
  • coder543 - Tuesday, July 11, 2017 - link

    I'm curious about the database benchmarks. It sounds like the database is tiny enough to fit into L3? That seems like a... poor benchmark. Real world databases are gigabytes _at best_, and AMD's higher DRAM bandwidth would likely play to their favor in that scenario. It would be interesting to see different sizes of transactional databases tested, as well as some NoSQL databases. Reply
  • psychobriggsy - Tuesday, July 11, 2017 - link

    I wrote stuff about the active part of a larger database, but someone's put a terrible spam blocker on the comments system.

    Regardless, if you're buying 64C systems to run a DB on, you likely will have a dataset larger than L3, likely using a lot of the actual RAM in the system.
    Reply
  • roybotnik - Wednesday, July 12, 2017 - link

    Yea... we use about 120GB of RAM on the production DB that runs our primary user-facing app. The benchmark here is useless. Reply
  • haplo602 - Thursday, July 13, 2017 - link

    I do hope they elaborate on the DB benchmarks a bit more or do a separate article on it. Since this is a CPU article, I can see the point of using a small DB to fit into the cache, however that is useless as an actual DB test. It's more an int/IO test.

    I'd love to see a larger DB tested that can fit into the DRAM but is larger than available caches (32GB maybe ?).
    Reply
  • ddriver - Tuesday, July 11, 2017 - link

    We don't care about real world workloads here. We care about making intel look good. Well... at this point it is pretty much damage control. So let's lie to people that intel is at least better in one thing.

    Let me guess, the databse size was carefully chosen to NOT fit in a ryzen module's cache, but small enough to fit in intel's monolithic die cache?

    Brought to you by the self proclaimed "Most Trusted in Tech Since 1997" LOL
    Reply
  • Ian Cutress - Tuesday, July 11, 2017 - link

    I'm getting tweets saying this is a severely pro AMD piece. You are saying it's anti-AMD. ¯\_(ツ)_/¯ Reply
  • ddriver - Tuesday, July 11, 2017 - link

    Well, it is hard to please intel fanboys regardless of how much bias you give intel, considering the numbers.

    I did not see you deny my guess on the database size, so presumably it is correct then?
    Reply
  • ddriver - Tuesday, July 11, 2017 - link

    In the multicore 464.h264ref test we have 2670 vs 2680 for the xeon and epyc respectively. Considering that the epyc score is mathematically higher, howdoes it yield a negative zero?

    Granted, the difference is a mere 0.3% advantage for epyc, but it is still a positive number.
    Reply
  • Headley - Friday, July 14, 2017 - link

    I thought the exact same thing Reply

Log in

Don't have an account? Sign up now