Access Point Framework Performance Results

As described in subsection 7.2.1, the performance of the APF has been evaluated as well. On Table 5 and Table 6, part of the obtained results are presented. In order to better understand the representation, it is important to mention that:

 Send Request signifies the average measured time for the requester to pass the prepared request through the 3 APF components, prior to sending it off to another APF instance

 Receive Reply stands for the average time measured from the point when a reply is received, then passed through the 3 APF components until it is dispatched to the application

 Receive Request, similarly, is the average time for the received request to pass through the 3 APF components

91

 Send Reply is the average time needed to pass the prepared reply, through the APF before sending it back to the requester.

The results on Table 5 were obtained from the test conveyed with a set of 1000 messages, and they represent how much time, in milliseconds, is necessary for a message (request or reply) to pass through each of the three components of the APF. In the specific case tested, the times presented in the AIC column describe how much time was needed for the request/reply to be transformed from Java to XML and vice versa, since this is currently the functionality of the AIC. Furthermore, the milliseconds measured for the TVE component, describe the time required for two actions, when it comes to sending a request or reply:

 a Velocity transformation

 an XML transformation from application specific to the Common Messaging Model (CMM)

On the other hand, the times presented in receiving a request or reply for the TVE, are measured against other two actions:

 transformation from the CMM to the application specific format

 an XSD validation against a certain schema, for receiving a request or reply.

Lastly, the values presented in the MPAS column, describe the time necessary for adding a header to the sending message, placing it on the queue, and storing it in the message warehouse (for sending request or reply). Accordingly, for receiving request or reply, the times measured represent removing the message header from the received message and adding the message to the warehouse as well.

AIC TVE MPAS

Send Request 24.925 43.338 49.305

Receive Reply 32.363 30.774 19.021

Receive

Request 63.957 28.154 16.878

Send Reply 20.212 34.203 26.139

Table 5: Time in milliseconds spent per component of the APF

In the lead, on Table 6, the results presented were obtained from the test with a message set of 3000 messages, explained in subsection 7.2.2. The numbers specify the total times in milliseconds necessary for sending a request, as well as receiving a reply, on the Requester side, and receiving a request and sending a reply on the Provider side. The times measured include all the actions previously described for each of the three components.

92

Average: Requester Provider

Send Request 112.6867ms /

Receive Reply 83.1077ms /

Receive Request / 112.7047ms

Send Reply / 85.8457ms

Table 6: Time in milliseconds spent per request/reply

On Figure 36, on the other hand, is presented the average time in milliseconds necessary for an APF instance to:

 send a request and process a reply; this is represented on the graph as Requester;  process a request and send a reply; this is represented on the graph as Provider;

Figure 36: Performance results for the Requester and Provider

As it is visible, the results obtained are very similar, and the slight difference is due to the fact that the testing was performed on two different machines with different capabilities. So overall, it can be said that on average, for the Requester, 195.7943ms are necessary to perform all actions, including passing a message through the AIC, TVE, MPAS components in two directions. Similarly, for the Provider, on average it takes 198.5503ms to also pass the request and reply through the 3 components in both directions.

7.3.2.1. Discussion on the APF’s Performance

If the results obtained for the performance of the APF are taken into consideration, an average number of interactions between the requester and provider, per second can be calculated. Therefore, the sum of the two final measurements (195.7943 for the Requester and 198.5503 for the Provider), would be 394.3446ms for sending and receiving request/reply. That means that approximately two complete cycles of sending request  receiving request  sending reply  receiving reply, running on two parallel APF instances,

195,7943 198,5503 0 30 60 90 120 150 180 210 Ti m e in M ill isecon d s

APF Performance Measurements

Requester Provider

93

can be completed within a second. This measurement was calculated having in mind that the current implementation of the APF is single threaded and synchronized, meaning that one cycle has to be completed before another one starts.

The final result of 2 request-response interactions per second might not be very high for an Enterprise Application Integration Framework. However, some aspects have to be taken into consideration. One is that the two APF instances were tested on PCs, where in reality for these purposes usually servers will be used, which offer bigger processing power. In a production environment deployed by Aurenav LLC, the APF instance handled throughput of several thousand messages, of variable size, per second, successfully, as the environment was different (Baldwin, 2012).

Another point is that from the deployment models of the APF discussed in Chapter 4 section 4.2, the one currently implemented and tested is the Centralized Integration model, which is suitable for small number of applications with low bandwidth and processing overhead. Therefore, for small business, with not so many applications to integrate, as well as not so many transactions per second, this can be quite appropriate solution.

Of course, we expect that the results will drastically improve when the APF is deployed in distributed manner. The results obtained in the evaluation of the message queues are real proof of improved performance, when running in distributed environment, where the throughput visibly and radically increased.

94