Scalability of Mobile Cloud Storage

— Today, there are high demands on Mobile Cloud Storage (MCS) services that need to manage the increasing number of works with stable performance. This situation brings a challenge for data management systems because when the number of works increased MCS needs to manage the data wisely to avoid latency occur. If latency occurs it will slow down the data performance and it should avoid that problem when using MCS. Moreover, MCS should provide users access to data faster and correctly. Hence, the research focuses on the scalability of mobile cloud data storage management, which is study the scalable on how deep the data folder itself that increase the number of works.


Introduction
The main issues related to data management are the scalability of data and storage data [1], [2], [3]. In Mobile Cloud Storage (MCS) it is important to maintain the scalability even users access the data file with many cloud storage services at one time. Scalable and consistent data management is a challenge that has opposed database research and the public for more than twenty years. It deals with petabytes of data, serves online requests for stringent latency and availability requirements as well as causes the workloads. If this problem is not handled well, it will decrease the performance of CC and consequently the industry, which no longer uses this system.
MCS is important to maintain scalability even users access the data file with multiple cloud storage at one time. For instance, access Dropbox, Google Drive, Box, and One-Drive at the same time. The scalability needs to be able to maintain the performance of mobile Web pre-fetching. In this research, the scalable is on how deep the data folder itself increases the number of works. The deepness of the data folder is referred to as the data level. The highest data level is the deepness of the data folder. If users using the normal MCS, the scalability is worse because it takes a long time for users to access the data. The purpose of this research is to enhance the scalability in handling several data in MCS environment.

Related work
The performance of scalability is measured based on response time [2], [4], [5]. To enhances service scalability and reduce the risk of performance degradation is by handling a larger number of data. Besides, fault tolerance mechanisms affect the system scalability and usability [4], [5], [6], [7], [8]. According to Rimal et al. [7], Microsoft Azure had an outage of about 22 hours in March 2008 that leads to critical issues if the downtime cannot be handled in Cloud Computing (CC) environment. Every year, thousands of websites need to face unpredicted downtime and hundreds of systems interruptions. Hence, the critical issue for CC is how to minimise such outages or failover to provide the scalability of the services. The issues of cloud scalability are investigated in this research and the performance measure is based on response time. Other researchers have used response time as a performance measure for cloud scalability [5], [6]. Due to concern in scalability, as well as performance and reliability arising from the management of multiple service queues and a large volume of service requests, centralised approaches are not suitable and architectures using service monitoring and management services are needed.

Material and methods
Besides MCS gives scalability, reliability, and efficiency in performance. Scalability is a key aspect of MCS [3], [9][10][11], which offers unlimited processing and storage capacity. It allows developers and IT operations to develop, deploy and run applications at the software level of CC, which easily grow in capacity, work fast and never fail. CC is reliable by enabling access to applications and documents anywhere in the world via the Internet. Therefore, users can easily access their applications anywhere. Moreover, CC provides efficient service by allowing an organisation to free up resources to focus on innovation and product development.
The questionnaire was distributed to 69 people but only 15 people were selected among them to measure the scalability of Mobile Cloud Storage (MOBICS), the latency per page ratio, precision, and recall. Only 15 users were selected from 69 respondents to test the scalability of MOBICS. The Nielson Norman group indicated that 5 users could uncover 85% of the major usability issues, and 15 users could find 100% [12] [13]. In addition, Ginny Redish stated that about 6 to 12 users needed to be involved in doing product testing and the testing worked on at the end of the process. Therefore, this research proposed to evaluate the scalability of MOBICS based on 15 users, the best number of respondents.
The scalability test was conducted by comparing different loads, which were data load level 1 to data load level 5 as shown in Figure 1. For example data level 1 consisted sort of data files, which were data 1, 2, 3, 4, and others. Then, data 1.1 in data level 2 was referred from data 1 from data level 1. Data 1.1.1 in data level 3 were referred from data 1.1 in data level 2 and the other followed the same flow. The result of response time based on different data levels as depicted in Table 1. The scalable is how deep the data folder itself increase the number of works. When creating a scalability test, it is important to scale up in increments. The data must be scaled up in increments as each stage tests. Small loads ensure the system functions as it should be on a basic level. Medium loads test if the system can function at its expected level. High loads test if the system can cope with a high load. The scalability was measured based on the total number of responses. This is the measure of time needed for a response to complete (from request to last response). The response time was recorded using a screen recorder that could monitor the user's activity while using the MOBICS. The data levels are used as variables to measure the response time. Response time experiment result is the benchmark to measure the scalability [2], [14], [15], [16] . Data level is the number of data positions. This experiment involved 5 data load levels that were significant to measure the performance of MOBICS. Table 1 shows the total response time on data levels 1 to 5 by comparing them to without pre-fetching (W), with pre-fetching (P), and with DT rules. The most efficient one with a short response time is highlighted in bold. Based on Table 1, using pre-fetching was more efficient compared to without pre-fetching and DT. Data level 1 took 15.3 seconds to access data. However, when the data level was increased, the result showed using DT was more efficient than with or without the pre-fetching. As evident, the response time on data level 5 (the deepness data level) by using DT took only 22.2 seconds to access data compared to with or without the pre-fetching which took 60.2 and 27.2 seconds respectively. It concluded that the total response time using DT was faster compared with the pre-fetching only and without the pre-fetching even at the high data level (Data level 5) and the total response time using the pre-fetching only was better than without the pre-fetching at each of data level.

Results and discussion
Latency per page ratio, precision, recall, used as a benchmark in this experimental result as mention earlier. The equation of latency per page ratio is the ratio of the latency that pre-fetching achieved to the latency with no pre-fetching. The latency per page is calculated by comparing the time between the browser initiation of an HTML page GET and the browser reception of the last byte of the last embedded image or object for that page. This metric represented the benefit perceived by the users, which will be better if it is low as its value [17]. Total response time is shown in Table 1 and it was recorded based on different data levels for 15 users. Five data levels were being used in this research to analyze the total response time with or without the pre-fetching. In addition, the total response time based on a DT algorithm was also recorded. Based on Table 1, it was proven that using pre-fetching was effective compared with traditional MCS (without the pre-fetching).  3  16  15  16  25  15  17  25  15  15  26  21  15  61  28  22   4  28  14  15  22  11  15  26  17  16  27  20  16  65  27  22   5  17  17  17  22  16  17  23  17  17  25  18  17  66  27  22   6  27  17  18  26  17  16  30  15  13  26  19  15  63  27  22   7  30  16  18  27  13  18  31  10  12  27  17  15  60  28  21   8  11  15  18  30  19  16  23  11  13  25  17  15  59  26  22   9  17  13  17  29  21  14  26  13  12  27  19  13  58  29  23   10  16  16  16  29  17  15  25  17  12  28  23  16  60  28  21   11  19  17  17  22  19  15  27  15  15  24  17  17  60  27  22   12  23  15  17  26  16  15  22  10  13  26  16  16  59  27  22   13  22  16  18  27  14  13  26  11  14  25  16  16  58  25  24   14  27  18  16  21  17  12  28  15  13  27  17  16  59  28  22   15  26  12  15  25  16  14  24  15  12  25  15  15  58  29  Furthermore, Figure 2 depicts the latency per page ratio that was calculated to evaluate the latency on MCS. The results show the latency was even lower at a high data level. The latency page ratio at data level 5 was 0.45 which was the smallest compared with the latency per page ratio at data level 1 which was 0.74. Therefore, using pre-fetching was effective in handling big data management commonly for multiple MCS. In MCS evaluation recall and precision are greatly used to measure algorithm performance. Precision [18] and recall are frequently used to measure the effectiveness of performance of the pre-fetching [19]. Precision is the ratio of the number of relevant records retrieved to the total number of irrelevant and relevant records retrieved. While recall is the ratio of the number of relevant records retrieved to the total number of relevant records in the database. Table 2 shows the result of precision and recall for the proposed MOBICS. The data were evaluated based on total the pre-fetch hit for 15 respondents to get the average value of precision and recall. The result proves the MOBICS provided high precision and recall with 86% and 76% respectively.

Conclusion
The scalability test was successful as it required less total response time in accessing the data even at a high data level. The performance of pre-fetching was measured based on the latency per page ratio that was calculated to evaluate the latency on the MCS. The results showed the latency was low even at a high data level. Besides, precision and recall were used to measure the effectiveness of the performance of pre-fetching. The result proved that the MOBICS provided high precision and recall with 86% and 76% respectively. The scalability test had improved and proved MOBICS efficiency that took only 22.2 seconds to access data even at the high data level (data level 5) compared to with and without the pre-fetching which took 60.2 and 27.2 seconds respectively (refer to Table 1).