Skip to Content

You may already be aware that Java 7 has been released and has a number of improvements over Java 6.  If not, you can get the full story here or a couple of the biggest highlights from a BI Platform perspective on Idea Place.  We’ll discuss the “garbage first collector” mentioned in Idea Place specifically in this post. 

Based on the popularity of this idea, and from general feedback from our customers and partners, SAP is currently targeting Java 7 support for Tomcat in a patch for BI 4 SP04.  While this is a product future and the release schedule is subject to change, it represents a major move forward and should be cause for a lot of excitement.  In this post I hope to convince you that there is significant value in preparing for Java 7 early if you run Tomcat 6 or 7 in order to move as quickly as possible when support is formally announced.

In order to do this, I came up with a few performance tests targeted at some of the exciting new features available in the BI 4 Feature Pack 3 release, namely the use of Exploration Views in the SAP BusinessObjects Explorer product.  An Exploration View is a saved exploration on an information space that can be used to expose and explore a specific part of the data on the information space.  Since this feature is expected to make a big splash with customers and in the Ecosystem, I decided to build one and see how Tomcat responded when hammered with a few hundred requests for this content.

I set up a test environment with the following specifications:

  • 1 Windows 2008 R2 machine hosting the BIP 4.0 SP04 Server stack (CMS, FRS, Web Intelligence, etc) – 4 CPU/16 GB RAM
  • 1 Windows 2008 R2 machine hosting the default BIP 4.0 SP04 Web Tier (Tomcat 6 + Java 6.0.24) and Explorer 4.0 SP04 servers – 4 CPU/8 GB RAM
  • 1 Windows 2008 R2 machine hosting the BIP 4.0 SP04 Web Tier (Tomcat 7 + Java 7.0.4) and Explorer 4.0 SP04 servers – 4 CPU/8 GB RAM
  • 1 Windows 2008 R2 machine hosting Apache JMeter 2.7 to execute the performance test

The 2 Web Tier machines were built to be exact replicas of one another … the only difference being the version of Tomcat and the JDK that was in use.  By using this configuration, I was able to execute a performance test against each machine, using the same BIP server tier, and measure the performance of each Tomcat+Java configuration.  I’ll share the very interesting results of these tests in just a few minutes.

Background

First, let me explain the performance test itself and the characteristics of my Exploration View.  I recorded a test plan using the HTTP Proxy feature of JMeter that performed the following operations:

  1. Login to BI Launchpad
  2. Launch Explorer
  3. Navigate to Exploration View sets
  4. Open an Exploration View
  5. Logoff

The Exploration View is based on technical support data for some fictional customers that I used SAP Business Objects Data Services 4.1 and Sybase IQ 15.3 to generate.  The characteristics are as follows:

  • 5 charts
  • 5000 rows in each chart
  • 1 facet and 1 measure in each chart

The resulting Exploration View looks like this:

Exploration View Set.png

Test Execution

I then ran my JMeter test plan against the Tomcat 6/Java 6 and Tomcat 7/Java 7 environments to compare the performance of each.  It is important to note that Tomcat 6 and Tomcat 7 performed almost identically when they both used Java 6 for the JVM.  Java 7 is the real game-changer here, as I am about to demonstrate!

In order to take advantage of the new garbage first (GC1) collector in Java 7, we have to add at least one java option to the Tomcat startup script.  On Windows, this can be done from the ‘Java’ tab in the Tomcat Configuration application.  You can find an exhaustive list of the possible options for Java HotSpot VM usage here.  Since my goal is to demonstrate the potential benefits from using Java 7, and not to write a detailed document on tuning garbage collection, I am only going to enable the GC1 collector by adding -XX:+UseG1GC to my Tomcat parameters.

 

The JMeter test plan was configured to emulate 50 distinct users, with a ramp-up period of 60 seconds, looping 5 times.  This results in a total of 250 test plan executions, generating consistent load on the server for the entire duration of the test.  I won’t cover the configuration of the test here, but if there is interest I can do so in a subsequent post.

Results Analysis

Side by Side Summary Reports.png

Review of the Summary Reports for each test show the following details (click on the image above to see the numbers better):

  • Using Java 6 an average transaction took ~29 seconds to complete
  • Using Java 7 an average transaction took ~18 seconds to complete
  • The standard deviation of a transaction was 40% less with Java 7, indicating a much more consistent experience
  • The lengthiest transaction in both tests was launching Explorer and downloading the sizable demo videos that come with the product

I used JConsole to retrieve CPU and Memory statistics from the Tomcat JVM to determine why Java 7 results in better overall performance:

Side by Side JConsole Summary.png

What we see for both CPU and Memory consumption is that the older JVM has many more peaks and valleys, resulting in a wider range of response times.  Compare high water marks for memory usage of over 700 MB for Java 6, compared with just over 400 MB for Java 7.  The Java 7 environment does sustain slightly higher overall CPU usage, but does a better job of keeping performance at a consistent level.

In summary, Java 7 brings much to be excited about, not least of all the proposition of a better experience for BI users and administrators alike.  While this is only a test, and not a guarantee of improved performance in your environment, it is my intent to test more of the features present in Java 7 in hopes of convincing you all that it is an upgrade well worth pursuing.

To report this post you need to login first.

17 Comments

You must be Logged on to comment or reply to a post.

  1. Patrick Bulteel

    Great post – doing this and then splitting the content into a static and dynamic content will show some great performance improvements for a much smoother user experience.

    (0) 
  2. Greg Myers

    Jim,

    In light of this really nice performance boost, I’d really be interested to see how this would look if you had the BI4 web tier split in an Apache/Tomcat configuration. We always recommend the Apache/Tomcat split to also boost performance.

    Great stuff! Thanks for sharing!

    (0) 
    1. James Rapp Post author

      Hi James,

      We are currently working with the SAPJVM and BI Platform teams in hopes of getting it for BI 4.2.  It would be helpful to have the request logged on Idea Place so we can track the request formally.  Development has indicated that customers clamoring for SAPJVM 7 with good business cases will help our case.

      So, keep in mind this is a product future and not guaranteed, but I am hopeful we will see SAPJVM 7 in BI 4.2.

      (0) 
        1. Patrick Bulteel

          Hi Mikhail,

          I believe that from now on we are not going to be bundling any Oracle version of the JVM. We will be providing SAPJVM for everything. This is mainly because SAP supports it’s own JVM and we can therefore provide overall better support in case of EOL, etc.

          That however does not stop you from implementing the Oracle JVM on Tomcat.

          Patrick

          (0) 
  3. Chris Bethune

    Gentlemen from SAP,

    A couple of questions:

    1.  I was reading this as well Jim’s deck from ASUG 2013 that discusses different types of Java GC.  In particular I noted the comment ”  For response time critical applications we recommend you use the concurrent mark sweep collector, and for throughput driven

    applications we recommend the parallel old generation collector.”  Could one you ellaborate on “concurrent mark sweep collector” a bit and what you define as a response time time critical application in the context of BIP4.1?  If I understand the two correctly I would envision a process handing rendering of a display would benefit from the concurrent mark sweep collector and an APS would be throughput driven since we’re probably dealing with volume of data here but I wanted to validate that if I could.

    2.  If one were to update to SAPJVM 7 on their own would this invalidate you for support?  I have done this in a sandbox and and fairly impressed with the differences in performance.  I would love to recommend this to my customers with professional assistance in implementing it but I also don’t want to create issues for them should they need to file a support incident.

    (0) 
    1. James Rapp Post author

      Hey Chris,

      My perspective:

      1. I didn’t find either of these settings to have an impact in my performance tests on 4.1. Response time driven would be like viewing a report, and throughput driven would be more appropriate for transactional systems running java processes. I’m not sure if the APS is running SAPJVM 7 yet (probably not) but the Garbage First (GC1) collector would probably show some improvement as it is fully modernized.

      2. I was dismayed to find that SAPJVM 7 wasn’t on the Supported Platforms document yet for BI 4.1 SP05. I spoke to Zach Hulbert and Ian Treleaven about extending support last year, but in my limited testing I didn’t notice an appreciable difference in performance. If you’re seeing something different, feel free to email me directly with the results and we can look into testing again. I believe the target we discussed was BI 4.2 but my memory is a bit fuzzy on the specifics.

      Unfortunately, the letter of the law would probably be unsupported. I can’t imagine a problem you would face with the SAPJVM that wouldn’t be there with the Oracle version, but I believe support would push back on the configuration when they come across it.

      (0) 
  4. Ramprasun Sribhasyam

    Hi James,

    Appreciate your insightful articles and pointers for the avenues to improve performance.

    Just want to clarify – in the reply to Chris Bethune (Jan 19, 2015 8:13 PM), to the second question, a comment was made “I didn’t notice an appreciable difference in performance”.

    Does that mean SAP JVM7 do not have any advantages in terms of performance over SAP JVM6? I thought this article concluded some gains with JVM7 – Does something changed?

    We are in the process of upgrading to XI4.1SP5 from XI3.1SP7. It seems SAP JVM is still not at 1.7 in XI4.1. Is it worth going for 1.7?

    Not to use bundled Tomcat7, but install JDK7 and Tomcat7 separate from BOE install is only way to use JVM7, without breaking support?

    Thanks in advance for your time!

    (0) 

Leave a Reply