Normal versus AQL Picasa Application

We implemented the Picasa album application normally and by AQL respectively.

Figure 4.6 is a screen capture of our application. User enter a user ID and then click the “Enter” button, and then it will show the album list of that user’s ID. The normal Picasa application get the entire RSS from Picasa album list without compression. And then, parse the XML to get the album title and cover image urls. Finally, download all the “on screen”² images. On the other hand, AQL Picasa application (PicasaAQL) one set the quality parameter to “50” (PicasaAQL-50) another set quality parameter to “95”

(Picasa-95), the other set quality parameter to “100” (Picasa-100) for worst case in this experimental. We set the resize rate of all the PicasaAQL to “50” to get the images that is 80 x 80 pixels because original image size is 160 x 160 pixels, our application just show 60 x 60 pixels so 80 x 80 pixels is more better user interface looking. First, PicasaAQL get the necessary XML data by AQL query. For example, It will decrease XML size from

2On screen image is stand for the images that will initial show on Android phone’s screen. For example, if the screen can only contain 18 images, normal Picasa application will just download these 18 images until the user scroll the screen.

Figure 4.6: Application Screen Capture

19.443 bytes to 884 bytes (about 95.3% reduction) when there are 10 albums.

Table 4.8 shows the response time and the total transmission bytes (Request and Response). Figure 4.7 shows the line chart of Table 4.8. The response time is start from user click the “Enter” button to user see the album list. The total transmission bytes is the total packet length that send and receive by application during the response time. According to our experimental, we can found the normal Picasa application is little faster (200ms to 600ms) than PicasaAQL when the album image count is less (about 4 in Figure 4.7 (a) ). The reason is the fewer images need fewer request headers and it directly get images from Picasa. But the total transmission bytes is larger than PicasaAQL.

When the image count increase, normal application’s response time is raise very fast but PicasaAQL-50 and PicasaAQL-100 are increase slowly.

Table 4.8: Normal Picasa APP. versus PicasaAQL APP.

Time (ms) 1,441 2,025 3,040 3,462 3,821 4,959 5,576 5,938 7,345 Normal

Picasa

Total Bytes 32,725 52,039 86,291 103,362 121,311 130,627 147,519 159,747 172,012

PicasaAQL (50)

Response

Time (ms) 2,278 2,322 2,627 2,725 2,635 2,896 2,938 2,969 3,013 PicasaAQL

(50) Total Bytes 4,798 7,356 10,193 13,102 14,634 17,608 19,525 21,302 22,717

PicasaAQL (95)

Response

Time (ms) 2,131 2,477 2,583 3,011 3,156 3,190 3,348 3,669 3,722 PicasaAQL

(95) Total Bytes 8,715 16,339 25,240 32,634 38,568 46,300 52,766 57,883 62,485

PicasaAQL (100)

Response

Time (ms) 2,260 2,736 2,824 3,266 3,375 3,442 3,551 3,827 3,915 PicasaAQL

(100)

Total Bytes 12,653 26,856 40,842 53,409 63,746 77,181 87,786 96,120 104,091

0

(a) Response Time (b) Total Transmission Bytes

Figure 4.7: Line Chart of Response Time and Total Transmission Traffic

Chapter 5 Conclusion

In this thesis, we observed the overhead when Android mobile phone application calling the RESTful API in wireless environment. The Android mobile phone has very fantastic user interface and a large number of application to use. More and more mobile phone users using the Android REST client application to take the place of using Web browser to access the internet. The wireless network is more weaker than wired network so we proposed a system architecture to reduce the wireless transmission overhead when calling RESTful APIs. Our system architecture has two parts. Client-Side Library in Android application is to send the API query language to Proxy-Side Library and handle the response result from our proxy. It can reduce the HTTP request headers and use fewer request to get more results by AQL. Proxy-Side Library is to parse the query from Client-Side Library. It can filter the result according to AQL and compress the XML, JSON or any plain text format data to reduce the transmission traffic. Proxy-Side Library also have “Image Multiple Get” module to provides image compression, image resize and image combined function to reduce the Image transmission overhead. Experimental results show our system architecture can reduce the transmission traffic and improve the response time.

For the common plain text data, it will reduce over 61% of original data. For the images, according to image count and parameter setting, it could reduce the total transmission bytes about 80% and speed up the response time to about 50% when there were over 10 small images and the quality parameter and resize rate was set to 50.

Bibliography

[1] R. T. Fielding, Architectural Styles and the Design of Network-based Software Archi-tectures. PhD thesis, UNIVERSITY OF CALIFORNIA, IRVINE, 2000.

[2] I. Kilanioti, G. Sotiropoulou, and S. Hadjiefthymiades, “A client/intercept based system for optimized wireless access to web services,” in Database and Expert Systems Applications, 2005. Proceedings. Sixteenth International Workshop on, pp. 101 –105, 26-26 2005.

[3] T.-Y. Chang, Z. Zhuang, A. Velayutham, and R. Sivakumar, “Webaccel: Accelerating web access for low-bandwidth hosts,” Computer Networks, vol. 52, no. 11, pp. 2129 – 2147, 2008.

[4] Open Mobile Alliance Inc., WAP FORUM. http://www.wapforum.org.

[5] B. C. Housel, G. Samaras, and D. B. Lindquist, “Webexpress: A client/intercept based system for optimizing web browsing in a wireless environment,” Mobile Net-works and Applications, 1998.

[6] R. Han, P. Bhagwat, R. LaMaire, T. Mummert, V. Perret, and J. Rubas, “Dynamic adaptation in an image transcoding proxy for mobile web browsing,” IEEE Personal Communications, pp. 8–17, 1998.

[7] Y. Hwang, J. Kim, and E. Seo, “Structure-aware web transcoding for mobile devices,”

IEEE Internet Computing, vol. 7, no. 5, pp. 14–21, 2003.

[8] T. Bickmore and B. N. Schilit, “Digestor: Device-independent access to the world wide web,” in Proc. WWW-6, pp. 655–663, 1997.

[9] O. Buyukkokten, H. Garcia-molina, and A. Paepcke, “Seeing the whole in parts:

Text summarization for web browsing on handheld devices,” pp. 652–662, 2000.

[10] J. Chen, B. Zhou, and H. Zhang, “Function-based object model towards website adaptation,” in In Proceedings of the 10th International World Wide Web Confer-ence, pp. 587–596, ACM Press, 2001.

[11] Y. Chen, “Detecting web page structure for adaptive viewing on small form factor devices,” in In Intl. World Wide Web Conf. (WWW), pp. 225–233, ACM Press, 2003.

[12] X.-D. Gu, J. Chen, W. ying Ma, and G. liang Chen, “Visual based content under-standing towards web adaptation,” in In Second International Conference on Adap-tive Hypermedia and AdapAdap-tive Web-based Systems (AH2002, pp. 164–173, 2002.

[13] Z. Hua, X. Xie, H. Liu, H. Lu, and W.-Y. Ma, “Design and performance studies of an adaptive scheme for serving dynamic web content in a mobile computing environ-ment,” IEEE Trans. Mob. Comput., vol. 5, no. 12, pp. 1650–1662, 2006.

[14] Yahoo! Query Language. http://developer.yahoo.com/yql/.

[15] Facebook Query Language. http://developers.facebook.com/docs/reference/fql/.

[16] Yahoo!奇摩生活+ API. http://tw.developer.yahoo.com/lifestyle/.

[17] P. Deutsch, “Gzip file format specification version 4.3,” RFC 1952, May 1996.

[18] Twitter API Documentation. http://dev.twitter.com/doc.

[19] Yahoo!奇摩知識+ API. http://tw.developer.yahoo.com/knowledge/.

[20] Best Practices for Speeding Up Your Web Site by Yahoo! Developer Network.

http://developer.yahoo.com/performance/rules.html.