Additional Blogs by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member
0 Kudos

Scenario : Have you ever wondered why inspite of adding all kind of hard ware sychronous webservices calls to XI take long time to execute? On average we have observed that a webservice call to XI will take about one sec to execute. Now this time is very low given the list of laundry work XI has to do internally from the call being handled by the dispatcher to the integration server and then to the recieving system by adapter engine. There are many more steps that need to be done before the response is sent to the client. Now ONE SEC for all these activites sounds very reasonalble. But in todays world of highly interactive web applications that are based on the eSOA paradigm that are built on enterprise services, this performance time is not acceptable.





 


Problem :  Rich internet applications require to make many calls to enterprise services before rendering the page to the users. If the webservices take a lot of time then the whole UI process for the user being very long and very soon users will be mad at the performance. Now having said all this if XI were providing these webservices it is often observed that XI adds about a second for all its laundry activites. So if the backend takes .5 secs to process the request, XI adds one sec to it. Hence the call will be returned in 1.5secs. As most of the companies transittion from a one of webservices in .net or java to more enterprise oriented services developed in XI, they will be hindered with the response times. PI in its current state cannot match the esponse times obtained by calling a webservices directly, that is hosted on a webserver. But there are means to closen the gap of performance by few milli seconds.       





SAP has many  published documents that talk about adding hardware and changing the system parameters for beefing up the performance. We have noticed that after doing all the recomendations, PI would still take about 1sec (start to end). In this blog i have listed some of the things that we did to bringing down the over all response time to around 375-420 milli seconds.



 



*1. Content Routing: *This is a very useful feature where we can switch the receiver based on the contents of the payload. Unfortunately we learned in the hard way that content routing takes up a lot of time for sniffing the payload for the specified condition. On removing content routing based logic, we saw the preformance time reduced by around 300ms.



 


*2. HTTP web request Preauthenticate: *XI webservices that need basic authentication required the credentials to be passed when the call is made to the webservice. But by the implementationof the HTTP protocol, these credentials are only sent when the client gets a 401 unauthorized error from the server. Subsequently the client sends the credentials for the following calls. This initial handshake takes up about  120ms. Based on the language that the client is implemented in there are parameters available to force the client to send the crententials by default. In .net this property is referred to as preauthenticate.





 


3. Sender SOAP communication channel: Posting direclty to Intergration server versus going through the adapter engine by using sender soap communication channel reduces the over all call response time. Since webservices need no sender aggrement or sender communication channel by posting directly to IS we can get better response time.[http://<INTERFACE> | http://<server>:<port>/sap/xi/engine?type=entry&version=3.0&Sender.Party=http://sap.com/xi/XI/XIParty/<PARTY>&Sender.Service=<SERVICE>&Interface=<NAMESPACE>

*4. TCP implementation problems between Unix and Windows: During our research we found out that when communicating between unix and windows there was a substantional delay in the packets acknowledgement from windows. We found out that windows by default does a delayed acknowledgement to tcp packets and unix expects acknowledges to every packet. Due to this disparity of implementation by windows we were seeing around 200ms lost waiting for acknowledgements. On MSDN we found notes that address this particular bug in the implementation on windows. Microsoft has hence acknowledged the bug and has released sp to fix the bug.  *






328890 : New registry entry for controlling the TCP Acknowledgment (ACK) behavior in Windows XP and in Windows Server 2003



815230 : Changing the TcpAckFrequency value to 1 does not have any effect







 



+Over all by implementing the above finding we brought down the average performance time of XI webservice from around 1.5secs to around 400ms of which XI processing time is only about 300ms. Following are the times that we were able save.+




*
























 TCP disparity

  150ms

 HTTP Preauthenticate

  120ms

 Sender soap channel

  135ms

 Content based routing

  300ms

  Total time saved*

   705ms







 


Conclusion:  In a sports car that needs to race on a track, everything that is not needed is kicked off to gain performance. The motive is to win the race. Simillarly PI has many features that a very useful but for the sake of performance and to cater user needs one has to sacrifice the neat features. Options mentioned in this blog are some of the ways to squence in more performance.





 



*What is SAP doing about this?? *SAP has long maintained that PI is designed more for asychronous webservices than sychronous services. But with the adaption of eSOA many customers are now using PI as the central hub for monitoring and governing all the enterprise services using PI. SAP is aware of the performance issues and is working very hard based on the customer feedbacks to improve performance. In PI7.1 SAP is introducing the notion of Direct Connection between the adapters that would remove the need of going through IS. This advanced adapter has 4X performance to its peer and this new design approach has been bench marked of having great performance times (~300ms).

9 Comments