Adopting cloud computing to optimize spatial web portals for better performance to support Digital Earth and other global geospatial initiatives

Abstract

A spatial web portal (SWP) provides a web-based gateway to discover, access, manage, and integrate worldwide geospatial resources through the Internet and has the access characteristics of regional to global interest and spiking. Although various technologies have been adopted to improve SWP performance, enabling high-speed resource access for global users to better support Digital Earth remains challenging because of the computing and communication intensities in the SWP operation and the dynamic distribution of end users. This paper proposes a cloud-enabled framework for high-speed SWP access by leveraging elastic resource pooling, dynamic workload balancing, and global deployment. Experimental results demonstrate that the new SWP framework outperforms the traditional computing infrastructure and better supports users of a global system such as Digital Earth. Reported methodologies and framework can be adopted to support operational geospatial systems, such as monitoring national geographic state and spanning across regional and global geographic extent.

Keywords:

• CyberGIS/WebGIS
• GeoPortal
• spatial cloud computing
• spatiotemporal thinking and computing
• GEO
• national geographic state

1. Introduction

The advancement of Earth observation (EO) dramatically increases our capability in acquiring geospatial data for building Digital Earth. To store, manage, and publish the explosively growing data, a variety of spatial data infrastructure (SDI; Maguire and Longley 2005) components have been developed. However, sharing and access of geospatial resources remain impeded by the isolation of SDIs. To foster interoperation, integration, and access of geospatial resources, different organizations proposed spatial web portals (SWPs), including Geospatial Platforms, Geospatial One-Stop (GOS), NASA SWP, and the Intergovernmental Group on Earth Observation (GEO) Portal (Yang et al. 2007; Xu et al. 2011; Goodchild, Fu, and Rich 2007). An SWP enables the integration and interoperation of geospatial resources through various protocols/Application Programming Interfaces (APIs) such as Open Geospatial Consortium (OGC) Catalogue Service for the Web (CSW; Nebert 2007), Web Accessible Folders (WAF 2013), and Really Simple Syndication (RSS), and these facilitate geospatial resource access by providing an integrated web interface with a built-in resource search engine.

Driven by the increasing demands of geospatial resources in the past few years, SWPs have matured with the advancement of enabling technologies. However, developing and operating an SWP are challenging due to the following computational intensities and spatiotemporal dynamics: (1) computing intensity due to the complexity of spatiotemporal data structure, query, and processing; (2) concurrent intensity due to millions of end users; (3) communication intensity due to massive interoperations among SWPs and geospatial resources (Gui et al. 2013); and (4) spiking workloads from spatiotemporal distribution of globally distributed end users. These challenges preclude SWP from interoperating large-scale geospatial resources and supporting fast resource access for end users to receive responses in seconds (Nah 2004). To address these challenges, SWP providers utilize significant computing resources, including cutting-edge hardware and network/computer clusters which are costly and inefficient in a traditional computing fashion (Berl et al. 2010).

Cloud computing is an emerging computing paradigm for end users to utilize virtualized computing resource through the Internet and provides unique features such as on-demand resource pooling, rapid elasticity, broad network access, reliability, and economy (Buyya et al. 2009; Mell and Grance 2011; Vaquero et al. 2008; Yang et al. 2011a). The ‘pay-as-you-go’ service model releases users from upfront cost for purchasing, hosting, configuring, and managing computing infrastructure, a perennial dream of distributed computing (Armbrust et al. 2010). Many organizations (e.g. Adobe Systems and Netflix) migrated their traditional computing facilities to the cloud (Amazon 2013; Azure 2013) with proven cost and energy efficiencies (Lee and Chen 2010; Marston et al. 2011). The wide adoption of cloud computing drives the fast growth of both public cloud, such as Amazon Elastic Compute Cloud (EC2) and Windows Azure (Azure), and private cloud, such as Eucalyptus, Cloudstack, and NASA Nebula.

The advancement of cloud computing offers a powerful and affordable computing solution for scientific studies, most notably for geosciences, that require massive, scalable, and reliable computing resources (Yang, Xu, and Nebert 2013). Various studies have been carried out to utilize cloud services for geoscience data sharing, data processing, and modeling (Bürger et al. 2012; Evangelinos and Hill 2008; Guan et al. 2013; Huang et al. 2013; Lee and Liang 2011; Li, Zhang, and Yu 2011). As a computing-, concurrent-, and communication-intensive application, SWP requires elastic and broadband network, which can be provided by cloud services. For example, EC2 provides high-performance instance with two quad-core processors, 23-GB memory and 10-Gbps network connection. In addition, cloud services provide a number of functions (e.g. workload balancing, auto-scaling) that could potentially improve SWP performance for global users. Therefore, cloud computing is a potential solution to better support SWP by addressing the challenges.

This paper studies the feasibility of using cloud computing to support SWP. A cloud-based framework for SWP is proposed to integrate several cloud features in support of the SWP operation. More specifically the following are proposed: (1) elastic resource pooling to ensure SWP provision or release of computing resource for efficient handling of complex geo-processing and dynamic user workloads; (2) workload balancing to help SWP accommodate massive concurrent access by scheduling user requests to multiple SWP instances; and (3) global deployment to assist SWP to distribute instances across different geo-locations thereby optimizing communications with end users, third-party SWPs, and geospatial resources.

2. Related research

2.1. Existing SWPs for geospatial resource interoperation and access

Over the past two decades, various SDIs and SWPs have been developed for managing geospatial resource. For example, NASA's Global Change Master Directory (GCMD) (Miled et al. 2001) is one of the largest geospatial resource catalogs managing more than 29,000 EO dataset and services for global change and Earth sciences (NASA GCMD 2013). The intergovernmental GEO designed a Global Earth Observation System of Systems (GEOSS) Common Infrastructure to facilitate sharing GEOSS data. The GEOSS Clearinghouse (CLH) (Liu et al. 2011), Component and Service Registry, and GEO portal are the three components of the GEOSS Common Infrastructure providing resource catalogs, resource registry, and access portal. The US government hosts the GOS as a single portal for federal geospatial resource. Ocean Data Portal (Reed et al. 2010) provides marine data hosted by the National Oceanographic Data Centres (NODCs). Finally, the Geospatial Platform (FGDC 2013) offers access to geospatial resources.

With increasing geospatial resources and SWPs, the communications of SWPs are increasingly intensified because SWPs frequently communicate with third-party SWPs for resource integration. In addition, more end users are engaged with SWPs and result in a significant growth of concurrent requests. Hence, an optimized SWP framework for communication and concurrent intensity is needed.

2.2. Improving SWP performance

For the high-speed access requirement of SWP, various technologies have been proposed. Wang and Liu (2009) offered a service-oriented framework for parallel and distributed processing. Various workload-balancing mechanisms are proposed for scheduling end user requests for different SWP duplications (Bunt et al. 1999; Huang et al. 2011). An index mechanism improves query performance by reorganizing data into a structured manner (Güting 1994). Specifically, a number of text-based, spatial, and spatiotemporal indices speed up access to geospatial resources (Guttman 1984; Beckmann et al. 1990; Theodoridis et al. 1996; Pfoser, Jensen, and Theodoridis 2000). Storage and file models, such as Hadoop Distributed File System (HDFS 2013) and Galileo (Malensek, Lee Pallickara, and Pallickara 2013), were used to optimize SWP I/O performance (Liu et al. 2009). Finally, a cache mechanism pre-fetches frequently queried data into memory to reduce SWP response time (García Martín et al. 2013; Li et al. 2012).

Many computing resource provision and allocation mechanisms provide on-demand access. For example, Röme (2010) offered a threshold-based computing resource provision mechanism that automatically adds computing nodes to the cloud when the resource utilization rate exceeds a predefined threshold. This threshold-based strategy releases computing resources when the resource utilization is low (Maheshwari, Nanduri, and Varma 2012). Chaisiri, Lee, and Niyato (2012) proposed a provision mechanism to minimize the total cost by using stochastic integer programming.

Although some of these approaches have been adopted by SWPs, more effort is required to integrate the approaches into traditional computing infrastructure. In addition, current SWP technologies and framework seldom consider the spatiotemporal distribution of workloads, using traditional computing infrastructure for dynamic computing requirements. Computing resources usually cannot be provisioned on demand for spiking access (Lee and Chen 2010).

2.3. Cloud evaluation and adoption for Digital Earth and geosciences

Multiple studies have tested the feasibility of cloud service in supporting scientific research. For example, Kim et al. (2009) discussed several issues impeding the adoption of cloud computing in the sciences, including risk of electric outage, security, and performance overheads. Ostermann et al. (2010) tested the performance of cloud services by analyzing computation, I/O, memory hierarchy, and reliability of five virtual machine (VM) types provided by EC2. And, Iosup et al. (2011) utilized several benchmarks including LMbench (Barham et al. 2003), Bonnie (Kowalski 2013), and HPCC (Luszczek et al. 2006) to evaluate the performance of four commercial cloud services: EC2, GoGrid, ElasticHosts, and Mosso. These evaluations showed that the cloud offers untapped potential for scientific research.

In the geosciences, cloud services support scientific processing and analysis functions. For example, Bürger et al. (2012) proposed a cloud-based hydrologic simulation by utilizing hydrology and visualization packages pre-installed in cloud services. Cloud service has been applied to large-scale spatial data. Lee and Liang (2011) proposed a cloud-based, geo-location data service – Geopot – for location-based mobile applications, and Amazon Simple Storage Service (Garfinkel 2007) was used for large spatial data management. Cloud services were also used in geo-science models. Evangelinos and Hill (2008) adopted EC2 to enable computability of coupled atmosphere–ocean climate models. Cost-saving instances can be utilized to execute climate models while the performance is comparable to low-cost cluster systems. Huang et al. (2013) developed a set of methods to leverage a large group of computing resources in minutes to accelerate large-domain dust storm forecasting. Cloud services also enable high-performance data processing for computing and data-intensive applications. Guan et al. (2013) integrated the cloud service to a data-processing framework, providing performance gain for intensive data processing. Li, Zhang, and Yu (2011) proposed a cloud-based framework for intensive floating car data (FCD) processing. The EC2 and cloud techniques (e.g. Chang et al. 2008; Dean and Ghemawat 2008) address the data intensity problem inside FCD processing. Esri also started to investigate cloud computing for supporting its ArcGIS online and Geoportal products.

These studies offer best practices for utilizing virtualized resource within cloud computing to support Digital Earth and geosciences. However, major benefits of cloud service (e.g. elasticity, workload balancing, and distribution) have not been realized, especially for SWPs. No technical documents and research can be found from Google Scholar, Scopus, or Science Citation Index (SCI) as of April 2014 about how to best leverage cloud computing characteristics to support the global operation of SWPs. This paper fills this literature gap by systematically studying how to best utilize cloud computing for SWPs.

3. Methodologies

3.1. The SWP architecture and workflow

SWP architecture and workflow (Figure 1) illustrates two major functions of integrating widely distributed geospatial resources and supporting user access. First, the SWP Resource Crawler and Monitor communicates with existing geospatial resources and third-party SWPs to do the following: (1) register or update the latest data, metadata, services, and applications; (2) monitor and retrieve real-time service and data quality; and (3) enable remote access for third-party SWPs. Second, end users access the SWP through the following workflow: (1) end users send requests through the SWP web client; (2) requests transferred from the client to the SWP server through global networking; (3) SWP search engine parses requests and (4) queries against the SWP database; (5) SWP search engine organizes (e.g. filtering and ranking) raw query results and (6) transfers results to the SWP client; and (7) SWP client visualizes results for the end users.

Figure 1. Concurrent, computing, and communication intensities in SWP.

The workflow has the following characteristics:

1. Computing intensity: data querying, indexing, updating, and converting are time consuming, especially for the fast-growing big data. The complexity of spatiotemporal data structure and spatiotemporal query process increases computing intensity.

2. Concurrent intensity: popular SWPs receive 10s to 1000s of concurrent user requests. An SWP needs to go through the entire request/response process for each user. Factual workloads usually contain sudden increases of concurrent access or spiking workload (Bodik et al. 2010) because some events (e.g. natural hazards, disease spreading, and elections) cause an explosive growth of access to geospatial resource.

3. Communication intensity: to integrate widely distributed geospatial resources, SWP intensively communicates and monitors massive SDIs, services, and third-party SWPs. The communication and concurrent intensities result in SWP performance degradation, such as slow response, network congestion, and system failure.

4. Global Access: while SWP supports user access internationally through the Internet, some users experience slow responses because their requests and responses go across intercontinental network. For example, the distributions of the CLH (Liu et al. 2011) end users, geospatial resources, and the system servers are dynamic (Figure 2). The SWP in the USA may have slow responses to users in Europe and Asia. The SWP and geospatial resource distribution also result in large volumes of data transfer over intercontinent networking. In addition, misleading service performance information may be delivered to users in different regions if services are integrated and monitored from a single location (Yang et al. 2011b).

Figure 2. The distribution of SWP end users and geospatial resources across the world.

3.2. Cloud-enabled framework

To address these challenges, a cloud-enabled framework to facilitate SWP operation is proposed (Figure 3). The framework includes three components: (1) cloud workload balancer for managing user access workload; (2) elasticity manager to support automatic computing resource provision; and (3) deployment manager for optimizing SWP utility in a global cloud environment. The three components deploy, auto-scale, and balance the workload for SWP instances hosted in the cloud resource pool. Each component communicates with each other to monitor the latest status of user workload, SWP instance distribution, and resource utilization. Each of these components is discussed in more detail.

Figure 3. Cloud-enabled framework for SWP.

Cloud workload balancer (Figure 4) automatically distributes end user requests to multiple SWP instances to reduce the response time, handle larger number of concurrent requests by utilizing multiple SWP instances, and achieve greater fault tolerance. Within the framework, multiple SWP instances are provisioned from the cloud resource pool supported by elasticity manager, and these instances are distributed in different cloud service regions by the deployment manager. These SWP instances are configured to provide a single SWP access end point (domain name). The instance detector periodically detects SWP instance status (e.g. CPU, memory and disk utilization rate, instance location, network traffic, and mean response time). The workload distributor forwards end user requests to different SWP instances based on location and status of current instances. Requests are forwarded to an SWP instance with less workload and an instance proximal to the end users. The pseudocode for the load balancing is based on Algorithm 1 which starts with the initialization of SWP instances in different cloud regions (LB2). For every user request, the workload distributor calculates the network distance from the request location to every existing cloud region (LB3, LB4, and LB5) and forwards the request to the region with shortest distance (LB6). Every instance in this targeted cloud region is checked by the instance detector. If the instance reaches a healthy state (Amazon Health Check 2013), the current instance workload is recorded (LB9), and the request is forwarded to the instance with least workload (LB12). Otherwise, the instance is isolated from the load-balancing process until its health state is restored (LB11).

Figure 4. Cloud workload balancer architecture.

Algorithm 1. SWP load balancing in the cloud.

LB1:	Begin
LB2:	initialize multiple SWP instances in different cloud regions
LB3:	for (every incoming request)
LB4:	for (every cloud regions)
LB5:	calculate network distance from the user request to each region
LB6:	forward the request to the region with shortest distance
LB7:	for (every SWP instance in the region)
LB8:	if (instance reach healthy state)
LB9:	monitor workload of the instance
LB10:	else
LB11:	isolate unhealthy instance
LB12:	forward the request to the instance with least workload
LB13:	End

The elasticity manager (Figure 5) enables the automatic provision of computing, storage, and network resources in two directions: scaling SWP instance configurations (e.g. CPU core number and memory size) on-the-fly to meet the computing demand and scaling to increase or decrease the number of SWP instances for the cloud workload balancer. The elasticity executor provisions and releases cloud resource based on predefined auto-scaling rules. To determine when, where, and how much computing resource needs to be provisioned/released, the elasticity monitor communicates with the workload balancer and deployment manager to analyze the spatiotemporal distributions of users and cloud resources. The pseudocode for a threshold-based SWP auto-scaling algorithm (Algorithm 2) starts at the beginning of every monitoring time interval (e.g. every minute) (AS2) and runs until the auto-scaling function terminates (AS11). For every SWP instance (AS4) in all different cloud regions (AS3), the elasticity monitor collects information of the instance such as CPU, RAM and network utilization, user request number, and response time. If a scaling-up threshold is reached (e.g. number of request > 100 and the average response time > 6 seconds for the last three time intervals) and the number of current SWP instance less than the maximum instance number (AS6), the elasticity executor scales up an instance in the current cloud region (AS7). If a scaling-down threshold is reached (e.g. CPU utilization < 30% for the last four time intervals) and the number of current SWP instance greater than the minimum instance number (AS8), the elasticity executor scales down an instance in the current cloud region (AS9). The algorithm moves to the next time interval (AS13) until the auto-scaling function terminates (AS11).

Figure 5. Elasticity manager architecture.

Algorithm 2. Threshold-based SWP auto-scaling in the cloud.

Input:	monitoring time interval; scaling up threshold; scaling down threshold; Max (the maximum SWP instance number); Min (the minimum SWP instance number)
AS1:	Begin
AS2:	while (at the beginning of a time interval)
AS3:	for (every cloud region in the cloud)
AS4:	for (every SWP instance in the cloud region)
AS5:	Monitor SWP instance;
AS6:	if (reach scaling up threshold and SWP instance number < Max)
AS7:	Execute scaling up at current cloud region;
AS8:	if (reach scaling down threshold and SWP instance number > Min)
AS9:	Execute scaling down at current cloud region;
AS10:	if (reach termination condition)
AS11:	Exit;
AS12:	else
AS13:	Move to the next time interval;
AS14:	End

Deployment manager optimizes SWP instance distribution by performing global configurations. Most cloud service providers have multiple data centers (cloud regions) across the world. By utilizing this cloud service feature as well as leveraging spatiotemporal principles (Yang et al. 2011b), the deployment manager helps the SWP gain location advantage by collocating SWP instances, end users, and geospatial resources. The deployment manager also enables SWP to provide location-specific (Yang et al. 2011b) service performance information to global users by monitoring performance from different geo-locations. The pseudocode for global deployment algorithm (Algorithm 3) starts at the beginning of every monitoring time interval (e.g. daily) and runs until the global deployment function terminates (GD13). The deployment manager calculates the distance (physical and virtual) from end users to each cloud region. If a cloud region threshold is reached (e.g. >800 users at >4500 km from the closest cloud region) and a closer cloud region is available, the deployment manager adds a new cloud region (GD7). An initial number (e.g. five) of SWP instance deploys to the new cloud region (GD8). If a dropping cloud region threshold is reached (e.g. number of users in the current region <500), the deployment manager terminates all SWP instances in this region (GD10) and drop this cloud region (GD11). Algorithm 3 moves to the next time interval (GD15) until the auto-scaling function is terminated (GD13).

Algorithm 3. Threshold-based SWP global deployment in the cloud.

Input:	monitoring time interval; adding cloud region threshold; dropping cloud region threshold; initial instance number in a cloud region
GD1:	Begin
GD2:	while (at the beginning of a time interval)
GD3:	for (every cloud region in the cloud)
GD4:	for (every end user location)
GD5:	calculate distance from user to each cloud region;
GD6:	if (reach add cloud region threshold)
GD7:	add a new cloud region;
GD8:	deploy an initial number of SWP instance in the new cloud region;
GD9:	if (reach drop cloud region threshold)
GD10:	terminate all SWP instances in droppable cloud regions;
GD11:	drop cloud regions;
GD12:	if (reach termination condition)
GD13:	Exit;
GD14:	else
GD15:	Move to next time interval;
GD16:	End

4. Experiments and results

Four experiments are conducted to evaluate the performance of the cloud-enabled framework as follows: (1) comparison of cloud services and traditional servers to test the readiness of virtualized computing resources; (2) computing resource pooling and workload balancing to test the performance of cloud-enabled SWP in handling computing and concurrent intensity; (3) the elastic provision of computing resources for SWP to test how cloud service helps SWP handle dynamic workloads; and (4) cloud-enabled deployment of SWP to test the performance of SWP in supporting global users.

4.1. Experiment application and environment

The NASA SWP (http://wms.gmu.edu/SWPortalBing) is a web-based spatial gateway for discovering, aggregating, managing, and presenting geospatial resources (Xu et al. 2011). To provide fast access, several performance-improving technologies (Section 2.2) were adopted. For example, an Apache Lucene (2013) index and a spatial index were used by Liu et al. (2011) for fast data retrieval. A server-side cache was implemented and managed by MySQL (2013). A traditional computing cluster was utilized for application hosting. To further improve the SWP performance, the cloud-enabled framework was adopted by implementing elastic resource pooling, workload balancing, and global deploying functions provided by EC2, Azure, and NASA Nebula.

The experiment was conducted on three cloud services and a traditional server located at different geographic regions with different computing and network configurations. The geographic locations of the experimental facilities where EC2 was located were Reston Virginia, Azure (Chicago, Illinois), and NASA Nebula (Ames, California; Figure 6). The traditional server was hosted at Fairfax, Virginia. Three cloud services and the traditional server were connected via the National LamdaRail. The global deployment experiment was supported by four data centers in three continents (North America, Europe, and Asia) hosted by Azure. In order to minimize the impact of different hardware configurations, VMs were chosen with the closest hardware configurations to the traditional server (two CPU cores and 8 GB memory) based on available VM types (Table 1).

Figure 6. Geographic locations of the three cloud services and the traditional server.

Table 1. Configurations of VMs and the traditional server.

	Instance type	CPU cores/unit	Memory (GB)
Azure	Large	4	7
EC2	Large	4	7.5
Nebula	Large	8	16
Traditional server	N/P	2	8

4.2. SWP performance across different cloud services

This set of experiments compares the performance of three cloud services to a traditional server in supporting SWP (Figure 7). The SWP instances and clients were installed and configured on VMs using different cloud services and the traditional server. Different numbers of concurrent spatial query requests were sent from clients to SWP instances in different cloud services (Figure 8 a–d). To reduce the impact of noise in dynamic network environment, the following sets of experiments are repeated 50 times to calculate the mean performance (e.g. mean response time).

Figure 7. Test scenarios across cloud services (adapted from Yang et al. 2014, Chapter 12, Section 12.3.3).

Figure 8. The SWP response time on cloud and traditional server.

In order to determine either to use the distributions of response time or to use the average response time for performance measurements, two boxplot charts are used to present the results of EC2 to Azure (Figure 8e) and the results of EC2 to local server (Figure 8f). In general, response times are very stable, although some request instances are far from mean values (maximum and minimum). The upper quartile and lower quartile are very close to the median and mean values, and most instances (>86%) are distributed within the mean ± standard deviations (SD). Therefore, we use average value to represent the general performance of SWP in the following experiments for best presenting the performance difference.

The results suggest three patterns. First, better hardware and network configuration commonly yield a shorter response time. The NASA Nebula provided the best performance because it had the best computing configuration and a stable network environment (private cloud). The EC2 had the second best performance, followed by Azure, and the traditional server. Second, cloud services and the traditional server provide similar performances in supporting SWP. Although the results were affected by different hardware configurations, no significant overheads were found from the virtualized computing resources in supporting SWP. Third the distribution of end user requests and cloud services impacts SWP performance: closer distance (geographic and network between users and services) results in a shorter response time. For example, it took ∼24 seconds for an EC2-hosted SWP to respond to 400 concurrent requests (requested from Azure), whereas only 18 seconds if requests were issued from EC2. In addition, passing request/response across long network distances usually results in a performance fluctuation because of the dynamic network environment. For example, fluctuations are found by issuing requests from three cloud services to traditional server while fluctuation is dampened if requests are issued from the traditional server to itself.

4.3. Resource pooling and load balancing

The following experiments investigate how the cloud-enabled SWP handles computing and concurrent intensity by leveraging large computing resource pool and balancing workload. Different numbers of SWP instances were launched from cloud resource pool (1, 2, and 5 instances) to function as an SWP URL end point (supported by cloud workload balancer) for responding to different numbers of concurrent requests.

From the results, five patterns demonstrate the performance of load balancing-enabled SWP end point. First, the mean response time of SWP was reduced by adopting resource pooling and load balancing with both Azure (Figure 9a) and EC2 (Figure 9b). Second, on average, the SWP achieved better performance with more computing resource (e.g. more SWP instances) for both Azure and EC2. Third, the mean response time was not consistently proportional to the amount of cloud computing resource. For example, it took ∼18 seconds for an Azure-hosted SWP to respond to 400 concurrent requests with one instance (Figure 9a), while the response time was 13 seconds when using two SWP instances. Thus, increasing the instance number may not always improve the performance. Four, the EC2 performed better than Azure with either a single instance or two instances for workload balancing. However, Azure performed better when using a larger number of load-balancing instances. For example, when SWP instance number was increased to five, the mean response time for an Azure-hosted SWP was ∼2.4 seconds with 400 concurrent requests, while the mean response time for EC2 was ∼6.5 seconds. Five, the mean response time increased 120% when the workload in each SWP instance increased 100%, but this relationship varied among cloud services. These results provide general guidance for SWP owners for choosing proper load-balancing configurations (e.g. the number of instances and different cloud services) to support fast user response.

Figure 9. The SWP mean response time as a function of the concurrent request number with the support of the cloud workload balancer.

4.4. Handling dynamic workload

These experiments investigate how cloud-enabled SWP handles dynamic workloads. The first experiment was similar to that in Section 4.3 except that this experiment implemented an auto-scaling rule as follows: (1) when the average response time > 6 seconds, the SWP elasticity manager automatically provisions a new SWP instance; and (2) to constrain costs, a maximum number of five instances to be provisioned by elasticity manager was set. The second experiment simulated a spiking access workload from 10 to 400 concurrent accesses. The auto-scaling rule for spiking access is as follows: (1) when the average response time > 6 seconds, two SWP instances are provisioned; (2) when the average response time is < 3 seconds, two SWP instances are released; and (3) the minimum and maximum number of SWP instance is 1 and 5, respectively.

The performance of auto-scaling and workload balancing-enabled SWP in handling increasing workload is shown in Figure 10 and demonstrated the following results. First, the elasticity manager and auto-scaling mechanism resulted in the SWP invoking more computing capabilities to the increasing workload. At the beginning (Figure 10a), only one SWP instance was utilized for concurrent access from 1 to 210 because SWP responded to the end users within 6 seconds. When the concurrent access number was 230, the elasticity manager utilized the second SWP instance because the response time exceeded the predefined threshold. Two SWP instances in the cloud workload balancer worked together to balance the workload, and they reduced the response time to ∼5 seconds. Based on similar mechanism, the elasticity manager utilized the third, fourth, and fifth SWP instance when the concurrent access number reached 280, 330, and 380, respectively. Second, auto-scaling enabled the SWP to achieve a balance between handling computing intensity and saving cloud service cost. With 400 concurrent requests, the response time of auto-scaling was reduced to 7 seconds compared with one-instance SWP of 14 seconds. In addition, the auto-scaling-enabled SWP was more cost-efficient compared to a load balancing-enabled SWP with redundant computing resource (five instances) even with a lighter workload. Because of the efficiency of the auto-scaling mechanism, auto-scaling-enabled SWPs handle well the dynamic or spiking access in a region. Conversely, load balancing better supports routine requests from different geo-locations across the world.

Figure 10. SWP response and elasticity manager reaction to a dynamic workload.

The performance of auto-scaling-enabled SWP in handling spiking access in a 9-minute timeline is shown in Figure 10b, and four general patterns are observed. When the concurrent request number increases from 10 to 400, the SWP average response time rose from 0.2 to 18 seconds, triggering a scaling-up event. Second, after the scaling-up event, an additional 60–90 seconds was required for two more SWP instances to be launched for handling the spiking workload, and the mean response time was reduced to 10 seconds. Third, another 60–90 seconds passed for the launch of the fourth and fifth instances, and the mean response time was reduced to 7 seconds. Finally, when the concurrent request fell to 10, the time to release every two instances was about 60 seconds.

4.5. Global access

These experiments investigated the performance of cloud-enabled SWP in supporting global user access by adopting global deployment with the following workflow:

1. Based on the spatial distributions of end users, launching four SWP instances in three continents with high access frequency (1, 2, and 1 from North America, Europe, and Asia, respectively).

2. To simulate global user access, load performance test software (Apache JMeter) was installed on VMs in different continents and concurrent spatial query requests sent to SWPs in different continents.

3. To monitor geospatial resource quality, VMs in different continents continuously communicated and recorded performance information from 7 popular geospatial web services located in different continents.

4. The repeat rules were used to calculate the mean response time and resource quality.

With global deployment, the SWP achieved 0.7–2.2 second performance improvements for European users and 0.5–2.1 second improvements for Asian users with only one SWP instance (Figure 11). This improvement was attributed to the optimized distribution of SWP server. For example, an SWP instance was deployed on Azure's North Europe data center to accommodate European user requests. However, these requests were forwarded to the SWP server in the USA without using the global deployment mechanism. In addition, global deployment-enabled SWP achieved further performance improvement because more instances were utilized with the workload balancing or auto-scaling mechanism.

Figure 11. The SWP mean response time as a function of global deployment.

The response time of four popular web map service (WMS) monitored by the cloud service from the North America, North Europe, and Asia is illustrated in Figure 12. The geospatial service performance is a function of distance (physical and network) between the clients and service providers. For example, the WMS in Ireland (Figure 12a) provided shorter response time to European user (about 0.2 seconds) than that to users from other continents (e.g. about 1.95 seconds from Asia). In addition, this WMS had better user satisfaction (Kettinger and Lee 1994) and service reliability (Maximilien and Singh 2004) for European users. It provided 100% and 88% user satisfaction (percentage of responses within 0.3 second) for European and North American users but 0% satisfaction for those from Asia. The reliability (percentage of non-error access) of this WMS for North European, North America, and Asian users was 99%, 97%, and 90.5%, respectively. The location-specific service performance information can be captured by adopting a global monitor, which is integrated with the SWP global deployment.

Figure 12. Service response time as a function of concurrent request number from different geo locations.

5. Conclusion

This paper proposes a cloud-based framework for SWP to address several SWP operational challenges and does so by leveraging cloud computing. Four SWP operation challenges are highlighted: (1) computing intensity for data querying and updating; (2) concurrent intensity for responding to massive requests; (3) communication intensity for interoperating and integrating explosively growing geospatial resources; and (4) spatiotemporal distribution of end users and the dynamic, globally distributed, and spiking workload. A cloud-based framework for SWP is proposed to address the challenges.

5.1. Key features for addressing SWP challenges

The key features in the cloud-based framework for addressing SWP challenges are summarized in Table 2:

Table 2. Key cloud features to address the SWP challenges.

	Elastically resource pooling	Workload balancing	Global deployment
Computing intensity	X
Concurrent intensity	X	X
Communication intensity		X	X
End user spatiotemporal distribution	X	X	X

5.1.1. Computing intensity handling

To better handle computing intensity, the elastic resource-pooling feature was implemented by the elasticity manager for the SWP to provision or release sufficient computing resources for intensive processing (Section 4.3) and to adapt the computing resources to the dynamic workloads (e.g. spiking workload) (Section 4.4). Experimental results (Section 4.2) demonstrate that the three cloud services (EC2, Azure, NASA Nebula) introduce similar and reasonably low virtualization overheads.

5.1.2. Concurrent intensity handling

To address massive concurrent user accesses, the elastic resource-pooling feature initially provisioned a number of SWP instances. Subsequently, massive concurrent workloads were dynamically scheduled to different SWP instances by the cloud workload balancer. The cloud-enabled workload-balancing mechanism significantly reduces the response time up to 16 seconds performance gain for 400 concurrent requests by using five SWP instances for workload balancing (Section 4.3).

5.1.3. Communication intensity handling

To address the communication intensity, the global deployment was used to reduce the communication distance between SWP and geospatial resources. Experimental results (Section 4.5) show that shorter distances achieve faster interoperations.

5.1.4. End user spatiotemporal distribution

The cloud-enabled global deployment approach helps SWP reduce physical and network distances between end users and SWP instances, so better system performance is achieved. Experimental results (Section 4.5) show that SWPs achieve up to 2.2 seconds performance gain for Asian and European users with one SWP instance.

These intensity challenges will increase with the growing of Digital Earth operational systems for addressing global challenges by leveraging global geospatial resources. Therefore, the methodologies, experiments, and results can serve as references to support better Digital Earth system global operations.

5.2. Future research

The proposed cloud-based SWP framework mainly focuses on system performance in responding to global users. To further improve the operation of the SWP, further research is desired from at least the following aspects:

5.2.1. Cost model

As a cloud-based system, the new SWP framework achieves better performance for the system operation. With the increasing number of cloud services and the diversity of in-cloud SWP configurations, it is challenging for SWP administrators to choose the ‘right’ cloud service and configuration. A cost model (Li et al. 2009; Zhang, Zhu, and Boutaba 2011) is needed to provide recommendations for choosing cloud services and cloud configurations (e.g. cloud instance type, instance number, and auto-scaling rules) based on the system requirement and to estimate and optimize the cost based on different cloud services and configurations.

5.2.2. Service performance measurement

The cloud-based SWP framework fostered a global-level service performance-monitoring approach by leveraging widely distributed cloud services. With the implementation of such a monitoring system, end users receive dynamic service performance according to user location and access time. However, a service quality measurement and composition model (Cruz, Monteiro, and Santos 2012; Wu et al. 2011) is missing to evaluate service based on their spatiotemporal distribution.

5.2.3. Spatiotemporal indexing and user behavior patterns

The spatiotemporal distribution of end users not only results in geographically distributed and spiking workloads but also contributes to various spatiotemporal user behavior patterns that can be used to optimize the SWP. Better spatiotemporal indexing (Theodoridis et al. 1996; Pfoser, Jensen, and Theodoridis 2000), caching (García Martín et al. 2013; Li et al. 2012), and workload balancing (Bunt et al. 1999; Huang et al. 2011) can be designed by understanding the users' demand for geospatial resource at different locations and at different times.

Acknowledgments

We would like to thank the anonymous reviewers and editor for providing insightful comments to improve the paper. All research and writing are performed at George Mason University. Dr George Taylor helped proofread a previous version of the paper.

Additional information

Funding

Research reported is partially supported by NSF [grant numbers PLR-1349259 and IIP-1338925], FGDC [grant number G13PG00091], and NASA [grant number NNG12PP37I].