Cloud Based Framework for Rich Mobile Application

Size: px

Start display at page:

Download "Cloud Based Framework for Rich Mobile Application"

Ariel Sherman
6 years ago
Views:

1 Cloud Based Framework for Rich Mobile Application by Andrew Williams (ID: ), Krishna Sharma (ID:), and Roberto Fonseca (ID: ) CS 230 Distributed Systems Project Champion: Reza Rahimi Prof. Nalini Venkatasubramanian

2 Introduction The mobile application market is about to change radically, from suppliers' standpoint and from the consumer access standpoint due to the emergence of widgets, the most compelling of mobile cloud applications. Smart phones enable a new, rich user experience in pervasive computing, but their hardware is still very limited in terms of computation, memory, and energy reserves, thus limiting potential applications. Mobile users are demanding more out of their mobile devices and this plays a larger role in their daily lives. Although the computing ability of mobile devices has greatly improved over the last few years it is still not enough to satisfy the current demand needs. Extending Battery life of mobile devices is one of the main goals of the mobile industry today. Instead of being limited to the data storage and processing power contained in a mobile device, cloud apps have all the power of a server-based computing infrastructure accessible through an app's mobile interface. Mobile cloud computing is a term that refers to an infrastructure where both the data storage and the data processing happen outside of the mobile device from which an application is launched. Our Solution Future of smartphones is decided by the battery consumption and technology. Unfortunately, technology trends for batteries indicate that these limitations are here to stay and that energy will remain the primary bottleneck for handheld mobile devices. Our solution was the usage of the popular technique to reduce the energy needs of mobile devices is remote execution: applications can take advantage of the resource rich infrastructure by delegating code execution to remote servers. This concept where a remote, online backup service is used for storing data and running applications from a mobile is known as mobile to server offloading. Our main aim was setup a server-client mechanism where, a mobile cloud acts as a server while our mobile device acts as a client. Our application would be running on the server, while clients acts as the user interface and sends the relevant data needed for computation to the server. The server then calculates and returns the result to the client. Computation time is saved by the client, however transmission time needs to be taken into account before time or power savings may be realized. For the testing purposes we used a computationally intensive open source project Java OCR. We divided this into three components: Convert to gray scale, filter image and scan image. These components were distributed between client and server. We used Microsoft Azure as the public cloud server and one of our laptops as the local cloud server. We used Restful webservices on the cloud for RPC calls on server side. Profiling was done manually for testing purposes. We also tested end to end scenario from android phone to the cloud.

3 Testing Setup In our project we set up 4 basic scenarios in which to test the performance and power consumption of the system. Our tests measured the performance of our three system components, convert to gray-scale time, filter time, and scan time along with the round trip transmission time between the client and server. The client system that was used in testing is a 1.4 ghz Intel laptop with 512mb of RAM, since this was the weakest computer that we had it was a good simulator for the current computational power that is available on a high end smart phone (Droid X 1.0 ghz CPU). Our collection of test files consisted of two amounts of text in both small and large in 200, 300 and 600 DPI. This was done in order to be able to test the performance of the OCR and to be able to see the affect of using large files to try to determine a point when either the file size is too large to justify sending or that the file is too large that client side processing would be too much to handle. All testing was conducted on the UCI local area network using wireless access points. Scenario 1 Client Only Processing : In this scenario the client computer is just running the OCR program on its own, all three components are executed on the client machine. Figure 1

Scenario 1 Results: In Scenario 1 the output was as we expected. For client only execution as the image DPI increased, the amount of total time also increased.

4 Scenario 1 Results: In Scenario 1 the output was as we expected. For client only execution as the image DPI increased, the amount of total time also increased. The individual times for the Filter, Grayscale and Scan also scaled up as the image size increased. Scenario 2 Client / Server Hybrid using Cloud Server : In this scenario the client computer executes the convert to gray scale component and then sends data to the cloud server for execution (see figure 2). However files over a certain size can not be executed in this segmented partition because the intermediate image format for after gray scale on java OCR (Pixel Image) is too large. Figure 2

5 Figure 3 Scenario 2 Results: The total execution times that we experienced with the hybrid execution was much higher that expected mainly due to an issue with the partitioning of Java OCR. Since the filter component converts the java image, to a native format (Pixel Image) the size of the image in memory becomes very large since Pixel Image is a conversion to a matrix of pixels. Encoding and sending this image across the network becomes a very time consuming process for the client machine resulting in very long return times. Tests using any file size over 512KB resulted in out of memory exceptions in java and the return times even with small files far exceeded any of the other scenarios. (See table below for detailed times in milliseconds) Figure 4

6 Scenario 3 Server Only using Cloud Server: In this scenario the client sends a request to the Cloud server and the cloud executes all three components. Figure 5 Scenario 3 Results: In Scenario 3 we saw execution times that were very similar to the client only processing. However with very large files we did see an reduction in total time from ms for client only to ms for cloud execution only. Sizing of the compute instance on the cloud may be the reason we did not see a better increase (see Microsoft Azure compute Instances for details). Figure 6

Figure 7 Scenario 4 Server Only using Local Server: In this scenario instead of using a remote Cloud server, the server side application was hosted in the same network in order to observe the change

7 Figure 7 Scenario 4 Server Only using Local Server: In this scenario instead of using a remote Cloud server, the server side application was hosted in the same network in order to observe the change in performance when the server is much closer. Figure 8 Scenario 4 Results: The results that we obtained from this scenario were very positive, we used a 2.66 ghz laptop with 4GB of RAM that connected to the test laptop via LAN. In this scenario the total execution times were faster and in the case of large images it was almost 3 times faster than running on client system only on average this scenario ran in 18667ms while on client only took on average 66782ms.

Figure 9 Figure 10 Comparison of Results The results from the 4 scenarios pointed to execution on the local server (Scenario 4) having the best times, this is because the less powerful client machine

8 Figure 9 Figure 10 Comparison of Results The results from the 4 scenarios pointed to execution on the local server (Scenario 4) having the best times, this is because the less powerful client machine was able to quickly access the resources available with minimal transmission times since it was accessing the server on LAN. The times for the Hybrid execution (partitioned execution) were easily the worst times due to the image conversion that was required to perform the filter, gray scale and scan components separately. Lastly the execution only on the cloud server (Scenario 3) results in only a small increase of performance on the largest of files because of long transmission times. We believe that having access to a larger compute instance would much increase the performance of this scenario.

9 Figure 11 Energy Usage Testing We also performed energy usage testing on each of the components. We used a tool called Joulemeter by Microsoft research that that shows us the current energy usage of the entire system in Watts. By closing all non essential processes we were able to obtain an average base reading at which the computer was sitting idle (26.18 w). Then we would run the application in two different modes, client only (Scenario 1) and server only (Scenario 4) for 200, 400 and 600 large images and write down the maximum wattage that Joulemeter recorded. This does not provide us with an exact measurement of how much energy the application uses but instead provides us with a rough upper bound that we average over 20 individual trials. Figure 12 From the data in Figure 12 above, we can see that for client only execution the peak power consumption climbs steadily as the image resolution and file size get larger. Offloading also follows the same trend however the difference between 300 and 600 DPI images increases in power sharply because the file size doubles.

10 Android Energy Usage Testing We also tested using the Android application that was written for this project. Since the power consumption is dependent on the hardware being used we could not perform tests using the android emulator. In order to measure the power we used Power Tutor from the University of Michigan and it was tested on an HTC Inspire 4G with only the basic processes running in the background. Since the Java OCR required some image libraries that were not available on Android we needed to only server side power consumption in which the phone would upload the image to an FTP server then call a web service to execute the OCR, we were then able to achieve the following data. Figure 13 From the data that we found during the Android power consumption testing we can see that the Wifi is using the most power. This is most likely because none of the components computation is done on the phone but instead on the Cloud server. Conclusion: In terms of execution time the results have shown that offloading compute intensive applications to remote servers can improve application performance. In addition, significant power consumption reduction were observed when all components of the application run on the server side. Potential Issues: Microsoft Azure Compute Instances: The amount of available resources for Microsoft Azure is based on a compute instance. Compute instances are available in five different sizes, Extra Small, Small, Medium, Large and Extra Large, each step represents approximately a double in CPU speed, Available Memory and Storage. For our test we used a Microsoft Azure trial account which uses only the extra small compute instance which is a 1ghz CPU and 768 mb of working memory, which is no more powerful than a high end smart phone.

11 Java OCR on Android: The last step of our project was to create an Android application that ran our project in the 3 modes. During implementation of this application we ran into an issue with Java OCR since it needed the java library java.awt.image and this library was not supported in Android. To work around this we only implemented the server only execution where the Android app would upload the file to an FTP site then call a web service to use the image from the ftp.

12 Appendix Testing Images: The following images were used for the test results in the paper, both sets of small and large were tested in 200 DPI, 300 DPI and 600 DPI. Small Image Large Image

Open Mobile Platforms. EE 392I, Lecture-6 May 4 th, 2010

Open Mobile Platforms. EE 392I, Lecture-6 May 4 th, 2010 Open Mobile Platforms EE 392I, Lecture-6 May 4 th, 2010 Open Mobile Platforms The Android Initiative T-Mobile s ongoing focus on Android based devices in US and EU markets In Nov 2007, Google announced