## 5 Results
### Performance Evaluation  
#### 5.3.1 Using QoS Criteria for Diagnostics  
From the first experiment, recall that the purpose was to stress-test Web services with a lot of concurrent requests and to measure our proposed approach and the impact it has in systems performance. We obtained the following results: Figures 4 and 5 show the same number of messages sent from 10 clients up to 5000 clients. In both Figs. we report the average response time; the response time measured the time it takes a client from sending their request (a message) until they get their response back (from a service provider). From Figures 4 and 5 we observed that the average RT and its corresponding standard deviation were quite similar in both (approaches without QoS evaluation and after using the QoS evaluation based on FIS) graphs for all cases even after highly increasing the number of clients; the QoS evaluation performed better by reducing abrupt increments in the average response time as the number of clients grows. In collaborative environments where intercommunication take place an important issue is resource usage and storage. Therefore, proposed solutions must remain constant and scalable even in the presence of large-scale environments, our solution aims to support these issues, and as illustrated by Figure 5. Besides, our proposal remained constant for a high number of interactions; therefore, it is scalable. \begin{table}
\begin{tabular}{c c c c c} \hline \hline \multicolumn{5}{c}{**Variable Values of Membership Functions**} \\ \hline \multicolumn{5}{c}{Input} \\ \hline  & Set & L & C & R \\ \hline \multirow{3}{*}{Response Time} & VG & \(-2.5\) & 0 & 2.5 \\  & G & 0 & 2.5 & 5 \\  & A & 2.5 & 5 & 7.5 \\  & B & 5 & 7.5 & 10 \\  & VB & 7.5 & 10 & 12.5 \\ \hline \multirow{3}{*}{CPU} & CPU\_L & \(-33.33\) & 0 & 33.33 \\  & CPU\_M & 0 & 33.33 & 66.67 \\  & CPU\_H & 33.33 & 66.67 & 100 \\  & CPU\_VH & 66.67 & 100 & 133.3 \\ \hline \multirow{3}{*}{Memory} & M\_L & \(-33.33\) & 0 & 33.33 \\  & M\_M & 0 & 33.33 & 66.67 \\  & M\_H & 33.33 & 66.67 & 100 \\  & M\_VH & 66.67 & 100 & 133.3 \\ \hline \multicolumn{5}{c}{Output} \\ \hline \multirow{3}{*}{FCSE} & FCSE\_VH & \(-1.25\) & 0 & 1.25 \\  & FCSE\_H & 0 & 1.25 & 2.5 \\ \cline{1-1}  & FCSE\_A & 1.25 & 2.5 & 3.75 \\ \cline{1-1}  & FCSE\_L & 2.5 & 3.75 & 5 \\ \cline{1-1}  & FCSE\_VL & 3.75 & 5 & 6.25 \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Membership functions values for inputs and outputs. To have a significant statistical sample, we executed each run for 100 times. For instance, when 20 concurrent clients requested a Web service we collected 2000 samples, and computed their average RT and standard deviation, as shown in Figure 5. For 50 concurrent clients, we collected 5000 samples, so on. In addition, each scenario constituted a dedicated server that hosted Web services and each Web service instance computed the overall QoS for each request/response. Specifically, computing at runtime, at any point in time, the fuzzy-consistency system evaluation (FCSE). The statistical sample size followed the [PERSON]'s sample size formula [34]:  
\[n=\frac{t^{2}pq}{d^{2}}\] \[n=\frac{(1.65)^{2}(.5)(.5)}{(0.0825)^{2}}=100\]  
where \(t\) = value for the selected alpha level of 0.05 in each tail = 1.65, \((p)(q)\) = estimate of variance = 0.25, \(d\) = acceptable margin of error for the portion being estimated = 0.0825 (the error researcher was willing to accept 8.25% for our case). From Figures 4 and 5 we can conclude that the proposed QoS evaluation approach slightly incremented the average RT, however, it remained constant, and it helped having a fast evaluation of the system at any time. The evaluation helped us to diagnose the system and take proactive actions, in our case decide if a checkpoint was essential or not. Hence, we could compute the evaluation of the system; at runtime our next goal was to leverage this calculation.