Performance in BRFplus Surprise, Surprise!
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:
- First call versus delta per call
- Code generation versus interpretation
- Call via ABAP OO interface versus static method versus RFC-enabled function module versus web service
- Call of BRFplus function versus select on database (buffered and not buffered)
- 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.
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:
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.