WebGIS Performance Tests

A WebGIS is usually constructed as a multi-tier architecture basically consisting of the client side, the server side and the database component. From the client side, users send queries or requests to the server via (wireless) internet. Next, the server communicates with the database, where the requested information is compiled by the database server. Finally, the result is sent to the client. With the rapid growth of WebGIS, a number of work models have been developed to increase efficiency and performance. While developing the Boston Water and Sewer WebGIS application in 2010, the authors tested the performance of two models: centralised and distributed.

The two work models tested both use multi-tier client/server architecture that mainly includes client, web servers and database servers. The clients are web browsers such as Internet Explorer (IE) or Firefox. Web servers include IIS (Internet Information Services - a web server application and a set of feature extension modules created by Microsoft), Apache or Tomcat, and database servers usually stem from Oracle or SQL.

In the distributed work model, the web server and the ArcGIS server are located on different computers (Figure 1). In the centralised work model, all servers - the web server and the ArcGIS server - are located on the same computer (Figure 2). In addition, the database component may be comprised of a number of databases. For instance, in the Boston Water and Sewer application, datasets containing water lines, sewer lines and street GIS features are stored in a spatial Oracle database while data on work order and construction projects are stored in a non-spatial Oracle database, billing data in an Ingres database, and data on water-meter readings in an SQL database. The reason behind separating the servers from the databases is to avoid any processes carried out on the data sets interfering with other processes.

Workflow

How does the client-side user obtain the information he requested? The general workflow of the diverse work models consists of a sequence of steps (Figures 1 and 2). First, the user on the client side selects the information he wants and accordingly sends a request to the IIS server, which calls on the c# procedure to convert the selections into parameters to set up the predefined SQL statements. To retrieve the data, the SQL statements are sent to the corresponding non-spatial database or to the ArcSDE server, depending on the type of information requested (non-spatial or spatial). The response of the non-spatial database consists of SQL data sets which are directly sent to the IIS server. The ArcSDE server sends the SQL statements to the spatial database and the response is then forwarded to the IIS server through the ArcSDE server. After completion of the above steps, the ArcGIS server comes into play; the SQL data sets received by the IIS server are sent partially or wholly to this server to update the GIS maps. Next, the generated GIS maps are sent to the IIS server from where they are transferred to the user on the client side.

Comparison

Table 1 compares various features of distributed and centralised work models. Distributed work models require two servers: one to act as IIS server and one as ArcSDE/ArcGIS server. Compared to centralised work models, distributed work models thus require more hardware and software, more maintenance, more drivers and tapes for making backups, more wires and more updates and hence they are more expensive. In addition, they require the communication between ArcSDE/ArcGIS servers and IIS server to go through the Ethernet cable.

This may be fast when traffic levels are low but it slows down significantly when traffic becomes busy, and can even lead to data transmission latency, which may be so extensive that data traffic comes to a complete halt. Processing done in the same server without using an Ethernet cable will increase the reliability of communication. However, one server also means one CPU (Central Processing Unit), which may become overloaded when too many users are sending requests for information.

Performance Tests

Several tasks were carried out to test the response time of the two work models. One of these tasks concerned searching for a building to present it on the map and to show its water account on the attribute panel. Another task concerned clicking on a sewer line to show its related services on the attribute panel. The centralised work model responded nearly three times faster in these two tasks than the distributed work model (Table 2).

Other tasks revealed that the time saving is generally more than a factor of two when using a centralised work model, given that the traffic levels are modest.

Concluding Remarks

Based on the criteria of number of users, expense, response time and maintenance effort, we chose the centralised WebGIS work model as the final client/server architecture for the Boston Water and Sewer WebGIS application. Other WebGIS work models we developed have been described in two other articles previously published in this magazine (see Further Reading).

Acknowledgements

Special thanks for the cooperation of Boston Water and Sewer Commission. This work is supported by the Special Project Fund of Taishan Scholars of Shandong Province.

Further Reading

- Chen, L., Dai, H., 2008, OPeNDAP: New WebGIS Architecture, GIM International, vol. 22, no. 5, pp.13-15.

- Dai, H., Chen, L., 2006, EcoSystem Survey Data Mapping Interface: Web-based GIS Application for Ocean Species Sample Analysis, GIM International, vol. 20, no. 2, pp. 61-63.

- Dai, H., 2004, An Approach on Rendering GIS Vector Maps onto Internet, presented at TSU GIS 2004, the 1^st Annual GIS Symposium at TSU, Troy, Alabama, USA, 19^th-20^th May 2004.

- Brandon Plewe, 1997, GIS Online: Information Retrieval, Mapping and the Internet, published by Cengage Learning, ISBN-10: 1566901375.

Table 1, Comparison of distributed and centralised work models.

Table 2, Response times (expressed in seconds) of distributed and centralised work models to two requests for information on the client side.