Spatial Trend Prefetching for Online Maps Mashupsmashups related to online maps are comparatively...

Spatial Trend Prefetching for OnlineMaps Mashups

by

Jun Zhang

A THESIS SUBMITTED IN PARTIAL FULFILMENT OFTHE REQUIREMENTS FOR THE DEGREE OF

Master of Science

in

The Faculty of Graduate Studies

(Computer Science)

The University Of British Columbia

(Vancouver)

August, 2008

c© Jun Zhang 2008

Abstract

Mashups try to merge some specific information together with online mapsapplication by displaying related markers onto maps. Sometimes markerswill be displayed very slowly. In this thesis, we have presented an approachto improve the performance of related applications by reducing networklatency for those responses. We use Spatial Trend Web Prefetching Modelto predict the areas which can be possibly arrived at after next movements.We classified movements into three patterns. Then this model will checkhistory operations done by a specific user, find possible pattern he may befollowing and then predict next possible operations for the user according tothe specific algorithm responding to that pattern. In our experiments donefor lab environment (Nearby Cities application) and Internet environment(Skype-Google Map application), we can see that our approach can achievehit rate of about 85% when movement interval is not less than 1000ms andlarger than 30% when movement interval is less than 1000ms.

ii

Table of Contents

Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii

Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii

List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v

List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi

Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . viii

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Background and Related Work . . . . . . . . . . . . . . . . . 42.1 Technology for Mashup Applications . . . . . . . . . . . . . . 42.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 Spatial Trend Web Prefetching Model . . . . . . . . . . . . 83.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.2 Spatial Trend Web Prefetching Model . . . . . . . . . . . . . 12

3.2.1 Model Summary . . . . . . . . . . . . . . . . . . . . . 123.2.2 Prefetching for Pattern I . . . . . . . . . . . . . . . . 163.2.3 Prefetching for Pattern II . . . . . . . . . . . . . . . . 183.2.4 Prefetching for Pattern III . . . . . . . . . . . . . . . 193.2.5 Extensions . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . 22

4 Analytic Evaluation . . . . . . . . . . . . . . . . . . . . . . . . 254.1 Around Prefetching Approach . . . . . . . . . . . . . . . . . 254.2 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.3 Results and Analysis for Lab Environment Experiments . . . 30

4.3.1 Single Pattern Experiment . . . . . . . . . . . . . . . 304.3.2 Simulation Experiment . . . . . . . . . . . . . . . . . 45

4.4 Results and Analysis for Real World Case . . . . . . . . . . . 52

iii

Table of Contents

4.4.1 Single Pattern Experiments . . . . . . . . . . . . . . . 524.4.2 Simulation Experiment . . . . . . . . . . . . . . . . . 57

5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.1 How Mashup Server Affects Prefetching? . . . . . . . . . . . 595.2 How Prefetching Affects Response Time? . . . . . . . . . . . 605.3 Factors Causing the Latency of Displaying Markers . . . . . 615.4 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Appendices

A Algorithm, Results and Analysis for Pattern IIIB . . . . . 67A.1 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67A.2 Results and Analysis for Experiment IIIB in Lab Environ-

ment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67A.3 Results and Analysis for Real Case Experiments . . . . . . . 70

iv

List of Tables

4.1 Experiment Variables and Their Possible Value . . . . . . . . 284.2 Experiment Configuration for Single Pattern Experiments in

Lab Environment . . . . . . . . . . . . . . . . . . . . . . . . . 314.3 Average RT for Un-hit Responses While MI=1000ms . . . . . 334.4 Results for Three Representative Experiment IIIA (MI=0ms) 364.5 Experiment Configuration for Simulation Experiments in Lab

Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.6 Trend Prefetching vs Around Prefetching for Simulation Ex-

periments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.7 Experiment Configuration for Single Pattern Experiments of

Real World Case . . . . . . . . . . . . . . . . . . . . . . . . . 534.8 Trend Prefetching vs. Around Prefetching for Simulation Ex-

periment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

v

List of Figures

3.1 A Route to Move Google Map. . . . . . . . . . . . . . . . . . 93.2 Bound Distance . . . . . . . . . . . . . . . . . . . . . . . . . . 113.3 Classes of Pattern III . . . . . . . . . . . . . . . . . . . . . . . 143.4 Pattern I Prefetching for 1st look-ahead step . . . . . . . . . 163.5 Pattern II Prefetching for 1st look-ahead step . . . . . . . . . 183.6 Pattern II Prefetching for 1st look-ahead step . . . . . . . . . 183.7 Pattern III A Prefetching . . . . . . . . . . . . . . . . . . . . 20

4.1 Hit Rate Changes According to Different PI/MI . . . . . . . 324.2 Increased Traffic Rate Changes According to Different PI/MI 324.3 Response Time for Experiment IIIA while MI=3000ms . . . . 334.4 Response Time for Experiment IIIA while MI=2000ms . . . . 344.5 Response Time for Experiment IIIA while MI=1000ms . . . . 344.6 Response Time for Experiment IIIA while MI=0ms . . . . . . 344.7 Average Response Time . . . . . . . . . . . . . . . . . . . . . 354.8 Hit Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.9 Increased Traffic Rate . . . . . . . . . . . . . . . . . . . . . . 394.10 Movement Time for Experiment IIIA while MI=3000ms . . . 404.11 Movement Time for Experiment IIIA while MI=2000ms . . . 404.12 Movement Time for Experiment IIIA while MI=1000ms . . . 414.13 Movement Time for Experiment IIIA while MI=0ms . . . . . 414.14 Average Movement Time for Experiment III A Series . . . . . 414.15 Metrics Sorted According to Different Move Patterns . . . . . 434.16 Hit Rate vs. Average Response Time . . . . . . . . . . . . . . 444.17 Hit Rates (No Stress on Application Server) . . . . . . . . . . 464.18 Increased Traffic Rate (No Stress on Application Server) . . . 474.19 Average Response Time (No Stress on Application Server) . . 484.20 Response Time for Simulation Experiment . . . . . . . . . . . 504.21 Movement Time for Simulation Experiment . . . . . . . . . . 504.22 Hit Rates for Real World Case . . . . . . . . . . . . . . . . . 544.23 Increased Traffic Rate for Real World Case . . . . . . . . . . 55

vi

List of Figures

4.24 Average Response Time for Real World Case . . . . . . . . . 564.25 Response Time for Experiment IIIA When MI =0ms . . . . . 574.26 Response Time for Simulation Experiment of Real World Case 584.27 Movement Time for Simulation Experiment of Real World Case 58

A.1 Pattern IIIB Prefetching . . . . . . . . . . . . . . . . . . . . . 68A.2 Experiment Results for Experiment IIIB in Lab Environment

with Stress on Mashup Server . . . . . . . . . . . . . . . . . . 69A.3 Experiment Results of Experiment IIIB for Real World Case 71

vii

Acknowledgements

First I would like to thank my supervisor, Eric Wohlstadter, for helping methroughout my research. He always had time to discuss things and gavepriority to reviewing my documents in a timely manner. When I felt lostand did not know where my research was going, he helped me see the overallplan and helped me remain grounded. It was a great opportunity to workwith Eric, who is an amazing supervisor and person.

I’d also like to thank Peng Li and Chao Yan for their helpful advice onmy thesis.

viii

Chapter 1

Introduction

Websites such as Google.com and Yahoo.com provide online maps and re-lated APIs, and applications have been developed by use of them. We callthose applications mashups related to online maps. Some of those mashupsdisplay some markers representing some specific information for specific ad-dresses, which are covered by the screen. They will display new markers asusers move the map to a new area.

Those mashups are becoming more and more popular, since they cannot only enable users to access some specific information but also relatethat information to some specific addresses and their surroundings. Forexample, through the weatherbonk.com application [21], we can know theweather information of Toronto and also can learn the weather informationfor those cities near Toronto or those cities along a highway from Ottawa toToronto. However, we find that sometimes it is very slow for some mashupsto display markers onto online maps. Some of this kind of slowness is causedby the rendering of display markers. Sometimes it is caused by slowness ofmashups on mashup servers.

To solve those issues, programmers can improve their source code to dis-play markers as quickly as possible. Some programmers improve mashupperformance by reducing the number of requests. For example, Skype-Google Map in Section 4.4 gets information, which can be covered by thecurrent screen together with its surrounding areas. Then when users do notmove out of that range, there will be no new requests sent out. So it cansave some time for network latency by reducing the number of the requests.However, it is very easy for users to move out of the range. When it hap-pens, it will be very slow to display markers. Even sometimes, it takes moretime because for each request, the mashup gets more data for a larger area.So it can not always solve the problem.

To reduce the network latency, which causes markers in mashups to bedisplayed onto online maps slowly, we adopt the technology of web prefetch-ing to predict next possible requests and to get responses for them in ad-vance. Then when clients send those requests, those related responses canbe retrieved from the memory of clients instead of remote servers. Since

1

Chapter 1. Introduction

mashups related to online maps are comparatively new, some traditionalweb prefetching technologies [12, 15–17, 20, 25] can not be applied. We havedeveloped a new web prefetching model, the Spatial Trend Web Prefetch-ing Model. It does prediction based on the operation history done by thespecific user. Since operations of users are to move online maps, historydata shall include the information related to those movements, such as thedistance to move online maps and the interval between every two continuousmovements etc. To find the possible trend embedded in movement historydata, we have classified movements into several patterns. The model checkswhich pattern the latest movement follows, how long the interval has takenbetween the last movement and the step before the latest one, and then doesprediction for next possible movements accordingly.

We have evaluated the performance of this approach compared withthe one without any prefetching and with another prefetching approachanalytically in the lab environment and the Internet environment. In thelab environment, we set up a simple mashup application to simulate a realworld case and add stress to the mashup server to simulate work load in thereal world. For our particular experiments done in the lab environment, thehit rate is about 85% when movement interval (See Definition 3.6) is not lessthan 1000ms and is larger than 50% when movement interval is less than1000ms, except when movement distance (See Definition 3.1) is longer thanbound distance (See Definition 3.9 and 3.10). For our experiments donein Internet environment, we choose Skype-Google Map as an experimentsubject. Hit rate is no less than 85% when movement interval is not lessthan 1000ms and is at least 30% when the movement interval is less than1000ms. Accordingly the response time in both environments is generallyreduced a lot, except when the movement interval is approaching to be 0msand there are big jumps for response time caused by too many requestssent to the mashup server. These specific results depend somewhat on thespecific environment and application used. So we discuss those dependenciesin detail in Chapter 4.

We also find that the movement patterns followed by the latest move-ment, the interval between every two movements, the load of the mashupserver and the bottleneck of Google Map and Firefox would affect the hitrate and the time to display the markers onto online maps.

We begin by providing background information about the technology onmashup applications related to online maps and the work done on prefetch-ing or other technologies to improve the performance of those applicationsin Chapter 2. Then we present our approach to predict next possible move-ments based on the history of operations done by users in Chpater 3. We

2

Chapter 1. Introduction

present the evaluation done in both the lab environment and the real worldcase in Chpater 4. Then we discuss some outstanding issues with the ap-proach and the possible solutions in Chapter 5. After that, we will provideour conclusion in Chapter 6.

3

Chapter 2

Background and RelatedWork

In this part, we will introduce the technology related to mashups for onlinemaps. Additionally, we will discuss related research literature.

2.1 Technology for Mashup Applications

A mashup is “a web application that combines data from more than onesource into a single integrated tool” [22].

Currently, the most popular mashups are the Google Maps mashups.According to the statistics data on the programmableweb.com [18], about23% of mashups listed belong to this type. Google Maps mashups combinedata elements from multiple sources, hiding this behind the graphical in-terface of a Google Map. Those mashups display markers at some specificcoordinates on Google Maps. It displays those markers as overlays onto theimages of Google Maps. According to W3C standards for HTML [23], theoverlay element is used to overlay images on top of a base image.

The process to build up a Google Maps mashup uses Google Maps APIs[3]. Google’s Maps APIs are based on coordinates; one must specify thelatitude and longitude of a location to show it on the map. Google’s APIshave provided a geo-coding service by which you can translate an address tocoordinates and show an address on the map. Also, a lot of third parties canhelp developers get latitude and longitude information. For example, in ourown application, Nearby City, to be used in Chapter 4 in the lab experiments,we used the database dump of geonames[9]. For each city, it includes thespecific cities’ name, latitude and longitude information. Additionally, wecan get this kind of information from some web service. For example, thereis a service from geocoder.us [10] that uses public domain data to translateUS addresses to coordinates.

Google Maps are based on AJAX technology, which provides a wayof loading tiles of a large image from Google servers. Programmers ap-

4

Chapter 2. Background and Related Work

ply AJAX to the development of mashups. When the marker informationdatabase, for example, the database on weather information or cities in-formation, is deployed on the mashup server, it will be very easy to getresponse information from it. However, when data source has to be gotfrom a third-party server, there will be some problem: For security reasons,most browsers do not allow cross-domain calls. At that time, we may needto make the mashup server forward those requests to a remote server andforward responses back to the client. Then the framework will be like theone in [5], which is used for GPS applications. It takes more network la-tency to get data remotely. So prefetching is much more important for thosemashups.

To begin the development of Google Maps mashups, we have to get a keyto use Google Maps APIs at first and then use the key to load a JavaScriptfile, which includes all of the symbols and definitions you need to use theGoogle Maps APIs.

The first step is to create a Google Map on your own web page by useof the class GMap2 to create a new map instance, which is to be specifiedby an element in the web page (usually a div element) as a container forthe map. To initialize the map, we should provide a pair of latitude andlongitude as the center of the map, which can be changed as we move theGoogle Map.

Next, we should develop a script in Javascript to send out AJAX re-quests to the mashup server. Those requests shall include the informationabout the size of the screen, which can be got by GBound, a class in GoogleMaps APIs and will be sent to the mashup server to get the response in-formation, which shall include the information of longitude and latitude forsome specific addresses. To display response information onto the GoogleMap, we use GMarker to create markers for that information related to somespecific addresses. We assign a click listener to a marker that pops open aninformation window over the marker. Then we display those markers byadding the related overlays onto the Google Map.

To enable the markers to be updated as we move the Google Map, weuse GEvent to catch some specific events. For example, in the Nearby Cityexample, we catch every movestart and moveend event. When those eventsare caught, the old markers will be removed from the Google Map and thenew markers will be displayed onto the Google Map.

The Nearyby City application firstly displays the area whose center isthe city of Beijing. If the zoom level is set to be 6, the screen may coverthe cities including Tianjin, Shi Jiazhuang, Jinan and Zhengzhou and soon. Also there are Google Map default markers to be displayed onto the

5


points which represent those cities. Those markers will be updated, whenwe change the bounds of the screen by changing the zoom level or movingGoogle Maps.

Besides the above basic knowledge, there are two points we have to men-tion: Firstly, since Google Maps mashups are related to spatial movements,their performance can be improved by spatial query, which has been ex-plored in [7, 11]. Also, most industry databases engines, such as MySQLand Oracle, have provided such functions. So when we design mashups, wecan use related techniques to improve the mashup’s performance. The sec-ond one: we have found that some security mechanism set up on a mashupserver can slow down responses. Generally, there are some firewalls or otherways to help protect mashup servers from intrusion or attack by hackers. Soif there are a lot of requests sent to a mashup server, some related firewallsor intrusion detection software may consider those requests are to attack theserver and then start the protection mechanism, which will slow down thespeed for clients to get responses or make lots of responses get lost. It canbe shown by our experiments in Chapter 4.

2.2 Related Work

Web prefetching can be used to improve the performance of web applications.This technology can predict the next possible HTTP operations for users andthen get the responses for those operations in advance. Then when usersreally do those operations, it will get those responses with less time.

According to who initiates the prefetching, the prefetching technologiescan be classified into three types [16]: Server Side Prefetching, Proxy SidePrefetching and Client Side Prefetching.

For Server Side Prefetching, it uses information from the web server topredict the documents that will be requested soon and prefetches the objectfrom the disk to the main memory of the server. Sometimes, it can provideclues on the next possible steps to the client to improve the client’s responsetime and then the client can initiate a prefetch. For example, in [25], anefficient mechanism is provided for video streaming over wide-area networkswith server-assisted prefetching.

For the Proxy Side Prefetching, the proxy prefetches documents fromweb servers and stores them in a proxy cache. It can gather information frommulti-clients or multi-servers, which makes it possible to do good prediction.Prefetching from the proxy side is a well studied concept [12, 15].

For Client Side Prefetching, it works with a browser to learn the personal

6


profile to predict future requests and uses the available bandwidth to retrievedocuments. For example, in [6], the potential of a client-side prefetchingmechanism has been explored by use of trace driven simulations.

Among the three kinds of prefetching, the Server Side Profetching cannot solve the issues caused by network latency and it mainly focuses onreducing the time to access to the hard disk or database. The Proxy SidePrefetching may not be able to reduce the network latency, since sometimesthere is network traffic jam between the proxy server and clients. Compar-atively, the performance of the Client Side Prefetching may be limited bythe resources of the client.

Several algorithms have been provided for prefetching to do prediction.Some of them try to do prediction based on statistics data from clients’ visitinformation. For example the Top-10 Prefetching [17] predicts the next re-quests by a prediction table consisting of the documents that are accessedvery frequently. Some prefetching approaches determine which link will bevisited based on client behavior characterization. For example, IntelligentPrefetching [20] does prefetching based on the operations of a web client orbehavior learning of the client. It is a prefetching technique by character-izing the client side behavior alone. The factors considered to determineprediction include the trend in visit counts and the order of visits of URLsby the web client. This prefetching provides a framework for web clientbehavior characterization, which classifies the web client’s operations intothree modes, and a model to capture and predict client behavior.

Since mashups are new kinds of web applications, there is little workdone on web prefetching for this kind of application. However, some explo-ration has been done to improve the performance of Web 2.0 applications,which can give some clues for us. Doloto [13] tries to reduce the time to loadJavascript by doing code splitting for network bound Web 2.0 applications.During this process, Doloto uses a prefetching queue on the applicationserver to store the split source code to be loaded to the client. Anotherexample, the Skype-Google Map application [19] reduces the requests forthe application server by getting the response information to cover the sur-rounding areas of the current screen. It provides some clues for us thatprefetching for around areas is a very straightforward way for programmersto do prefetching, which is why we choose it to do a comparison with ourapproach in Chapter 4.

7

Chapter 3

Spatial Trend WebPrefetching Model

According to our own experience, we can learn that sometimes there aresome rules for our usage of an online map. For example, we may move themap for a long distance quickly and as we approach to some object address,we may slow down and move the map with little distance to search theobject carefully. To do efficient predictions, it is necessary to analyze thetrend or rules embedded in the users’ history of operations. Spatial TrendWeb Prefetching Model does predictions based on the analysis of users’operation history.

Firstly we will give the definitions used in the Spatial Trend Web Prefetch-ing Model in Section 3.1. After that, we begin to introduce the model inSection 3.2 and provide the details for the algorithm for different movementpatterns in Section 3.2.1 - 3.2.4. At last, Section 3.3 will give details of howwe implemented it.

3.1 Definitions

Before the introduction of Spatial Trend Web Prefetching Model, we givesome basic definitions in this section.

In Figure 3.1, there are n movements from P0 to Pc. The points ofP0 . . .Pc are center points of those screens which are arrived at after eachmovement. For example, P0 is the center point of the screen of Google Mapsbefore the 1st movement. We use Pc to represent the center point of thecurrent screen after the latest movement. For each point, we use the pair oflongitude and latitude to represent its position. For example, Pi(lngi, lati).

Definition 3.1 (Movement Distance): The distance between twocenter points of two continuous movements is defined as movement distance.Suppose the ith step is a movement from Pi to Pi+1, then the movement

8

Chapter 3. Spatial Trend Web Prefetching Model

Figure 3.1: A Route to Move Google Map: Black points represent centerpoints of the screens after movements

9


distance is:

Distance(Pi, Pi+1) =√

(lati − lati+1)2 + (lngi − lngi+1)2 (3.1)

The movement distance is composed of two parts: one in latitude di-mension and the other in longitude dimension. Generally, we use those twoparts to evaluate how far a map has been moved.

Definition 3.2 (Latitude Distance): The movement distance in lat-itude dimension (LatDistance) is

LatDistance(Pi, Pi+1) = |lati+1 − lati| (3.2)

Definition 3.3 (Longitude Distance): The movement distance inlongitude dimension (LngDistance) is

LngDistance(Pi, Pi+1) = |lngi+1 − lngi| (3.3)

Definition 3.4 (Movement Angle): The angle of movement from Pi

to Pi+1 is the angle between the line PiPi+1 and the line parallel to longitudein east as is usual. In Figure 3.1, the angle of P1P2 is angle(P1, P2). We canget it by:

angle(P1, P2) = Arctg(lati+1 − latilngi+1 − lngi

) (3.4)

Definition 3.5 (Response Time): Let the time when a client sendsout a request be Ts and the time when the client gets its response be Tr.Then the response time for this request is:

RT = Tr − Ts (3.5)

Definition 3.6 (Movement Interval): Let the time when a browserfinishes the latest movement be Te and the time when the browser begins todo next movement be Tb. Then the movement interval between those twomovements is:

MI = Tb − Te (3.6)

Definition 3.7 (Look-ahead Step): We define those movements pos-sibly to be done in the future as look-ahead steps. Let the number of look-ahead steps be L. When L=1, this means we are predicting the next move-ment; when L=2, this means we are predicting the next, next movementand etc.

10


Definition 3.8 (Prefetching Interval): Let the time when we doprefetching for ith look-ahead step (L=i) be Ti and the time when we doprefetching for (i+1)th look-ahead step be Ti+1. Then the prefetching in-terval is:

PI = Ti+1 − Ti (3.7)

Suppose NorthEast and SouthWest represent the diagonal points for theonline map displayed in the current screen, as in Figure 3.2.

Figure 3.2: Bound Distance: The lines represent bounds of a screen. Theblack points represent the SouthWest node and the NorthEast node of thescreen.

Definition 3.9 (Latitude Bound Distance): The distance betweentwo bounds parallel to latitude lines is Latitude Bound Distance.

LatBoundDistance = |lnge − lngw| (3.8)

Definition 3.10 (Longitude Bound Distance): Similar to Definition3.9, Longitude Bound Distance is:

LngBoundDistance = |latn − lats| (3.9)

Definition 3.11 (Latitude Distance Ratio): The ratio of LatDis-tance and LngBoundDistance:

LatDistanceRatio(Pi, Pi+1) =LatDistance(Pi, Pi+1)LngBoundDistance

(3.10)

11


Definition 3.12 (Longitude Distance Ratio): The ratio of LngDis-tance and LatBoundDistance:

LngDistanceRatio(Pi, Pi+1) =LngDistance(Pi, Pi+1)

LatBoundDistance(3.11)

The last three definitions will help describe the Pattern III prefetchingalgorithm in Section 3.2.

Definition 3.13 (Main Direction): The direction in which the mapis moved for a longer distance than in other directions.

Definition 3.14 (Row Area): The continuous areas with the samesize, whose centers have the same latitude are defined as a row area.

Definition 3.15 (Column Area): The continuous areas with the samesize, whose centers have the same longitude are defined as a column area.Figure 3.7 provides an illustration.

3.2 Spatial Trend Web Prefetching Model

3.2.1 Model Summary

There are three assumptions:

1. Users generally do not change their movement patterns constantly,including the direction and distance.

2. The faster for users to move the map, the less possibility for users tochange their movement patterns.

3. At most time, movement distance would not exceed onescreen bound distance in both dimensions. At thattime, LatDistance(Pc−1, Pc) <= LngBoundDistance andLngDistance(Pc−1, Pc) <= LatBoundDistance.

Based on those three assumptions, Spatial Trend Web Prefetching Modelpredicts the possible direction and distance of look-ahead steps according tohistory data.

Spatial Trend Web Prefetching Model does predictions by applying twomain steps: (i) checking and (ii) predicting.

12


CheckingBased on movement angle and distance, Spatial Trend Web Prefetching

Model classifies movements into three movement patterns:

Pattern I (Little Distance Pattern): Movement follows Pat-tern I only if 0 < LatDistanceRatio(Pc−1, Pc) <= 1% and 0 <LngDistanceRatio(Pc−1, Pc) <= 1% . Here we choose 1% instead of afixed distance value, since some specific distance value may be very little forsome zoom level, e.g. 1, but will be very large for another zoom level, e.g.10.

Pattern II (Single Direction Pattern): Movement follows PatternII only if it meets with one of the following conditions:

• LatDistance(Pc−1, Pc) = 0 and LngDistanceRatio(Pc−1, Pc) <= 1%

• LngDistance(Pc−1, Pc) = 0 and LatDistanceRatio(Pc−1, Pc) <= 1%

When one of movement distances exceeds 1% of bound distance andthe other one is equal to 0, then we say that the movement follows SingleDirection Pattern.

Pattern III (Multi Direction Pattern): Movement follows PatternIII only if it meets with one of the following conditions:

• LatDistance(Pc−1, Pc) > 0 and LngDistanceRatio(Pc−1, Pc) > 1%

• LngDistance(Pc−1, Pc) > 0 and LatDistanceRatio(Pc−1, Pc) > 1%

When both movement distances are larger than 0 and at least one ofthem is larger than 1% of bound distance, then the movement follow MultiDirection Pattern.

Based on the main direction, we can classify Pattern III into the followingsub-classes:

• Pattern III (1): If ( angle(Pc−1, Pc) < 45 and angle(Pc−1, Pc) > −45), the main direction is east ;

• Pattern III (2): If ( angle(Pc−1, Pc) < −45 and angle(Pc−1, Pc) >−135 ), the main direction is west;

• Pattern III (3): If ( angle(Pc−1, Pc) >= 135 and angle(Pc−1, Pc) <=225 ), the main direction is south;

13


Figure 3.3: Classes of Pattern III

14


• Pattern III (4): If ( angle(Pc−1, Pc) >= 45 and angle(Pc−1, Pc) <=135 ), the main direction is north;

For Pattern III, sometimes the latest movement distance follows somehistory trend, that is, there is no big change for its distance compared withthose of previous ones. Sometimes, there is a big change for the distanceof the latest movement. To make sure the prediction is efficient, we shouldcheck if the latest movement follows the history trend:

• |LatDistance(Pc−1,Pc)−LatDistance(Pc−2,Pc−1)|LatDistance(Pc−2,Pc−1)

<= 0.25

• |LngDistance(Pc−1,Pc)−LngDistance(Pc−2,Pc−1)|LngDistance(Pc−2,Pc−1)

<= 0.25

If both above conditions are ture, we will conclude that the distanceof the latest movement follows the same trend with previous movements.Here, we choose 0.25 since if it is increased, hit rate may be decreased andif it is decreased, some needless areas may be prefetched. We chose thisparameter’s value based on our intuition. So far we have not validated thatit is always optimal.

PredictingNext, we do prediction according to the movement pattern information

and history information.For Pattern I, the model predicts that look-ahead steps will move with

little distance. Since movement distance is little, we do not care aboutmovement angle and distance.

For Pattern II, the model predicts look-ahead steps will continue to movein the same direction and movement distance will be no larger than onebound distance. Since to move in a single direction, users have to use move-ment cursor buttons on the top left of Google Maps, which enable maps tomove for a short distance, for example about 1/3 of LatBoundDistance or1/3 of LngBoundDistance for a Google Map.

For Pattern III, we analyze movement angle and provide a range forthose areas to be prefetched. During this process, we predict movementdistance based on history data which depends on if the latest movementfollowed some trend or not. We predict movement distance as below:

• If the latest movement followed some trend, then we predict movementdistance to be the average value of related movements. This means:Suppose the ith step till latest movement, movement distance followsthe same trend. Then for look-ahead steps, we predict the latitudedistance and longitude distance to be:

15


1.

c∑k=i

LatDistance(Pk, Pk+1)

c−i+1 (i <= c) and

2.

c∑k=i

LngDistance(Pk, Pk+1)

c−i+1 (i <= c)

• Otherwise, we predict movement distance to be equal to the last move-ment distance. This means: If there is a big change for the distanceof the latest movement compared with those previous ones, then wepredict the latitude distance and the longitude distance for look-aheadsteps to be: LatDistance(Pc−1, Pc) and LngDistance(Pc−1, Pc);

Additionally, in Spatial Trend Web Prefetching Model, we do predictionnot just limited to one look-ahead step. Instead, we will do prefetchingiteratively. For each loop, we sleep for a prefetching interval, since constantlysending requests to application server can cause pressure for the mashupserver and clients.

The details of the prefetching are described in 3.2.2 - 3.2.4.

3.2.2 Prefetching for Pattern I

For Pattern I, we define it to move maps for little distance. Since we assumethat those look-ahead steps will move map with little distance, then if thereis one look-ahead step, that step can be covered by the current screen andthose areas around the current one. So, for the 1st look-ahead step weprefetch the surrounding areas. In Figure 3.4, suppose Area 5 is the currentscreen which the latest movement arrived at. We will do prefetching forArea 1 - 9 for the 1st look-ahead step.

Figure 3.4: Pattern I Prefetching for 1st look-ahead step

In summary, the algorithm for Pattern I is to find possible areas at firstand then do prefetching for those areas.

16


Algorithm 1 Prefetching Algorithm for Pattern I

• Input: the bounds information for the area after the latest movement

• Procedure:

– Find the possible areas to be prefetched: the surrounding area ofthe current screen.

– Send requests to the mashup server for those areas;

17


3.2.3 Prefetching for Pattern II

We define Pattern II to move maps in a single direction. Here, we predictthat look-ahead steps move in the same direction with the latest movementif it follows Pattern II. For movement distance, we predict it to be Lat-BoundDistance or LngBoundDistance.

For the 1st look-ahead step, we do prefetching for the next area in themovement direction. For example, in Figure 3.5, suppose the latest move-ment arrived at Area 1 from west, we will do prefetching for Area 2 as the1st look-ahead step.

Figure 3.5: Squares represent screens of maps

Figure 3.6: Squares represent screens of maps

Algorithm 2 Prefetching Algorithm for Pattern II

• Input: the bounds information for the area after the latest movement

• Procedure:

– For each loop j (j >= 1):

∗ Find possible areas to be prefetched: the jth area next to thecurrent area in the movement direction

∗ Send requests to the mashup server for those areas∗ Sleep for prefetching interval

– Repeat the loop;

If we do prefetching for several look-ahead steps, we will do prefetchingfor one additional area extended in the movement direction. In Figure 3.6,continuing the example in Figure 3.5, if we do prefetching for the 6th look-ahead step, we will prefetch for Area 6.

18


The algorithm for Pattern II is similar to that for Pattern I, except forthe way to find possible areas to be prefetched.

3.2.4 Prefetching for Pattern III

We define Pattern III as a movement which moves not in a single directionor little distance. Suppose the center point of the current screen is Pc andthe center point of the previous one is Pc−1, then we do prefetching for theareas that are selected from those which have overlaps with the area definedby (as in Figure 3.7)

[−|angle(Pc−1, Pc)|, |angle(Pc−1, Pc)|] (3.12)

Since we suppose next movements will be with similar angles to the latestmovement, their movement angles will fall in the range defined by formulaIII-1 at most times. Suppose the distance of the latest movement in latitudeis LatDistanceP and the distance in longitude is LngDistanceP. Check thefollowing conditions:

LatDistance(Pc−1, Pc) <= LngBoundDistance (3.13)

LngDistance(Pc−1, Pc) <= LatBoundDistance (3.14)

We define Pattern IIIA and Pattern IIIB based on 3.13 and 3.14 anddesign our algorithm accordingly: If both 3.13 and 3.14 are true, then wethink movements are following Pattern III A and the next rows and columnscould cover next steps. Prefetching will be done starting with the row orcolumn area next to the current one in the main direction. If one of them isnot true, then we think movements are following Pattern III B and the nextrows and columns could not cover the steps, since those steps have move outof the prefetched areas. We provide a related algorithm in Appendix A.

For each look-ahead step, we will do prefetching for one row or columnarea falling in the specific area defined by formula 3.12: If latest movementfollows Pattern III (1) or (2), then we will do prefetching for one columnarea; otherwise we will do prefetching for one row area. We try to explainabove ideas by use of the following examples.

In Figure 3.7, after a map is moved from the center of Area 21 to thatof Area 17 and both conditions of 3.13 and 3.14 are true, then we will doprefetching for the column with Area 17 and the column beside Area 17 asthe 1st look-ahead step, the one with Area 18 for the 2nd look-ahead step,then the one with Area 19 as the 3rd step and the one with Area 20 as the4th step, etc.

19


Figure 3.7: Pattern III A Prefetching

Algorithm 3 Prefetching Algorithm for Pattern III

• Input: the bounds information for the area after the latest movementand history data

• Procedure:

• Calculate movement distance for look-ahead steps: suppose they areLatDistanceP and LngDistanceP.

• For each loop j (j >= 1):

– Find the possible areas to be prefetched:

∗ If the latest movement follows Pattern III (1) or (2): the jthcolumn area next to the current area in the main direction

∗ If the latest movement follows Pattern III (3) or (4): the jthrow area next to the current area in the main direction

– Send requests to the mashup server for those areas;

– Sleep for prefetching interval;

• Repeat the loop;

20


To sum up, the algorithm for Pattern III is to calculate the movement dis-tance at first, next to predict possible row or column areas to be prefetched.It will sleep for one prefetching interval between each iteration.

3.2.5 Extensions

Based on experimental results, we make some improvements for the algo-rithm described above:

Extension ITo avoid duplicate prefetching, we check if there is a hit in memory for

the area to be prefetched. If 20 continuous look-ahead steps can get hit, wewill conclude that there is a duplication about prefetching. Then to savethe resource, we will not continue the process to do prefetching. The reasonfor us to check 20 continuous steps is that: According to our experiments inthe lab environment, if we set that value to be 15 or l0, hit rate would belower, since some prefetching processes which shall be continued have beenstopped.

Extension IIIf movement interval is less than response time, then the hit rate for

Spatial Trend Web Prefetching Model will be very low for Pattern II andPattern III, since before clients can get responses for the prefetching, themap has been moved for several steps. Then it is impossible to get a hit inmemory. To solve the problem, we have improved the above algorithm asbelow:

1. Find the specific look-ahead step whose response is possibly hit. Wecan get it by RT = ceil(RT

MI ).

2. If the latest movement follows Pattern II, then for the 1st look-aheadstep, we will do prefetching from the area to the one which is the RMtharea in the main direction. Starting with the 2nd look-ahead step, wewill do prefetching for RM areas extended in the movement direction.

3. If the latest movement follows Pattern III, then for the 1st look-aheadstep, we will do prefetching from the column or row beside to thecurrent screen to the RMth column or row area. Starting with the2nd step, prefetching will be done for every RM rows or columns.

21


Here we do not change the algorithm for Pattern I, the reason is that iflook-ahead steps follows Pattern I, the possibility for them to move out ofthose areas around the current one is very low.

Extension IIIWe do not want prefetching to be done forever, which will waste a lot

of traffic. We use the latest number of continous steps which follow thesame movement trend as the number of the steps to do prefetching, since itprovides some indication how long a user might follow the same pattern ofthe latest movement.

3.3 Implementation

There are two ways to implement this web prefetching tool. Both of themneed to interrupt the HTTP requests sent from browsers, analyze thoserequests and do prefetching based on the analysis with Spatial Trend WebPrefetching Model.

One is to upload a Javascript by use of GreaseMonkey, an extension forFirefox, and then use the script to interrupt the XMLHTTPRequest, analyzethe request information and do prefetching if necessary. The prefetchedinformation will be cached in the memory allocated for Firefox. The wholeprefetching process will cost resources of Firefox. It can make Firefox slowdown. Also, this way just can work with Firefox, since no other browsersprovide a similar extension for different operating systems.

The other way is to develop an independent prefetching server on clients,which will interrupt all HTTP requests through setting proxies of browsersand then do prefetching accordingly. This way does not cost the resourcesfor browsers. Also, it can be applicable to work with any browser. So atlast we choose this way to implement a multithreaded prefetching server.

We implement the model as a Java application, which can be dividedinto the following parts:

Thread PoolsThere are two thread pools set on the prefetching server. One thread

pool enables this server to catch all of the requests from browsers. The otherthread pool is to do prefetching. For each request, the server selects one ofthe idle threads from the first pool to handle it. Since for some movementpatterns, we have to do prefetching for several steps and there are limitedthreads in the first pool, we prefer to use an idle one in the second pool to

22


handle prefetching.

CachingAll of the information is stored in memory as vectors. Here we do not

use hash table. The reason is that the process to check if the current areacan be hit needs us to check all areas which have overlaps with the currentone, since sometimes a hit can compose several responses cached. So hashtable can not help us here. In the future, we can use a more advanced datastructure such as a spatial index [11].

The information stored is not limited to response content but also in-cludes part of the request header, the bound information of the area andzoom level, which are used to differentiate requests.

• Since it is possible that some users would like to use two mashups atthe same time, we store URL headers for responding applications.

• One area cached can be defined by the points SouthWest and NothEast(See Figure 3.2). Then the information of an area to be cached is{latn, lats, lnge, lngw}.

• Also, different zoom levels can produce different responses for an ap-plication. For example, the fastfoodmaps application [8] will displayonly cities who have fast food restaurants on Google Maps when zoomlevel is 4 and will display the specific restaurants when zoom level is8.

MatchingFor each request to the mashup server, we check if there is a hit in the

memory. We do that by matching the request header, bounds informationand zoom level information with those cached ones. If there is a hit, wewill return the response content to the client directly. Sometimes, a hitis made up of several responses in the cache. At that time, we have tohandle the response by forwarding the combination of them to the clientin a correct format. The reason for us not to parse those responses andcache information for separate markers is that: Different mashups providedifferent formats for their responses and it is very difficult for us to providea general way to parse them and create a new response.

Rate of PIMI

According to our experiments, when the ratio between prefetching inter-val and movement interval is 1/6 in the lab environment, the hit rate will

23


be the best. But in the real world case, to save some traffic and avoid bigjumps for the response time, we just use the rate of them to be 1/3 andaccordingly, the hit rate will become lower. For the details, see Section 4.3and 4.4.

24

Chapter 4

Analytic Evaluation

The evaluation of the efficiency of Spatial Trend Web Prefetching Model willfocus on two points:

• If our approach can improve the performance of mashups comparedwith those which do not use any prefetching approach;

• If our approach can improve the performance of mashups better thanthose which use a simple approach

For the second point, we choose a simple prefetching approach, AroundPrefetching, which is described in Section 4.1. After that, we will do exper-iments for the three approaches, the one without prefetching (No Prefetch-ing), the one with Around Prefeching and our approach (Trend Prefetching)and analyze the results accordingly.

We chose to do experiments in a lab environment first, since we wantto evaluate our approach in a clean environment to avoid other factors ofthe real world that disturb the results, such as unstable response timesand security mechanisms (See 5.1) adopted by mashup servers. To makethe results convincing, we use various ways together to simulate real-worldnetwork traffic. Section 4.2 will give the details of the lab experiments.Section 4.3 will provide the results and accordingly the analysis for the labexperiments. Then we do some experiments outside the lab for a real worldmashup, which is covered by Section 4.4.

4.1 Around Prefetching Approach

Since we need to measure how well our approach has improved mashupperformance compared with other approaches, we need to find an alternativeapproach to ours. An easy way to do prefetching is to prefetch around areasafter each movement. That is:

• For each movement, we will do prefetching for around areas, just likethe 1st look-ahead step as mentioned in Figure 3.1.

25

Chapter 4. Analytic Evaluation

• For each movement, we just do only one look-ahead step.

• Before each operation of prefetching, we will check if there is a hitalready for the areas to be prefetched. If yes, then we will not prefetchthose areas.

In the experiments, we have implemented a prefetching proxy for this AroundPrefetching approach.

4.2 Method

To do evaluation in the lab environment, we set up a private subnet, includ-ing a desktop as the mashup server, whose CPU is Intel Pentium 4 3.00GHZand RAM is 1024M, and a laptop as the client, whose CPU is Intel PentiumM 1.30GHZ and RAM is 768M.

Also, we chose to develop a mashup, named Nearby Cities, by ourselvesusing Apache Tomcat, Java Servlet and Mysql. This application is developedto simulate a real world Google Maps mashups using Google Maps APIs.After each movement, the application will display makers for no more than10 cities in the current screen. For example, if we move a Google Map to thescreen with the center of “Beijing”, then the markers representing cities likeBeijing, Tianjin and etc. will be displayed accordingly. Those old markerswill be removed before displaying new markers. We got the data aboutcities information all over the world from the Geoname web services [9] andimport part of them into our local database. For each city, the informationincludes its name, the province it belongs to, the country it belongs to, itslatitude and longitude, etc.

To simulate real world mashup server resource usage, we use netperf [14]to add enough stress to the mashup server to make sure its CPU utilization isabout 90% and memory utilization is about 55%. Also to simulate networklatency, we make each thread on the mashup server to handle the requestssleep for 1000ms, before sending out responses to clients.

Another important factor we have to consider is how to design the routeto move a Google Map. For the Nearby Cities mashup, we designed routesby selecting the capital cities covered by our database firstly, including Bei-jing, Astana, Tashkent, Bishkek, and Ulaanbaatar. Then based on theirlatitude and longitude, we use Traveling Salesman Problem TSP [1] – Sim-ulated Annealing SA algorithm [2] to provide a route to move Google Maps.After that, we divide the route between every two continuous points intoeight parts and set one point for each part. Google Maps could be moved

26


automatically using a Greasemonkey script or the prefetching server, bywhich we modify some Javascript of the application. This kind of automaticmovement can reduce the incorrectness caused by hand.

For experiment configuration, we considered several variables which canaffect experiment results: movement pattern and movement interval and soon. For details, see Table 4.1.

Based on whether movements follow a single pattern or mixtures of pat-terns, our experiments are mainly classified into several classes as below:

Single Pattern Experiments: In an experiment, movements followonly one movement pattern. For example, in some experiments, we justmove a Goolge Map following Pattern III. We will provide a fixed value formovement interval of each experiment. Then the combination of experimentcategory and movement interval will define different experiment groups.

Simulation Experiments: In an experiment, movements simulate howusers might use mashups which are related to online maps. That is, ourmovements will follow a mixture of those patterns in different usage modes.Also, movement interval value is not fixed and will be changed according todifferent usage modes.

To make sure the evaluation to be reasonable and measurable, we useseveral metrics. We focus on measuring the performance with some met-rics, including Hit Rate, Response Time and Average Response Time. Weevaluate if prefetching approaches can affect other parts of the applicationwith the metrics of Movement Time and Average Movement Time. Also,we will evaluate increased resources used by our approach with the metricIncreased Traffic Rate. The details for the metrics are listed below:

Metric 1 (Hit Rate): Let the number of requests that are hit be Nh,and let the total number of requests sent from client to the mashup serverbe Nt. Then the hit rate is:

HR =Nh

Nt× 100% (4.1)

Metric 2 (Response Time): It has been defined in Definition 3.5(Response Time) of Chapter 3.

Metric 3 (Average Response Time): Suppose there are N steps of

27


Table 4.1: Experiment Variables and Their Possible Value

Experiment Variables Possible Value

Experiment Category

Experiment I: Movements follow Pattern IExperiment II: Movements follow Pattern IIExperiment IIIA: Movements follow Pattern IIIand movement distance does not exceed onebound distance in both two dimensionsExperiment IIIB: Movements follow Pattern IIIand movement distance will exceed one bounddistance in at least one dimension.

Movement Interval

0ms: Movement interval is set to be 0ms. Infact, since it takes some time for a map to bemoved, suppose it to be , and then is the realmovement interval. See Figure 4.13, it displaysthe real movement interval while movement in-terval is set to be 0ms.250ms: Movement interval is set to be 250ms.500ms: Movement interval is set to be 500ms.750ms: Movement interval is set to be 750ms.1000ms: Movement interval is set to be 1000ms.2000ms: Movement interval is set to be 2000ms.3000ms: Movement interval is set to be 3000ms.

Number of Movements The number of steps to do movement in an ex-periment. Let its value to be N. Then we chooseN to be: N >= 20 and N <= 40. Since thetwo mashups used in later parts just cover partof Google Map, if we move for too many steps,we may move into an area not covered by thosemashups. Then we can not get response for thatmovement. So we set the maximum value for Nto be 40. At the same time, we want to makesure the precision of our experiment results, sowe set N no less than 20.

Zoom Level Since we use Google Maps in our experiment,the value for zoom level fall in its range: 0-18.

28


movements and the ith response time is RTi and the average response timeis:

ART =

N∑i=1

RTi

N(4.2)

Hit Rate and Response Time are used to evaluate web prefetching ap-proaches. By use of the metrics of Response Time, we can check whether ahit can save some response time for the client. However, since a mashup is areal-time application, its response time is dependent on whether the mashupserver is stable or not. Sometimes, some individual response time does notchange a lot even after using prefetching. For example, in experiments inSection 4.3 and 4.4, there are big jumps for response time as movement in-terval is shortened. This may cause us to get an erroneous evaluation. Tosolve this issue, on one hand, we collect response time for all movements andtry to find the graphical trend of them; on the other hand, we use AverageResponse Time to measure if there is some improvement on the speed for aclient to get responses.

Metric 4 (Movement Time): Let the time to finish a movement beTe. Let the time to start the movement be Ts. The movement time is:

MT = Te − Ts (4.3)

Metric 5 (Average Movement Time): Suppose there are N steps ofmovements and the ith movement time is MTi, then the average movementtime is:

AMT =

N∑i=1

MTi

N(4.4)

Generally there are two parts for a mashup: One part is to display spe-cific areas of online maps and the other is the application part which is todisplay markers and information onto online maps. Our web prefetching ap-proach focuses on improving the performance of the application part, thatis, to improve the speed of displaying markers onto online maps. During thisprocess, we do not want our approach to affect the performance of anotherpart, such as to delay displaying tiles of online maps. So we provide Move-ment Time to measure how quick the map can be moved successfully. Just

29


like Response Time, Movement Time also depends on real world networklatency. So we also analyze the graphical trend of Movement Time and themetrics of Average Movement Time to measure the speed to move onlinemaps and to check if prefetching approaches have affected displaying onlinemaps.

Metric 6 (Increased Traffic Rate): Suppose the traffic generatedby prefetched requests and responses is Bpref , suppose the traffic generatedby those no-prefetched responses and requests is Bunpref , and suppose thetraffic generated by responses and requests while not using any prefetchingis B, then increased traffic rate is:

ITR =Bpref + Bunpref − B

B× 100% (4.5)

4.3 Results and Analysis for Lab Environment

Experiments

In the lab environment, we have carried out both the single pattern experi-ments and simulation experiments. The details will be shown in this sectionand Appendix A.1. For each experiment in this section and Appendix A.1,we have repeated it for at least five times.

4.3.1 Single Pattern Experiment

In this section we will do experiments whose movements will follow a singlepattern and the movement interval will be with a fixed value throughout anexperiment. The configuration of these experiments could be defined by thecombination of the values in Table 4.2.

There are some points that should be explained: Generally, we set zoomlevel to be 6 in the experiments. However, sometimes, we have to set it tobe 9. As we know, if given the same screen size, LatBound and LngBounddistances for Google Map with zoom level 6 is about 8 times of those for theone with zoom level 9. Since we just imported part of cities in the worldinto our database, sometimes if we use a map with zoom level 6, there willnot be enough space for us to move around. When we do Experiment IIIB,we set zoom level to be 9, because in that experiment we need to move fora long distance for 40 times. For other experiments, including ExperimentI, II and IIIA, they are done with the zoom level set to be 6. Here, wejust provide and discuss the experiment results for Experiment I, II and

30


Table 4.2: Experiment Configuration for Single Pattern Experiments in LabEnvironment


Experiment Category

Experiment IExperiment IIExperiment IIIAExperiment IIIB

Movement Interval

0ms1000ms2000ms3000ms

Number of Movements 40 stepsZoom Level When we do experiments in Experiment IIIB,

we set zoom level to be 9. For other kinds ofexperiments, they are done with the zoom levelset to be 6.

IIIA. Appendix A.1 covers the related content for Experiment IIIB. Theseadditional experiments for IIIB are not central to the argument of the thesis.

Through those experiments, we will explore the following topics:

Topic 1: PI vs. MIIn Chapter 3, when we introduced Spatial Trend Web Prefetching Model,

we said that there is a prefetching interval for the proxy server to sleep beforestarting another loop of prefetching. To find if find there is some relationshipbetween Hit Rate, Increased Traffic Rate and the ratio between PrefetchingInterval(PI) and Moving Interval(MI), we did Experiment IIIA, since atmost time, users move maps following Pattern III with movement distanceno larger than one bound distance .

According to Figure 4.1 and Figure 4.2, we can conclude that the hitrate and increased traffic rate will change when the ratio between PI andMI changes. Obviously, when the ratio of PI and MI is 1/6, the hit rate willachieve a comparatively high value and increased traffic rate will achieve acomparatively low value. So we choose to set PI to be 1/6 of the latest MIin the following experiments.

One point we need to explain here is about why hit rate decreases, when

31


Figure 4.1: Hit Rate Changes According to Different PI/MI

Figure 4.2: Increased Traffic Rate Changes According to Different PI/MI

32


the rate of PI and MI is less than 1/6, especially when movement interval isless than 1000ms. As we know, if the ratio between PI and MI is becomingless, then more prefetching requests will be sent out to the related mashupserver. Then when movment interval is small enough like 1000ms, therewill be too many requests sent out, which increases pressure for the mashupserver and results in response time being increased (See Table 4.3). Thatis, although we have sent out a lot of prefetching requests, we can not getresponses in time. So hit rate will be less. This kind of phenomena may nothappen in other cases, since our mashup server is just a desktop with lowerhardware configurations.

Table 4.3: Average RT for Un-hit Responses While MI=1000ms

Average RT for Un-hit Responses(PI=MI/5)

Average RT for Un-hit Responses(PI=MI/8)

1351ms 1892ms

According to Figure 4.2, we can conclude as the ratio of PI and MIbecomes smaller, increased traffic rate generally remains stable, that is, tobe increased little. In Figure 4.9, we will see that when the ratio is fixed,increased traffic rate will be determined by movement patterns.

Topic 2: Trend Prefetching vs. No Prefetching vs. AroundPrefetching

Figure 4.3: Response Time for Experiment IIIA while MI=3000ms

33





34


Figure 4.7: Average Response Time35


As at most time, users move maps following Pattern III with movementdistance no larger than one bound distance, from Figure 4.3 to 4.6, we showresponse time for one representative trial of Experiment IIIA. Apparently,if there is a hit for a request, then its response will just cost a very shorttime, no matter which prefetching approach is used.

According to those figures, we also can see that if movement intervalis becoming short, response time will be increased accordingly. See in Fig-ure 4.3, the maximum value for response time for No Prefetching is about1500ms and in Figure 4.5 and 4.6, the responding value is about 1800ms.Also, according to Figure 4.7, the average value of response time is increasedwhile we decrease movement interval.

More importantly, when movement interval is shortened, prefetching ap-proaches may cause big jumps for the responses. This can be found bycomparing Figure 4.3 with Figure 4.6. This also can be proven by the ex-periment data listed in Table 4.4. Apparently, it results in the increaseof the average response time. The reason to cause those big jumps is that:When using short movement interval, those prefetching approaches will sendrequests at a very quick speed, which causes the responding mashup serverto receive a lot of requests in a short time.

Table 4.4: Results for Three Representative Experiment IIIA (MI=0ms)

Experiment Prefetching Ap-proach

Average Re-sponse Time(ms)

Number of responseswhose time is largerthan 1500ms

Experiment 1No Prefetching 1373.975 12Trend Prefetching 592.4 9Around Prefetch-ing

1246.95 11


1161.925 11


978.875 4

36


We can compare the performance of Trend Prefetching and AroundPrefetching by checking their average response time. In Figure 4.7, we cansee the results for both ways are very similar with each other for ExperimentI, since they use the same algorithm for Pattern I. In later figures, we cansee that their hit rate and average response time are similar with each otherin Experiment I. For Experiment II and IIIA, we can see that as movementinterval is decreased, the average response time for Around Prefetching in-creases more than that for Trend Prefetching. Especially, when movementinterval is set to be 0ms, there is a big jump for Around Prefetching, whichis approaching to No Prefetching. Comparatively, the value of average re-sponse time for Trend Prefetching is much less, which demonstrates thatour approach can save time for users. So, although there are big jumps forresponse time of Trend Prefetching, yet the hit rate makes the average valuemuch smaller.

Based on Figure 4.8, we can compare hit rate for Trend Prefetching andAround Prefetching. The graphical changes for the three figures are similarwith each other. When movement interval is large enough, e.g. 3000ms or2000ms, hit rate for those two approaches are almost the same. However,when movement interval becomes shorter, especially when it is 0ms, hit ratefor Around Prefetching will be decreased much more. This can prove thatin these experiments, our approach is better than Around Prefetching onpredicting next steps, especially when movement interval is very short.

According to Figure 4.9, increased traffic rate for both approaches aredifferent according to different movement patterns. We will explain themone by one.

In Figure 4.9 I, for Experiment I, increased traffic rate of Around Prefetch-ing sometimes is the same with or similar to that of Trend Prefetching, Sincethey use the same algorithm for Pattern I.

In Figure 4.9 II, for Experiment II, increased traffic rate of AroundPrefetching is more than that of Trend Prefetching, which is caused bythe policy of prefetching. If maps are moved in a single direction, TrendPrefetching is just to do prefetching for areas next to the current one, whichare not more than 3 times or at most times about 1 or 2 times of the currentscreen. However, for Around Prefetching, we have to prefetch about 9 timesof the current screen for each movement. As a result, increased traffic ratefor Around Prefetching is much higher.

Figure 4.9 III is very similar to Figure 4.9 II: increased traffic rate ofAround Prefetching is more than that of Trend Prefetching. The reasonfor it is: for Trend Prefetching when movement distance is less than onebound distance, a lot of areas that we want to prefetch will duplicate with

37


Figure 4.8: Hit Rates38


Figure 4.9: Increased Traffic Rate39


each other. Since we have the mechanism to check duplicate areas to beprefetched before each prefetching, so the area to be prefetched is much lessthan the model has planned and even less than that for Around Prefetching.

Lastly, we will check if prefetching approaches affect movement time ofGoogle Map, the part related to displaying online maps in mashups.

Figure 4.10: Movement Time for Experiment IIIA while MI=3000ms

Just because of the reason mentioned before, here, from Figure 4.10to 4.13, we just display movement time for one representative trial of Ex-periment IIIA. There is no big difference between movement time for NoPrefetching and that using either of the two prefetching approaches. Theresults for Experiment I, and II are similar to that displayed in Figure 4.10to Figure 4.13. So based on those data, we can conclude both prefetchingapproaches will not adversely affect other parts of map mashups.

Topic 3: How movement pattern and movement interval affect


40




Figure 4.14: Average Movement Time for Experiment III A Series

41


metricsIn these experiments, we considered movement patterns, including move-

ment angles and movement distances, and movement interval as variables.We will check how those factors affect our metrics results.

According to the Figure 4.8 and 4.9, we can know that as movementinterval is decreased, hit rate is decreased. As we know, if movement intervalis decreased, this means the time available for a client to get response isdecreased and this also means that the time available for prefetching serverto send out prefetching requests is decreased, which in turn results in thedecrease of the possibility for requests to get hit. Based on Figure 4.3 toFigure 4.7, we can see that as movement interval is decreased, response timeis increased or even sometimes there are big jumps for it, because of thepressure added and requests jam caused by our prefetching for our mashupserver.

Figure 4.10 to Figure 4.13 tell us when movement interval is decreasedto 0ms, movement time is not stable, which is caused by the bottleneck ofthe performance of Firefox. From Figure 4.14, we can see there is no bigchange for average movement time as movement interval changes.

Now in Figure 4.15, we compare experiment results for different move-ment patterns of Trend Prefetching. According to Figure 4.15 I and III,visual trends for hit rate and average response time remain similar for Ex-periment I, II and IIIA, except for the one when movement interval is setto be 0ms. The results of Experiment II are better than others. The reasonfor it is that: When a map is moved in a single direction with distance lessthan LatBound or LngBound, it is very easy to do prediction by lookingahead one area in the movement direction if the RT/MI is no more than1, otherwise for (RT/MI+1) areas. Then if direction is not changed, it canget hit when we get responses in time. Since the area to be prefetched isnot as much as those for other patterns and it is easier for Pattern II to getresponse in time, so when movement interval is 0ms, its hit rate ranks asthe top one.

Based on Figure 4.15 IV, we also can conclude that when movementinterval is larger than 1000ms, average movement time is very similar witheach other for the three patterns.

Topic 4: Hit Rate vs. PerformanceIn this topic, we want to explore if there is any graphical relationship

between hit rate and performance of Trend Prefetching. Here, we use averageresponse time to represent its performance.

42


Figure 4.15: Metrics Sorted According to Different Move Patterns43


Figure 4.16: Hit Rate vs. Average Response Time44


According to Figure 4.16, we can see that hit rate and average responsetime will follow the same rules: As the movement interval is decreased, hitrate is decreased and then there will be a big jump for average responsetime. Based on the analysis above, we know there are two reasons for it:On one hand, decreased hit rate makes more response times have a highervalue. On the other hand, decreased movement interval causes traffic jamon mashup servers, which in turn makes response time jump higher.

Topic 5: What happens when there is no stress added to theapplication server?

According to Figure 4.17, when there is no stress on CPU and Memory,hit rate for both of Trend Prefetching and Around Prefetching will be no lessthan those when we added some stress to the related mashup server to makeits CPU utilization be 90% and its Memory utilization be 55%. Especially,when movement interval is 1000ms and 0ms, hit rate for Trend Prefetchingis larger than those in Figure 4.8. The reason is simple: When there is nostress for CPU and Memory, then even there are lots of requests sent to themashup server at a sudden, the server has enough resource to handle themand then there will be no big jumps for response time then. At the sametime, we can see that the graphical trends of the two figures are very similarwith each other.

According to Figure 4.19, we can see that average response time for thosetwo approaches has been improved, since there are no big jumps for responsetime and higher hit rate makes more requests to be with less responses time.Accordingly in Figure 4.18, increased traffic rate is increased, since moreresponses can be got by client before movements are finished. In Figure 4-9,some responses can not be got by client or even lost before movements arefinished, which we do not consider as our prefetching traffic. Also, we cansee that the graphical trends of the two figures are very similar with eachother.

4.3.2 Simulation Experiment

To do a simulation experiment, we analyzed possible operations for a userto use Google Map to find some information for a specific area and itssurroundings. We designed the movement route as below:

The map is moved following the mixture of Pattern III, II and I and themovement intervals are a mixture of 2000ms, 1000ms and 0ms. The distancesfor those steps do not exceed the bound in any dimension. The details ofthe mixture are: The first 7 steps follow Pattern III for which movement

45


Figure 4.17: Hit Rates (No Stress on Application Server)

46


Figure 4.18: Increased Traffic Rate (No Stress on Application Server)47


Figure 4.19: Average Response Time (No Stress on Application Server)

48


interval is 1000ms. The next one follows Pattern I with movement intervalto be 0ms. The next 7 steps also follow Pattern III and their movementinterval is 0ms. Then the next 3 steps change to follow Pattern II andthe corresponding movement interval is 0ms. Then the next 7 movementschange back to follow Pattern III and movement interval is 1000ms. Thenext 4 steps will follow Pattern II and movement interval is 2000ms and thelast 2 steps follow Pattern I whose movement intervals are 0ms.

This movement route is designed to simulate how users might moveGoogle Maps to find some specific address: At the beginning, users movevery quickly, since they may be far from their object address. As they ap-proach to the subject, they slow down. So movement interval is short atfirst and then becomes larger. During this process, they may make mistakefor using the mouse so there is some step following Pattern I. Also, theymove following Pattern II and III. At last, they may want to move aroundto see surroundings quickly. So the last steps follow Pattern I or II withshort movement interval.

To make sure there is enough space for us to move around, we set zoomlevel to be 9. So the experiment configuration would be:

Table 4.5: Experiment Configuration for Simulation Experiments in LabEnvironment

Experiment Variables Possible ValueExperiment Category Mixture of Experiment I, Experiment II and Ex-

periment IIIA.Movement Interval Mixture of 0ms, 1000ms and 2000msNumber of Movements 31 steps.Zoom Level 6

According to Figure 4.20, we can see that there is less frequency forTrend Prefetching to have jumps on response time compared with AroundPrefetching. And there are more responses got hit for Trend Prefetching. Soit got higher hit rate and less average response time (See Table 4.6). At thesame time, there are some big jumps for Trend Prefetching in Figure 4.20.The reason for those jumps is that: We set movement interval to be 0mssince 8th step to 20th step, which causes requests to be increased at onceand then in turn results in big jumps of those steps. According to Figure4.21, there is no big difference for movement time.

49


Figure 4.20: Response Time for Simulation Experiment

Figure 4.21: Movement Time for Simulation Experiment

50


Table 4.6: Trend Prefetching vs Around Prefetching for Simulation Experi-ments

Trend Prefetch-ing (Average —STDEV)

Around Prefetch-ing (Average —STDEV)

No Prefetching(Average —STDEV)

Hit Rate % 75 — 3.15 49 — 1.8 N/AIncreased TrafficRate %

292.57 — 28.14 299.08 — 18.71 N/A

Average Re-sponse Timems

364.79 — 16.74 522.7396 — 19.93 1017.9 — 0.68

Average Move-ment Time ms

89.2 — 12.72 85.725 — 11.87 96.175 — 18.05

51


4.4 Results and Analysis for Real World Case

For the real world case, we have carried out both the single pattern experi-ments and simulation experiments. The details will be shown in this sectionand Appendix A.2. For each experiment in this section and Appendix A.2,we have repeated it for at least five times.

4.4.1 Single Pattern Experiments

In the real world environment, we chose Skype-Google Map [19] from realworld ones. This application also is developed on Google Maps. When aGoogle Map is moved, some icons representing skype contacts of the webadministrator will be displayed onto screens. For the real world case, we havedone Experiment II, IIIA and IIIB. Since the application itself sends requeststo cover some around areas of the current screen, so if we do Experiment I,there will be few requests sent out. Then it will make results of experimentnot make sense at all. Here, we just provide and discuss the experimentresults for Experiment II and IIIA. For Experiment IIIB result, please seeAppendix A.

We did Experiment II, IIIA and IIIB using the laptop, which actedas the client in Section 4.3 and is connected to the internet through theprivate subnet of UBC SPL lab. Then the experiment configuration can besummarized as:

During the experiment, we set PI=MI/3 to save some traffic and avoidpossible jumps for response time. Also, we reduced threads in both threadpools to receive connections from browsers and to send prefetching requests,since both ways reduce the increased traffic rate and add less pressure formashup servers but decrease the hit rate, although not very much.

For Experiment IIIA, when movement interval is less than 500ms, aver-age response time is increased a lot. The reason for this situation is that:Although there is a high hit rate for Trend Prefetching, there are also somebig jumps in response time, which makes average response time very big (SeeFigure 4.25). For Around Prefetching, its hit rate is comparatively low andthere are more jumps than No Prefetching. As a result the average valueis also very high. The reason for those big jumps is very complex, whichcan be caused by network traffic jam, and also can be caused by securityprotection on mashup servers or sometimes can be caused by the pressurealready on mashup servers.

Comparatively, for Experiment II, since those areas needed to be prefetchedin Trend Prefetching are less than those for Experiment IIIA, then there are

52


Table 4.7: Experiment Configuration for Single Pattern Experiments of RealWorld Case


Experiment CategoryExperiment IIExperiment IIIAExperiment IIIB

Movement Interval

0ms250ms500ms750ms1000ms2000ms3000ms

Number of Movements 30 steps.Zoom Level When we do experiments in Experiment IIIB,

we set zoom level to be 8. For other kinds ofexperiments, they are done with the zoom levelset to be 6.

53


Figure 4.22: Hit Rates for Real World Case

54


Figure 4.23: Increased Traffic Rate for Real World Case

55


Figure 4.24: Average Response Time for Real World Case

56


not so many big jumps and so average response time for Trend Prefetchingis not higher than that for No Prefetching.

Figure 4.25: Response Time for Experiment IIIA When MI =0ms

4.4.2 Simulation Experiment

We did the simulation experiment by use of the laptop which connectedto the internet through the private subnet of UBC SPL. We suppose theadministrator of Skype - Google Map to drive from the east of the UnitedStates to the west of the United States to travel a half circle of the country.During the process, he wants to visit some of his friends, skype contactsof Skype-Google Map. We simulated him to go through a Google Map tofind the correct way to travel to drop by those friends. The whole processwas recorded by a Greasemonkey script, including those center points ofthe screens and movement intervals. Then during the experiment we re-played those movements with that script. The whole process included 22movements and all of them follow Pattern III and most of those movementintervals are less than 1500ms and half of them are less than 1000ms andlarger than 500ms. The zoom level is 8.

Just like experiments in Section 4.4.1, we set PI=MI/3 to reduce requestsand avoid possible jumps for response time. And, we reduced threads inboth thread pools in the experiment to avoid using too much resource onthe client.

According to Figure 4.26 and Table 4.8, we can see that, hit rate forTrend Prefetching is much higher than that for Around Prefetching. Ac-cordingly, average response time for Trend Prefetching is much less thanthat for Around Prefetching. Figure 4.27 and Table 4.8 show that bothprefetching approaches will not affect movement time.

57


Figure 4.26: Response Time for Simulation Experiment of Real World Case

Figure 4.27: Movement Time for Simulation Experiment of Real World Case

Table 4.8: Trend Prefetching vs. Around Prefetching for Simulation Exper-iment

Trend Prefetch-ing (Average —STDEV)

Around Prefetch-ing (Average —STDEV)

No Prefetching(Average —STDEV)

Hit Rate % 82.61 — 1.54 30.44 — 3.89 N/AIncreased TrafficRate %

152.98 — 2.23 319.8 — 10.17 N/A

Average Re-sponse Timems

205.44 — 11.24 321.39 — 32.13 463.35 — 7.79

Average Move-ment Time ms

150.54— 32.29 152.41 — 23.82 130.5—38.28

58

Chapter 5

Discussion

We discuss factors of the problem domain that complicate web prefetchingfor mashup applications which are related to online maps and discuss futureresearch.

5.1 How Mashup Server Affects Prefetching?

From Chapter 4, we can see that in the lab environment, those metrics lookmuch better than those collected in real world environment. It is becausein lab environment, we have set up a simple and clean environment. In realworld, the situation is much more complex. We just discuss some factorsthat we have found affect prefetching:

The first one is the security mechanism set up on a mashup server, whichwe have mentioned in Chapter 2. Generally, the firewalls or other waysto help protect mashup servers from intrusion or attack may slow downresponses. In fact, this kind of protection will not just affect prefetchingwork in this way, but can also be applied to clients. During the experimentsdescribed in Chapter 4, we found that Kaspersky Anti-Virus 6.0 on ourlaptop blocked or slowed down responses especially when movement intervalis set to be about or less than 1000ms.

Secondly, the performance of the application deployed on a mashupserver can affect response time, which in turn will affect the hit rate ofprefetching. We think a prefetching or caching tool on the mashup servercan help solve the problem. That is, we can provide a tool to help save timeof geting data from database by prefetching related data to the memory ofthe server.

The third factor is about the stress on mashup servers. In Chapter 4,we tried to simulate the load in real world to set CPU utilization to be 90%and memory utilization to be 55%. Then we did experiments when there isno stress on the same mashup server. By comparing the results, we foundthat the stress on the mashup server can affect hit rate, response time andetc.

59

Chapter 5. Discussion

Lastly, we notice that some mashup applications provide different re-sponses based on bounds information sent in a request. For example, infastfoodmaps application [8], perhaps it displays some specific fast foodrestaurants in the current screen when we set zoom level to be 8. Butwhen we send a request with the screen size three times of the currentone, then the response will just include the summary information of somecities to have fast food restaurants but not specific restaurants. While in ourprefetching implementation, to avoid creating too many requests for mashupservers, we just do prefetching for the area whose size is three times of thecurrent screen. Otherwise, response time in real world case will be muchlarger. So if response information varies according to the size of screens,response got from the cache may be not the correct one. Our prefetchingcan not work in this situation. To solve this issue, we can use the aggrega-tion mechanism mentioned in [24] to aggregate separate requests for thoseareas which have the same size of the current screen together on clientsand to aggregate responses for those request on mashup servers. That is,it needs mashup servers to provide the mechanism to analyze and separateaggregation requests and to aggregate responses.

5.2 How Prefetching Affects Response Time?

According to Figure 4.7 and 4.24, we can see that as movement intervalis decreased, average response time while using prefetching approaches willbe increased much more than that without using any prefetching approach.According to Table 4.4, when movement interval is set to be 0ms, there willbe big jumps for response time while using Trend Prefetching. So we canconclude that when movement interval is very short, especially when it ap-proaches to 0ms, prefetching approaches may increase instead of decreasingaverage response time and slow down the displaying of markers.

The reasons are very complex. The first possible reason is the pressurefor mashup servers added by prefetching requests. In the lab environment,when we added pressure to the mashup server, the large amount of requestswould cause bigger latency. While according to Figure 4.19, when we didnot add pressure to the mashup server, average response time would not beincreased as much as that displayed in Figure 4.7. So although the pressurefor the mashup server caused by the prefetching requests is limited, yet whenthere is already enough pressure, it may increase response time a lot.

Another possible reason is security protection on mashup servers, whichhas been mentioned in Section 5.1. When movement interval is shortened

60


to be 0ms, the speed to send out requests will be very quick. Some securityprotection mechanism will take it as attack for mashup servers and begin toslow down those responses, which will increase response time.

Additionally, there may be some other environmental causes for it, suchas, the network traffic added by prefetching requests and responses and soon.

5.3 Factors Causing the Latency of Displaying

Markers

The goal of our web prefetching is to help speed up markers to be displayedonto online maps. As we know, in a Google Maps mashup, after clients getresponses, some Javascript will analyze those responses, create, and thendisplay markers onto Google Maps. So the latency to display those markersincludes two parts: network latency, which refers to response time, and dis-playing time which refers to the time to create markers and display them.Our prefetching tool just focuses on reducing response time. We have nothandled the time to create markers and display them. But sometimes, thisfactor determines whether markers can be displayed quickly. For example,we have checked weatherbonk.com application [21]. All of the icons of mark-ers are loaded remotely when clients display them. It costs a lot of time oreven 1000ms at worst to load and display them. And response time is justabout 500ms. So under this kind of condition, our tool can not improve thespeed of displaying markers very much.

However, we can use some programming techniques to reduce that la-tency: For example, when they design and develop an application, they canmake the responding script to load markers in advance and require clients’browser to cache those icons. Then when clients want to use those icons,they can get them from their cache instead of loading it remotely.

Another possible reason affecting displaying markers is the performanceof the browser. During our experiments process, we found there is bottleneckfor the performance of Firefox. For the same experiment, Firefox costs about80% percent of CPU utilization on my laptop and Safari just costs about50% percent of CPU utilization. Also Firefox costs much more memoryutilization. When movement interval is very short or set to be 0ms, Firefoxcan not display moved Google Maps and we just saw grey color displayed inscreens. And we can not see markers on maps too. However, when we useSafari, we can see the Map and markers displayed in the screen.

61


5.4 Future Work

According to the experiment results, we can see that there are still a lot ofwork needed to be done to improve our prefetching tool, such as to reduceincreased traffic rate; to improve hit rate while the movement interval isshort and to consider other factors to improve the performance of mashupsand etc.

Currently we cache all responses prefetched, which waste a lot of memoryof clients. In the future we would provide a mechanism for cache replace-ment.

Also, we should do further analysis for the performance of mashups whenmovement interval is less than 1000ms. For example to simplify the factorswhich will affect the prefetching results, perhaps we can download the wholeGoogle Map locally, which will reduce the effect caused by latency of GoogleMaps.

Our prefetching tool is based on the assumption that every user wouldfollow some pattern to use online maps. Also, we assume that once a userfollows some pattern, generally he will not change it at once. However, in realworld, move patterns may be much more complex than those assumptions.So we need more analysis on users’ usage history information and thenprovide better prediction. For example, we can try to use some machinelearning knowledge and artificial intelligence knowledge to help improve ourapproach by predicting the possible area with higher possibility and alsoin a smaller range. Then both hit rate and increased traffic rate can beimproved. Since fewer requests are sent out to mashup servers, there will beless big jumps for response time.

Also, we can consider other factors mentioned above which affect ourprefetching. For example, we can set up another prefetching tool on amashup server, which can do prefetching from databases and then cacheresponses which are used most frequently by clients in its memory. Thenit will save a lot of time to do search again from databases. Accordinglyresponse time will be improved. Another example, on clients, we also cananalyze Javascript loaded and do some modification by use of some Grease-monkey script to load some picture or icons related to markers in advance.Then we can save a lot of time to display markers.

Additionally, until now, all of the experiments are done in cable networkenvironments. We have not evaluated our prefetching tool in a wirelessenvironment. As more and more mashup applications have been developedfor mobile or wireless environment, there is such need to make it to beapplied in this kind of environment. Since there is big difference on the

62


speed between cable network and wireless one, so perhaps, this will needhigher efficiency for our approach to be able to cause less increased trafficrate while maintaining a reasonable hit rate.

In this thesis, we have only tried to support applications using the HTTPprotocol. However, applications such as Google Maps might be supportedbetter in the future by streaming protocols or other more efficient protocols,since the Map should respond to user input in soft real-time. For example,perhaps we can use Comet protocol [4] to improve the performance.

63

Chapter 6

Conclusion

More and more mashup applications are developed on online maps, such asYahoo! Map and Google Map. They try to merge some specific informationtogether with online maps application to provide a new kind of service forusers. Those services are very attractive. But sometimes markers will bedisplayed very slowly, which is caused by network latency.

In this thesis, we have presented an approach, which is deployed onclients, to improve the performance of related applications by reducing net-work latency for those responses. In this approach, we use Spatial TrendWeb Prefetching Model to predict the areas which can be possibly arrived atafter next movements. We classified movements into three patterns. Thenthis model will check history operations done by a specific user, find possiblepatterns he may be following and then predict next possible operations forthe user according to the specific algorithm responding to that pattern. Ac-cording to our evaluation, we can see that our approach can achieve hit rateof about 85% when movement interval is not less than 1000ms and largerthan 30% when movement interval is less than 1000ms in our experiments.

Although there are still some issues in our approach, e.g. there maybe some big jumps for response time when there is no hit in real worldcase experiment, we analyzed them and try to provide possible solutions forthem.

64

Bibliography

[1] D.L. Applegate, R.E. Bixby, V. Chvtal, and W.J. Cook. The Travel-ing Salesman Problem: A Computational Study. Princeton UniversityPress, 2006.

[2] V. Cerny. A thermodynamical approach to the travelling salesmanproblem: an efficient simulation algorithm. Journal of OptimizationTheory and Applications, 45:41–51, 1985.

[3] http://code.google.com/apis/maps/.

[4] http://cometdaily.com/.

[5] C. du Mouza and P. Rigaux. Web architectures for scalable movingobject servers. In the 10th ACM international symposium on Advancesin geographic information systems, pages 17–22, 2002.

[6] A. Eden, B. Joh, and T. Mudge. Web latency reduction via client-sideprefetching. In Proc. 2000 IEEE Int. Symp. on Performance Analysisof Systems & Software ISPASS − 2000, pages 193–200, 2000.

[7] Max J. Egenhofer. Spatial sql: A query and presentation language.IEEE TKDE, 6-1, 1994.

[8] http://www.fastfoodmaps.com.

[9] http://www.geonames.org/export/.

[10] http://www.geocoder.us.

[11] Chia-Hsin Huang, Tyng-Ruey Chuang, Dong-Po Deng, and Hahn-Ming Lee. Efficient gml-native processors for web-based gis: Tech-niques and tools. In 14th International Symposium of ACM GISAdvancesinGeographicInformationSystems, November 2006.

[12] Thomas M. Kroger, D. E. Long, and J.C. Mogul. Exploring the boundsof web latency reduction from cacheing and prefetching. In Proceedings

65

Bibliography

of the Symposium on Interworking Systems and Technologies, pages13–22, December 1997.

[13] BenJamin Livshits and Emre Kiciman. Doloto: Code splitting fornetwork-bound web 2.0 applications. Technical report, Microsoft Re-search, 2008.

[14] http://www.unixguide.net/hp/faq/7.1.2.3.shtml.

[15] V.N. Padmanabhan and J.C. Mogul. Using predictive prefetching toimprove world wide web latency. Computer Communications Review,26:22–36, 1996.

[16] http://www.utd.edu/ilyen/course/web/yanlou.ppt.

[17] http://www.ics.forth.gr/carv/r-d-activities/wwwPerf/INET98 prefetch/.

[18] http://www.programmableweb.com.

[19] http://www.voidstar.com/skymap/.

[20] N. Swaminathan and S.V. Raghavan. Intelligent prefetch in www us-ing client behavior characterization. IEEE International Symposium onModeling, Analysis, and Simulation of Computer and Telecommunica-tions Systems MASCOTS′00, page 13, 2000.

[21] http://www.weatherbonk.com/.

[22] http://en.wikipedia.org/wiki/Mashup web application hybrid/.

[23] http://www.w3.org/MarkUp/html3/overlays.html.

[24] K.C. Yeung and P.H.J. Kelly. Optimising java rmi programs by com-munication restructuring, in: Proceedings of the middleware 2003.Springer Verlag, pages 324–343, 2003.

[25] Junli Yuan, Qibin Sun, and Susanto Rahardja. Server-assisted prefetch-ing for internet streaming media delivery. In Multimedia Systems andApplications IX, SPIEs International Symposium on Optics East 2006,October 2006.

66

Appendix A

Algorithm, Results andAnalysis for Pattern IIIB

A.1 Algorithm

If one of the formulas 3.13 and 3.14 in Chpater 3 is not true, then thenext rows and columns could not cover the steps, since those steps havemove out of that prefetched areas. Then we have to calculate the properareas to be prefetched by use of LatDistanceP in latitude dimension andLngDistanceP in longitude dimension. Then we have to calculate the properareas to be prefetched by use of LatDistanceP in latitude dimension andLngDistanceP in longitude dimension. Prefetching will be done startingwith the row or column area in the main direction, whose distance fromthe current one is LatDistanceP in latitude dimension and LngDistanceP inlongitude dimension.

For example, in Figure A.1, suppose the map is moved from the centerof Area 21 to that of Area 13 and there is a big change for the movementdistance although it also follows Pattern III A, then we will do prefetching forthe column with Area 13 for the 1st look-ahead step and then do prefetchingfor the one with Area 20 for the 2nd loop-ahead step.

To improve the hit rate, we are not limited to doing prefetching for thecolumn in the main direction. We will also do prefetching for the columnnext to the predicted column in the opposite direction, since sometimes userswould reduce movement distance at once.

A.2 Results and Analysis for Experiment IIIB inLab Environment

In the experiments done in lab environment mentioned in Chapter 4, wehave got the results shown in following Figures.

Figure A.2 I seems very different from those three ones in Figure 4.8: hitrate for Around Prefetching is 0% in the experiments no matter how long

67

Appendix A. Algorithm, Results and Analysis for Pattern IIIB

Figure A.1: Pattern IIIB Prefetching

68


Figure A.2: Experiment Results for Experiment IIIB in Lab Environmentwith Stress on Mashup Server 69


movement interval is set to be. The reason is that: For Around Prefetching,we just do prefetching for areas around the current screen. If movementdistance is longer than LatBound or LngBound, we can not get a hit, sincewe have move out of those around areas.

In Figure A.2 I, as we can see when movement interval is decreased, hitrate for Trend Prefetching is decreased a lot. This can be explained by thedesign of the experiment. For Experiment I, II and IIIA, all of them is donewhile setting zoom level to be 6. Then its LatBound is 8.42 and LngBoundis 10.98 in our application. For Experiment IIIB, when we set zoom level tobe 9, its LatBound is 1.05 and LngBound is 1.37. Obviously, the previousone can cover much more possible areas than the later one. So it is mucheasier for requests in the one with zoom level to be 6 to get a hit. For thelater one, it can not prefetch proper areas for the 1st look-ahead step butmay get them for several steps. So when movement interval is long enoughfor it to do prefetching for several steps, then it will get a high hit rate.When movement interval is decreased, and there is no such chances andaccordingly, hit rate will be decreased a lot.

In Figure A.2 III, when movements follow Pattern III and movementdistance is more than one bound distance in at least one of the dimensions,increased traffic rate of Around Prefetching is much less than that of TrendPrefetching. Just as what we have said in above paragraphs, to make sure hitrate to be acceptable, if there is enough time, Trend Prefetching approachwill prefetch for several steps in main direction, each of which will add about10 more areas to be prefetched. As movement interval is decreased, area tobe able to be prefetched becomes smaller. So when movement interval islarge enough, increased traffic rate for Trend Prefetching is much larger andit will be decreased to be almost the same with that for Around Prefetchingwhen movement interval is 0ms.

A.3 Results and Analysis for Real Case

Experiments

Based on Figure A.3, we could see that the results for Experiment IIIBfollow similar graphical trend as those in Figure A.2, except that: comparedwith results displayed Figure A.2 III, increased traffic rate seems to be muchlower for both prefetching approaches. The reason is that: For some areas,responses of Skype-Google Map are very short, since there are no skypecontacts living in that area.

70


Figure A.3: Experiment Results of Experiment IIIB for Real World Case

71

Spatial Trend Prefetching for Online Maps Mashupsmashups related to online maps are comparatively...

Documents

Transcript of Spatial Trend Prefetching for Online Maps Mashupsmashups related to online maps are comparatively...