bildwelt
E2E FORUM
E2E Bridge E2E Commerce

performance metrics

E2E Forum General Discussion performance metrics

This topic contains 2 replies, has 2 voices, and was last updated by  Paul B. Cahill 3 years, 9 months ago.

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • #784

    Paul B. Cahill
    Participant

    Are there any metrics regarding the efficiency of the E2E server to gauge throughput of the server?

    Does Marcel has any benchmarks for the server that he can spare and share this may satisfy his questions. I realise that the throughput is probably dependant on the kind of activities employed however there must be some tests performed that mock’s out the end points and therefore runs without a load. This would employ the UML VM only and give some measure to the basic efficiency of the server.

    #789

    Marcel R.
    Blocked

    Hi Paul,

    unfortunately I cannot provide you with a standardized performance tests. The latency of Bridge services depends very much on the used Bridge components and is typically limited by calls to external systems because the Bridge is typically used for integration projects and not number crunching. However, we went to great lengths to scale integration use cases linearly. This is a very important feature because it allows you to keep your latency low for increasing load by scaling up hardware – either more CPU power or more nodes. For example, Oracle tested this behavior explicitly when we did our Oracle middle ware certification (see table below).

    Another performance bottle neck might be persistent state objects when using external databases as storage. Attached you find some tests we did for this use case. More about persistent state performance can also be found here.

     

     

    Memory & Latency Scaling Tests Oracle/SAP Communication

    Test StepsTest Description/ProcessBehavior
    Data ScalingLoad will be produced from SAP using SAP test tool (WE19). Use of scenario BPEL_SAP_Inbound – IDOC.

    1. 10 IDOCS
    2. 20 IDOCS
    3. 50 IDOCS
    4. 100 IDOCS
    5. 200 IDOCS
    System stays stable, no loss of data.

     

    Latency and memory scale linearly.

    Runtime Scaling:

    Test for the Heavy Load from BPEL to SAP bridge

    Load will be produced from BPEL using scenarios

    • BPEL_SAP_Outbound – BAPI
    • BPEL_SAP_Outbound – IDOC

     

    1. BPEL_SAP_Outbound – BAPI
      1. Conc. Threads 1, Loops 10, Delay ms 1000
      2. Conc. Threads 2, Loops 10, Delay ms 1000
      3. Conc. Threads 1, Loops 20, Delay ms 500
      4. Conc. Threads 2, Loops 20, Delay ms 500
      5. Conc. Threads 5, Loops 20, Delay ms 500
      6. Conc. Threads 10, Loops 50, Delay ms 500
      7. BPEL_SAP_Outbound – IDOC
        1. Conc. Threads 1, Loops 10, Delay ms 1000
        2. Conc. Threads 2, Loops 10, Delay ms 1000
        3. Conc. Threads 1, Loops 20, Delay ms 500
        4. Conc. Threads 2, Loops 20, Delay ms 500
        5. Conc. Threads 5, Loops 20, Delay ms 500
        6. Conc. Threads 10, Loops 50, Delay ms 500
    System stays stable, no loss of data.

     

    Memory scales linearly.

    The tests run on a one processor PC with 4GB memory.

    #792

    Paul B. Cahill
    Participant

    Hi Marcel,

    Thanks again for these figures. As you pointed out, I assumed the external interfaces would be the limiting factor and as the bridge is driven by the meta data it should perform fairly linearly. Another limit would be the complexity of the Action script manipulation which will vary depending on the circumstances. Is this correct?

    It looks like the internal persistence module zips along very nicely compared with the external database versions. Are there any significant disadvantages with the internal version compared the the external database versions?

    Regards,

    Paul

Viewing 3 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.