The results from Experiments 1a – 1c, 2a–2b, and 3a–3c give an idea about how the CSB–UCC influences latency in mobile distributed systems. All the nine (9) experiments focus on the determination of data propagation window in an n–device to multi–cloud ecosystem. Throughout the experiments, the file sizes are kept within the range of 100 MB to 2.4 GB. In experiments, 1a – 1c, I investigate the data propagation window of existing mobile enterprise solutions such as the Dropbox mobile App, the Amazon SDK for mobile, and the MEGA mobile Apps. The reason for the evaluation of these public offerings is to determine the base (benchmark) values with which I can compare/validate the performance of our proposed CSB–UCC architecture.
In experiments 2a – 2c, six (6) results are reported on the employment of the CSB–UCC as a centralized broker. The CSB–UCC is hosted on Amazon EC2 instance and the propagation window is determined using the client devices. With regards to services accessibility on Dropbox, I realized that up to 3200 users (representing approximately 28800 requests) can be supported to retrieve updated data within a time that is close to the base result for Dropbox. The number of requests is the number of files that can be retrieved using the HTTP GET method. However, users beyond 3200 experience a significant delay in the data propagation. Also, it is observed that the centralized broker supports 3214 (representing about 28900 requests) when propagating data from the Amazon S3 facility within close approximation to the base results on Amazon S3 App. Moreover, the centralized broker enables about 3206 users (representing approximately 28854 requests)
to be served when connected to the MEGA facility. Within the stipulated range of supported number of users, we observed that the update propagation window is reasonably close to the base values. The delay is within some insignificant seconds more than the base value.
However, in real world, the users of a system can be more than an average 3200 users. This creates the need to enhance the system capacity to maintain similar propagation window but with bigger user support. Thus, the distributed architecture of the CSB–UCC is tested with six active nodes. I realized that the following number of users can be supported: Dropbox – 20026 users (representing about 180234 requests), Amazon S3 – 20098 users (representing about 180882 requests), and MEGA – 20077 users (representing about 180693 requests). The distributed broker architecture raises the number of supported users to approximately 20000 because each node has the capacity of a centralized server.
For clarity, a summarized overview of the results are presented in Table A.1 in Appendix A. Considering the three public cloud services, I report the results obtained for each client device. The result includes the maximum propagation window within the file size range (Max Window) in seconds, the minimum propagation window (Min Window) in seconds, and the Average (Avg) in seconds. These results are recorded for each set of experiments which includes the base (benchmark) results (Base), the centralized broker within a supported user range (Centralized), the overloaded centralized broker (Overloaded), and the distributed broker architecture (Distributed).
By focusing only on the Avg, I calculate the average propagation window relative to the base result. This is an attempt to determine how slow or fast the proposed system performs against the benchmark results. This is calculated based on the formula:
Average Propagation Window Relative to the Base Result = AvgB – AvgM
where AvgB is the benchmark average result for each IaaS mobile service and AvgMis the average result
for each experimented broker architecture. So, assuming I want to calculate the average propagation window relative to the benchmark result for the Playbook using Dropbox, the result for the centralized broker is 360.79 - 360.37 which equals 0.42. This means that on average, the update propagation window of the centralized broker is 0.42 seconds faster than the Dropbox App on the Playbook device. Furthermore, the average propagation window relative to the base result for the Playbook using Dropbox when the distributed CSB–UCC is employed is 360.79 409.44 which equals -48.65. This means the average propagation window is 48.65 seconds slower when the distributed architecture is employed to propagate the updates from Dropbox in comparison to the Dropbox mobile App on the Playbook.
From the results, it is observed that clearly the delays which are introduced when the centralized server is overloaded can be intolerable. Depending on the domain that will adopt the CSB–UCC, waiting for several minutes to retrieve an update can be time wasting. Especially, in mission critical systems, the luxury of waiting for updates for minutes may not be afforded. Thus, such systems can adopt the distributed architecture approach to ensure load distribution that can lead to reduction in the propagation window. However, the distributed architecture is not a viable approach if the workload is minimal (at least within
the test range of up to 3200 users). In this case, the centralized architecture can be adopted because the propagation window is relatively same. The caveat with the centralized architecture however is the fact that when the broker crashes, the entire system can become non–usable since the broker acts as an application router. A possible solution is to keep a backup copy of the application state that can be employed is the vent of failures.
Though the distributed architecture shows great promise, it can also lead to higher cost in terms of expenses to buy several IaaS nodes for hosting, and system management. The distributed architecture means the application states will be hosted on multiple servers and enabling a coordinator to manage the communication flow in decentralized manner. In such cases, the management requires extra efforts when it comes to the detection of faults and maintenance. So, with the pros and cons highlighted, the adoption of the CSB–UCC architecture should be guided by the need of the enterprise regarding latency minimization, the workforce base of the enterprise, and the level of financial/cost commitment.
Next, the proposed best-proximity use case is tested.