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.
14 Comments
