APIv2 Conversation Factory Benchmarks.
Contents
Overview
Benchmark methodology
Scenario A
Scenario B
Test Run 1 - Using openConversationByCorporateID
Test Run 2 - Using 'slow open' from factory no longer applicable since Proxy-30
Test Run 3 - Using 'fast open' from factory default option since Proxy 30
Comparison of results
Interpretation of the results
Conclusion
Overview
The purpose of the following benchmarks are to highlight the performance benefits of using the Conversation Factory for managing conversations with the APIv2.
The Conversation Factory was introduced into the APIv2 Proxy back in 2001 and since then has become the recommended technique for managing conversations in multi-user, multi-threaded client applications.
The benchmarks below describe a set of tests where the user functionality remains constant but the functions used for opening and closing the conversations with the Amadeus Central System vary.
Benchmark methodology
Three separate test runs were executed. Each test run consisted of two different functional scenarios executing in parallel in two separate threads.
In terms of functionality, each test run is identical. The only varying factor is the function used to open and close conversations with the APIv2.
Scenario A
Scenario A consists of the following steps repeated 100 times:
- Open Conversation.
- Send and receive Query A1.
- Send and receive Query A2.
- Close Conversation.
Query A1 is an ‘Air Availability request for flights
between Paris and Nice on 25 Oct 2003 ‘:
<PoweredAir_MultiAvailability><messageActionDetails><functionDetails><businessFunction>01</businessFunction><actionCode>44</actionCode></functionDetails> </messageActionDetails><requestSection><availabilityProductInfo><availabilityDetails><departureDate>251003</departureDate></availabilityDetails><departureLocationInfo> <cityAirport>par</cityAirport></departureLocationInfo><arrivalLocationInfo><cityAirport>nce</cityAirport></arrivalLocationInfo></availabilityProductInfo> <availabilityOptions><productTypeDetails><typeOfRequest>TN</typeOfRequest></productTypeDetails></availabilityOptions></requestSection></PoweredAir_MultiAvailability>
Query A2 is a request to book one passenger on a
flight.
<PoweredPNR_AddMultiElements><pnrActions><optionCode>20</optionCode><optionCode>0</optionCode></pnrActions><travellerInfo><elementManagementPassenger>
<reference><qualifier>pr</qualifier><number>1</number></reference><segmentName>nm</segmentName></elementManagementPassenger><travellerInformation><traveller>
<surname>toto</surname></traveller><passenger><firstName>totjia</firstName><type>adt</type></passenger></travellerInformation></travellerInfo><originDestinationDetails>
<originDestination><origin>nce</origin><destination>lhr</destination></originDestination><itineraryInfo><elementManagementItinerary><segmentName>AIR</segmentName>
</elementManagementItinerary><airAuxItinerary><travelProduct><product><depDate>201003</depDate></product><boardpointDetail><cityCode>nce</cityCode>
</boardpointDetail><offpointDetail><cityCode>lhr</cityCode></offpointDetail><company><identification>ba</identification></company><productDetails>
<identification>0341</identification><classOfService>y</classOfService></productDetails></travelProduct><messageAction><business><function>1</function>
</business></messageAction><relatedProduct><quantity>1</quantity><status>nn</status></relatedProduct></airAuxItinerary></itineraryInfo></originDestinationDetails>
</PoweredPNR_AddMultiElements>
Scenario B
Scenario B consists of the following steps repeated 50 times:
- Open Conversation.
- Send and receive Query B1.
- Send and receive Query B2.
- Close Conversation.
Query B1 is an ‘Air Availability request for flights between Nice and Paris on 20 Oct 2003 ‘ <PoweredAir_MultiAvailability><messageActionDetails><functionDetails><businessFunction>01</businessFunction><actionCode>44</actionCode></functionDetails> </messageActionDetails><requestSection><availabilityProductInfo><availabilityDetails><departureDate>201003</departureDate></availabilityDetails><departureLocationInfo> <cityAirport>nce</cityAirport></departureLocationInfo><arrivalLocationInfo><cityAirport>par</cityAirport></arrivalLocationInfo></availabilityProductInfo> <availabilityOptions><productTypeDetails><typeOfRequest>TN</typeOfRequest></productTypeDetails></availabilityOptions></requestSection></PoweredAir_MultiAvailability>
Query B2 is an ‘Air Availability request for flights
between Paris and Nice on 25 Oct 2003 ‘ <PoweredAir_MultiAvailability><messageActionDetails><functionDetails><businessFunction>01</businessFunction><actionCode>44</actionCode></functionDetails>
</messageActionDetails><requestSection><availabilityProductInfo><availabilityDetails><departureDate>251003</departureDate></availabilityDetails><departureLocationInfo>
<cityAirport>par</cityAirport></departureLocationInfo><arrivalLocationInfo><cityAirport>nce</cityAirport></arrivalLocationInfo></availabilityProductInfo>
<availabilityOptions><productTypeDetails><typeOfRequest>TN</typeOfRequest></productTypeDetails></availabilityOptions></requestSection></PoweredAir_MultiAvailability>
For all test runs, the target system was Amadeus Production Practice Training June19th 2003.
Test Run 1 - Using openConversationByCorporateID
In this run, Conversations were opened using the function CAI_openConversationByCorporateId, and closed with CAI_closeConversation.
|
Transaction name |
Edifact message pair |
Amount |
% |
Mean |
Mean |
Mean (ms) |
amount |
Fast Opens |
|
Query length |
Reply length |
Response time |
* resp time |
|
||||
|
Command_CloseConv |
EDI:HSFREQ-HSFRES |
100 |
16.667 |
249 |
185 |
206 |
20600 |
0 |
|
Command_GetScreen |
EDI:HSFREQ-HSFRES |
100 |
16.667 |
284 |
643 |
318 |
31800 |
0 |
|
Default_OpenConvCid |
API internal authentication |
100 |
16.667 |
101 |
455 |
314 |
31400 |
0 |
|
PoweredAir_MultiAvailability |
EDI:SATRQT-SATRSP |
200 |
33.333 |
278 |
1950 |
152 |
30400 |
0 |
|
PoweredPNR_AddMultiElements |
EDI:PNRADD-PNRACC |
100 |
16.667 |
351 |
359 |
129 |
12900 |
0 |
|
|
|
|
|
|
|
|
|
|
|
TOTAL |
|
600 |
100 |
|
|
223.8 |
127100 |
0 |
Test Run 2 - Using 'slow open' from factory
No longer applicable: "Fast Open" is the default option since Proxy-30
In this run, a ConversationFactory is created first, and
then all Conversations opened using the function CAI_openConversationFromFactory
.
The parameter CAI_OpenType-> bind_host_resource is set to ‘true’ to ensure that a host resource or AAA is allocated at open time.
Conversations are closed using CAI_closeConversationFromFactory.
|
Transaction name |
Edifact message pair |
Amount |
% |
Mean |
Mean |
Mean (ms) |
amount |
Fast Opens |
|
Query length |
Reply length |
Response time |
* resp time |
|
||||
|
Command_CloseConvFromFactory |
EDI:HSFREQ-HSFRES |
100 |
19.96 |
250 |
185 |
224 |
22400 |
0 |
|
Command_GetAccessFSlow |
EDI:HSFREQ-HSFRES |
100 |
19.96 |
285 |
643 |
314 |
31400 |
0 |
|
Default_CreateFactory |
API internal authentication |
1 |
0.2 |
103 |
455 |
59 |
59 |
0 |
|
PoweredAir_MultiAvailability |
EDI:SATRQT-SATRSP |
200 |
39.92 |
279 |
1950 |
156 |
31200 |
0 |
|
PoweredPNR_AddMultiElements |
EDI:PNRADD-PNRACC |
100 |
19.96 |
352 |
359 |
123 |
12300 |
0 |
|
|
|
|
|
|
|
|
|
|
|
TOTAL |
|
501 |
100 |
|
|
175.2 |
97359 |
0 |
Test Run 3 - Using 'fast open' from factory
Since the release of Proxy-30, "Fast Open" is the default option
In this run, a ConversationFactory is created first, and
then all Conversations opened using the function CAI_openConversationFromFactory
.
The parameter CAI_OpenType-> bind_host_resource set to ‘false’ to ensure that a host resource or AAA is allocated at the reception of the first functional query only.
Conversations are closed using CAI_closeConversationFromFactory.
|
Transaction name |
Edifact message pair |
Amount |
% |
Mean |
Mean |
Mean (ms) |
amount |
Fast Opens |
|
Query length |
Reply length |
Response time |
* resp time |
|
||||
|
Command_CloseConvFromFactory |
EDI:HSFREQ-HSFRES |
100 |
24.938 |
241 |
176 |
217 |
21700 |
0 |
|
Default_CreateFactory |
API internal authentication |
1 |
0.249 |
103 |
455 |
342 |
342 |
0 |
|
PoweredAir_MultiAvailability |
EDI:SATRQT-SATRSP |
200 |
49.875 |
288 |
1941 |
249 |
49800 |
100 |
|
PoweredPNR_AddMultiElements |
EDI:PNRADD-PNRACC |
100 |
24.938 |
343 |
350 |
141 |
14100 |
0 |
|
|
|
|
|
|
|
|
|
|
|
TOTAL |
|
401 |
100 |
|
|
237.25 |
85942 |
100 |
Comparison of results
|
|
|
|
Response
Times |
|
|
openByCorporate |
600 |
0% |
127100 |
0% |
|
slow
open |
501 |
17% |
97359 |
23% |
|
fast
open |
401 |
33% |
85942 |
32% |
Interpretation of the results
The results show that using the Conversation Factory with the fast open option is the most efficient technique for managing conversations. There is a 33% reduction in overall transaction traffic, and 32% reduction in overall response time compared with the classic openConversationByCorporateId technique. Remember, that this improvement is for the exact same set of functional queries!
There are two reasons for this gain.
Firstly, it can be seen that the Conversation Factory minimizes the API internal authentication traffic exchanged between the APIv2 Gateway thanks to the fact that it authenticates the user only once (during 'Create factory' time) and can then subsequently opens as many conversations as needed without further Proxy to Gateway exchange.
Secondly the 'fast open' option further reduces traffic thanks to the fact that the sign-in process 'piggy-backs' the first functional transaction. The result of this is that the first functional transaction response time is slightly increased (this is normal as it also includes the sign-in process), but a complete return trip from Proxy to Gateway is saved (helping to reduce network traffic).
Conclusion
Using the fast open from factory can significantly reduce the amount of traffic exchanged with the Amadeus Central System, which in turn can improve the overall response time perceived by the end-user.
In the scenario above, a 33% reduction in traffic was achieved, with an overall response time benefit of 32% ! All this, for the same functionality!
The actual benefits of using the fast open can vary depending on the conversation usage i.e. average number of transactions per conversation used,
however, as a general rule, a client application working with multiple users & threads will always gain something compared to using the old CAI_OpenConversationByCorporateID / CAI_CloseConversation technique.