Skip to Content

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).

To report this post you need to login first.

9 Comments

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

  1. Aamir Suhail
    Thanx Naveen for the excellant blog,just a small question
    >>In PI7.1 SAP is introducing the notion of Direct Connection between the adapters that would remove the need of going through IS
    does this mean that we will be able to bypass the pipeline steps?
    Thanx
    Ahmad
    (0) 
    1. Anonymous
      Hello Ahmad,

      As per the new AAE (adavance adapter engince), most of the operations carried by IS can now be done in the adapter like message mapping. Currently there is no support of BPM or content based routing.

      So in short yes we can by pass pipeline steps.

      Cheers,
      Naveen

      (0) 
      1. Goradindla Sreerama Reddy
        Hi Naveen,

        Good blog,a simple clarification on content based routing “This is a very useful feature 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.”

        you have removed the content based routing which saw the perfomance improvement but as routing logic is removed from XI is this logic been handled in sender or receiver side or routing functionality is total removed from this interface

        Thanks
        Sreeram.G.Reddy

        (0) 
        1. Anonymous
          Hello Sreeram,

          We handled the routing based on the sender business service by doing appropiate receiver determination accordingly.

          Cheers,
          Naveen

          (0) 
          1. Goradindla Sreerama Reddy
            Hi Naveen

            Thanks for quick response. so you have used mutiple sender service and for each one you have reciver determination

            Unless we use nosoapuserid and pwd in url it will keep on asking userid and pwd everytime we trigger this interface.
            I could not understand this solution
            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.

            Thanks in advance

            Regards
            Sreeram.G.Reddy

            (0) 
  2. Bhavesh Kantilal
    Naveen,
    All I can say is THANKS!
    Its good to see you come back to XI Blogging and thanks for doing that with a Bang.

    PI 7.1 promises so many things, but I wonder how easy these things are going to be from an Implementation perspective.
    Too many features being added to the huge list of already existing options which can be a double edged sword as you never know when to use what. I do hope that SAP plans to provide documentation that will help us Consultants make a wise decision when we need to decide on the best approach.

    Looking forward to more blogs from you.

    Regards
    Bhavesh

    (0) 
    1. Anonymous
      Hello Bhavesh,

      What we are seeing is natural evolution of XI. Most of the vendors of integration hub provide almost have the same functionality. In fact having many options gives you an opportunity to use features at your discretion.

      Cheers,
      Naveen

      (0) 
  3. Sebastian Simon
    Hello Naveen!

    Excellent article, very much on point!
    I pretty mich faced the same problems and also, avoiding x-path content routing and using the integration engine as entry point gave  us “feelable” better results.
    The problem with content routing is it uses  a very slow implementation of ccBPM inside, i hope SAP might change this in future as it is an important feature.

    Cheers
            Sebastian

    (0) 
  4. Satish Reddy
    Naveen,

    As usual your blogs are very helpful to the SDN community. Good to see a blog from you after a long time. Expecting few more weblogs from you.

    Regards,
    —Satish

    (0) 

Leave a Reply