[The copyright of this article is owned by the xiaotie@vip.sina.com, reproduced by the author's consent.]
Problems ......
Performance tests show that the performance of the current architecture is relatively low.
Test environment: pc cpu inter pentiumiii clock speed 797 MHz
Primary memory: 384 Mb
Operating System: Windows Server 2003
Web server: iis6.0
GIS server: geoserver
The current Web GIS solution is able to process less than 20 mb of geographic data (when the shape fileformat data volume is used, the page size can be opened at around, And the javaw.exe memory usage is around 50 MB. However, when Web GIS processes Geographic Data larger than 320 MB, the Performance drops sharply, and the memory usage increases sharply. when processing a 330 MB shape filefile, javaw.exe occupies-MB of memory, the processing time is up to 5-10 minutes.
The underlying cause of performance may be the absence of caching and indexing mechanisms, or the efficiency of Java itself. To locate the problem, the C ++ open source GIS qgis is used to open the same dataset for comparative testing. the time consumed is similar to that of geotools, indicating that the reason for the performance is not the language, the index and cache mechanisms can be used to improve performance. Fortunately, both JTs and postgis provide spatial index support. As for caching, it can be solved on the server side.
Another unexpected problem found in the qgis test is memory usage. Open the same dataset, and qgis memory usage is only 1/10 of geotools. The memory limit of the Java Virtual Machine may cause that the loaded dataset cannot be too large. Fortunately, the memory is cheap, and there are not many Web GIS applications with big data sets of G. cluster can be used if necessary.