main features
5.1 Interaction Mechanisms
6.2.4 Analytical Model Results
Figure 6.7 depicts a throughput perspective of the analytical model results. In this case, we have an indication for predicting how many simultaneous contributions the server supports as the number of participants increases. A typical throughput curve presents a rapid growing of the throughput value, until the system reaches the saturation point. This is the case ofattendee- sendclass (Figure 6.7(b)) that reaches the saturation point handling 434.3t ps , around 50users
participating in the co-browsing thread.
6.2 Application Server Scalability 106
Residence time equation for request classrat queuei:
R0i,r(−→N) = Di,r delay resource; Di,r[1+ni( − → N −−→1r)] queuing resource. (6.2) Throughput equation for request classr:
X0,r( − → N) = Nr ∑Ki=1R0i,r(−→N) (6.3)
Queue length equation for request classrat queuei:
ni,r(−→N) =X0,r(→−N)×R0i,r(−→N) (6.4) Queue length equation for queuei:
ni( − → N) = R
∑
i=1 ni,r( − → N) (6.5) Schweitzer’s approximation: ni( − → N −−→1r) = Nr−1 Nr ni,r( − → N) + R∑
t=1&t6=r n i,t(→−N) (6.6) Iteration error: ε =maxi,r nei,r(−→N)−ni,r( − → N) nei,r(−→N) (6.7)Figure 6.6: MVA Equations: equations that guide the MVA algorithm on solving the component level model (69).
However, the presenter-sendclass (Figure 6.7(a)) presents such an uncommon throughput curve. In this case, the saturation point is already with 1 user. It is due to growth dependency between the number of requests and the number of users (Table 6.4), since there is always just one request of this class in the system, not mattering the number of participants in the co-browsing thread. Considering now 100users, the application server still could handle 1.7t ps. As the web browse is the only informative contribution composing this request class, such throughput value is acceptable, since the relative response time for supporting 100users is around 588msec.
Another analysis perspective of the obtained results is concerning the expected response times. It is worth to remember that this metric is the main focus of the chapter. As expected for any system, as simultaneous requests in the system increases, the average response time tends to increase too. This behavior is shown by figure 6.8, which presents a forecast of response
6.2 Application Server Scalability 107
(a) Request Class:presenter-send (b) Request Class:attendee-send
Figure 6.7: Analytical Model Results - Throughput times.
(a) Request Class:presenter-send (b) Request Class:attendee-send
Figure 6.8: Analytical Model Results - Response Time
Assuming that the infra-structure for supporting a co-browse service is composed by only one server, we consider that the system provides an acceptable level of scalability. As it can be seen, even in such a impracticable case, having 500 users participating in the same co-browsing session, the application server still is able to handle requests in an acceptable time, where the
presenter-sendrequests would be handled in 2.8 seconds, while theattendee-sendin 1.1 second.
As a final remark, comparing the results obtained from the performance model and the practical experiments, we have observed that the performance model has not only overestimated the responsiveness of OCEAN, but also it had an inaccurate behavior (Figure 6.9). A possible explanation for that is because of adopted instrumentation method (see Appendix A), used for conducting the experiments. Recall that the parameters (service demands) used as entries to the analytical model were collected using an instrumentation method executed at the application
6.3 Conclusions 108
level. At the application level, some measurement points are inserted at the server to take the instant a request arrives, goes through the server resources (CPU, disk and sleep) and leaves. However, we recognize that there can be some imprecision on estimating service demand. Even though, considering this inaccuracy the obtained results still are valuable and the performance model tends to be an upper bound for response time.
(a) Request Class:presenter-send (b) Request Class:attendee-send
Figure 6.9: Validating the Performance Model: these graphs compare the results about server response time, obtained from experiments and from solved performance model.
6.3
Conclusions
This chapter showed that OCEAN’s design provides acceptable responsiveness to users. The delay imposed by the co-browsing mechanism has a low cost allowing users to experience a high level of synchronization in co-browsing sessions. Following, the application server evaluation suggests that the co-browsing system scales suited to users which is a very important characteristic for turning OCEAN’s prototype into a usable release candidate.
The adopted methodologies during such performance evaluation task involved two of the three basic disciplines of performance analysis: experimentation an analytical modeling. The first included a great effort on making repetitive experiments with the variation of some parameters (number of users, size of web sites and type of distributed users: dense or sparse). Coordinating such experiments was constrained by an inconvenience, which was the number of available computer for performing tests. The obtained results of notification protocol delay has demonstrated the high performance archieved by our prototype.
The second study has had a poor accuracy of the chosen model, and also the unexpected effect of the sleep component which has led to less relevant results than we expected. However, these results were still useful for providing us a better indication of the server scalability, rather
6.3 Conclusions 109
than intuitive insights. Therefore, such study can be very helpful for guiding further attempts of evaluation OCEAN.
For future work, there are others characteristics that should be evaluated and if necessary improved in OCEAN. Still considering performance, there are relevant issues to evaluate, for example, the effect of simultaneous co-browsing threads, or even simultaneous sessions in the system. Moreover, it will be interesting to extend the assumption that the application server does not fail, then we could investigate for instance: (i)system dependability(4); (ii)usability, regarding the quality of system usage perceived by individuals and groups(15); and (iii) the impact of such usage on organizations.
110
7
General Conclusions and
Outlooks
This work proposed an integrated solution for collaborative web browsing, taking into account the intrinsic characteristics of this collaboration paradigm, its main issues usually faced on building processes of groupwares dedicated to it. As a result, we have proposed OCEAN, a comprehensive groupware specification and implementation, developed for addressing the main requirements involved in a common co-browsing scenario.
Therefore, this chapter is dedicated to conclude this work providing a review of the obtained results, highlighting its main contributions, as well as presenting relevant topics to be considered in future work.