Skip to Content

The latest version of BRFplus is shipped with NetWeaver 7.0 Enhancement Package 2. Many customers have already contacted me for ramp-up participation which makes me happy as it shows that we are going into the right direction. At the beginning of a project, questions dealing with performance and sizing are often raised. Therefore, I asked Hans Beuter from my team to help me write a paper on that topic.

When we started to write the paper, we expected that the performance would be good because of the built-in code generation capabilities. But we never conducted any tests on customer-like systems, and we never had a system exclusively for tests. As a consequence, our previous tests were not free of external influence and results were not reproducible.

So we first set up a system for a series of new tests:

  • 4 CPUs AMD Opteron 852 
  • 16 Gigabyte RAM
  • SUSE Linux Enterprise Server 10 SP2 (x86_64)
  • MaxDB 7.7.04.032
  • SAP NetWeaver 7.0 Enhancement Package 2 SP4

This may not look impressive, but this equipment was good enough for us to perform the tests.

The next step was the creation of a little price calculation example that contains the most important BRFplus concepts, but is still simple to understand. Our example included the following artifacts: Function, Data Objects, Ruleset, Rules, Decision Tables, and Formulas.

Then we started with the measurements:

  1. First call versus delta per call
  2. Code generation versus interpretation
  3. Call via ABAP OO interface versus static method versus RFC-enabled function module versus web service
  4. Call of BRFplus function versus select on database (buffered and not buffered)
  5. Call with and without trace

I do not want to replicate in this blog what is written in the paper. Therefore I just use one diagram that came as the biggest surprise to us. We did compare the BRFplus delta runtime against a database SELECT SINGLE statement on table T100 (ABAP message table) which is a fully buffered table.

BRFplus Performance

Our tests showed that a delta call to BRFplus took about 50 microseconds whereas a single select from T100 with loaded buffers needed about 70 microseconds. Unbuffered selects are of course far slower and can be compared with initial BRFplus calls that also take more time because of the need to bring the class into the ABAP load (session memory).

This means that BRFplus is a good alternative for view clusters:

  • better performance
  • more flexibility
  • ability to combine local, customizing, and system data
  • many additional features

Please find all the measurements and much more information in our paper about BRFplus performance and sizing

 

To report this post you need to login first.

2 Comments

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

  1. Brandis Omer
    dear Carsten

    i fear i have located a small inconsistency in the document ( or i have misunderstood the information)..

    but on page 18 you wrote that a static method call took 0.78 milisecods,

    and on page 19 , you wrote 0.048 miliseconds.

    there is a 1625% difference between the two results????

    (0) 
    1. Carsten Ziegler Post author
      On page 18 the table shows 0.78 milliseconds for the first call. The first call includes load time (find class and load it into abap memory). This load time is only necessary for the first call. Consequently, the runtime per call for 10000 calls is about 0.048 milliseconds as shown in the same table (total runtime of 484 milliseconds for all 10000 calls).

      On page 19/20 the deltas are shown. Each additional call will take only 0.048 milliseconds.

      (0) 

Leave a Reply