Skip to Content

Indeed performance issues are always there.

And we need to fix them all.

Even if SAP did its best to improve performance on PI 7.1x, my opinion (and my recent experience I’m gonna describe here shortly) is that PI is quite architetcurally heavy, mainly because of two stacks bouncing a single message so many times – within a common message lifetime… See this old creature of mine to get an idea The specified item was not found. of what I am talking about. 

And this is especially true when PI gets compared to other middleware products, e.g. WebMethods – do you remember Business Connector? Yes, you’re right. This tiny thing basically all lives and runs inside a single JVM… No double stack, sometimes even no DB (persitence) at all.

But don’t get me wrong: on the other hand SAP PI provides a robustness that other products simply do not or cannot: “heaviness” is the price we pay for the product (and our implementations around it) to be rock solid. Usually it’s a just a matter of finding the right trade off between performance and redundancy, isn’t it? 

Wanna go faster, mate? Then read on.


In a recent PoC I’ve led, the prospective customer asked us to show how fast PI could be in handling hundreds of simultaneous synchronous calls (JMS A/S bridge using AFW modules to RFC).

The first result was awful: WebMethods took 10 secs to handle 100 calls, vs PI taking 60 secs for the same number (and doing exactly the same usual things: basically some simple content conversion and mapping plus RFC and JMS adapter job).

Then I came to realize a couple of things:

(1) the A/S bridge module in the JMS adapter is making the channel act as a singleton, because the java thread is stuck waiting for the response message; so no parallelism at all was performed (this may be achieved adding other server nodes but this was not our case since we had no other machine resources available on that PoC-machine (recent AIX 4CPUs 8Gb RAM with recent Oracle))

(2) even after switching completely off message tracing on the abap stack and audit log on the j2ee stack, still there was a slight improvement (2-3 secs… which means 100 calls took 57 secs instead of 60).


So given point (1) we tried simulating multiple nodes, by simply duplicating business systems, channels and configuration objetcs and having them “listening” on the same JMS queue.
Best result with 4 parallel channels: 18 secs for 100 calls. Still bad compared to the WebMethods result, obtained on a dev machine (half sized if compared to our PI box!)
Adding more channels over 4 didn’t help (tried up to 8).

Another important fact: increasing simultaneous call number (200, 300, 400, ect) was dramatically degrading performance on SAP PI (200 calls didn’t take 60 secs x 2, but more, that is about 150 secs) while Web Methods had a linear behaviour (or even getting better from time to time).

And finally, given point (2), and remembering the good old nights of 5 years ago spent decompliling when I was coding the module to get mapping running in the A.E. (my blog above), I came accross new 7.11 features like INTEGRATED CONFIGURATION.
Wow, just too cool.
I switched my whole Config Scenario to this new object and I got impressive results: one single channel took only 20 secs to handle 100 calls, with linear behaviour. With 4 parallel channels (also in this case more than 4 didn’t help) I came to get better results than WebMethods, that is below 10 secs, and the same better result was kept with 300 simultaneous calls (around 15 secs!!).

Veni, vidi, vici.

Lesson learned

You get best performance when PI handles the whole thing in one stack only, J2EE in this case, thanks to this new wonderful object called Integrated Configuration.

Cons: you lose a bit in terms of monitoring and features (e.g. mappings in Integrated Configuration can’t have parameters, which is really useful feature indeed), but that’s basically it.

And if performance is what you need, well, boost yourself with this speedy approach!

No doubt you (and your customer) will sit back and enjoy speed.

To report this post you need to login first.


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

  1. Former Member
    As always, a great and useful blog mate!

    just a pair of question…ic is working only with an aae? is not possible make it working with an ‘old’ 7.0 through ae? is only a 7.1 feature?


    1. Former Member Post author
      Ciao Paolo,
      Thanks for your comment.
      I’m not aware of IC and AAE in 7.0 – I also tried to give a quick look at 7.0 EhP 1 and 2 for new features but couldn’t find anything related to PI.
      You can anyway use my “hackerous” Mapping Module to speed up things a bit… ๐Ÿ˜‰


    1. Former Member Post author
      Hi Prateek,
      Appreciate that. It actuaolly took me a while to gather the strength to come back blogging ๐Ÿ˜‰


  2. Former Member
    It’s wonderful to read again blogs marked with the big G (and I’m referring to the G that counts for us), as they are always doubtless inspiring!

    A very hot theme and another weapon in our swiss cutter..

    Great job!

  3. Former Member
    Hello Alessandro,

    you pointed out the issues about the 2-stack architecture pretty well, actually no surprise to me as i have the same experience.
    The double stack is since years the major pain point in performance competing with other EAI/ESB platforms.
    Its good to have the AAE, its great for simple scenarios to boost performance.
    However i still miss the flexibility you have from all PI features inside the double stack.

    In my opinion, it should be all inside the java stack like you said to win the match, would make a lot of things easier.

    Hopefully it ll change with 7.3 or further on ๐Ÿ˜‰

    Best wishes

    1. Former Member Post author
      I do believe the path SAP is following (in regard to new features like AEE & Co.) is pointing in the right direction.
      We just have to trust them a bit, while thinking out of the box as much as possibile in the meantime. ๐Ÿ˜‰


  4. Former Member
    Hi Guarneri,

    Thanks for sharing this bolg. I am pleased with new AAE and its performance. We are doing exactly the same scenario JMS A/S bridge and RFC integration with JMS RequestResponseBean. We did initially with regular scenario which was functionally working fine but slow so for performance reasons we changed to Inegrated scenario then we got the huge performace boost but the problem is we are loosing the Correlation between the Request and Response Message, I mean we are mapping MessageID to CorrelationID in the Sender Comm Channel and then mapping ConversationID to JMS CorrelationID in the Receiver Comm Channel. Now the same configuration works fine with regular scenario that we are able to map Request JMS MessageID as correlation ID in the Response JMS mesasge. But in Integrated Sceario Response JMS CorrelationID contains response MessageID of PI not the Orginal JMS ID.

    Did you across this problem? if can share how you did you get around this problem?


    1. Former Member Post author
      You’re right. In fact it doesn’t work. I was compelled to do a work aorund.
      Please do open a support request! And let me know what SAP says.



Leave a Reply