The first group of tests was intended to
The first group of tests was intended to evaluate the performance of the GUI initialization. We evaluated the times obtained for different initial GUI models with 1, 2, 3, 5, 10, and 20 components as shown to the user. These sizes were chosen since GUIs (developed within our COTS-based architectures) are usually made up of less than 20 components. For example, a typical user interface with only one component in the aforementioned domain is a GUI composed by a map with geospatial information. In addition to the map, the user interface may contain a legend component and/or a component with a list of the layers shown, thus forming typical examples of GUIs with two and three components. Due to visual limitations and typical user preferences, the normal scenario is to manage GUIs with a maximum of four, five or six components. For completeness, we included experiments with 10 and 20 components so performance could be tested under less favorable conditions. At the very least, the results allow us to infer the response times for scenarios with additional components. We also evaluated performance with “low”, “medium” and “high” coupling. If “n” is the number of GUI components, low coupling means that there are fewer than “n−1” communications between components. High coupling means that the number of communications is over “n∗n (n−1)/2”, and medium coupling is an intermediate number. Fig. 16b shows the results of this apexbio biochem test. It is worth mentioning that the times shown in Fig. 16a correspond to the times shown in Fig. 16b for medium coupling. We can arrive at three conclusions from Fig. 16a and b: (1) the response times rise in proportion to the number of components, (2) the coupling degree does not affect (or has an insignificant influence on) performance, and (3) performance is suitable for GUI initialization, since the worst response time is below 600ms, resulting in a good user experience. Nevertheless, we performed another group of tests to evaluate the initialization by concurrent users, to test performance in a real exploitation/production environment. An excerpt of the results of this experiment is shown in Fig. 17, where rows (U) are the response times when different numbers of concurrent users i accessed the user interface, and columns (C) are the size of the model loaded. Low, medium and high coupling are represented by “l”, “m” and “h”, respectively. Performance is measured in milliseconds. When multiple concurrent users simultaneously make a request for GUI initialization, the server side is not able to respond to all users at the same time. Therefore, the “min” column in Fig. 17 gives the time taken for the first user to receive the response and complete the initialization process. The “max” column depicts the time taken for the last user to receive the response and complete the process. Fig. 8 shows a representation of the results (one for model). From the results depicted in Fig. 17 and the different graphs in Fig. 18, we are able to draw the following conclusions: (1) “min” response time remains almost constant and is not affected by the number of concurrent accesses, (2) “max” response time increases in proportion to the number of concurrent users, (3) the larger the GUI model is, the higher the increase in “max” value, and (4) GUI architecture coupling does not influence performance even if the number of concurrent users is increased (as we mentioned above for one user, see Fig. 16b). The results in Fig. 18 are summarized in the graphics shown in Fig. 19a and b, which represent the lowest and highest times achieved, respectively. Performance in these experiments is relatively good in terms of response times for GUI initialization with different numbers of concurrent users. Nevertheless, for models with 10 components the response time experienced by the last user (“max” value) begins to exceed acceptable levels (3.5s) once there are over 40 concurrent requests for access. For models with 20 components, the highest response time (over 3.6s), with over 25 concurrent initializations, is excessive. The reason the number of concurrent users influences the response time is because the application server (i.e., the platform-independent server) which has some points in common (shared EJBs) is accessed by all the users and a bottleneck may be created. An example of Pangaea is the EJB in charge of managing the user sessions. We therefore performed another experiment, in which we tried to lower the response time and improve performance. In this test, we deployed two and three platform-independent servers and balanced the workload by distributing the requests among the servers. The results are shown in Fig. 19c.