Mapserver performance issue: why so much slower?

[Sean Gillies]

On Apr 19, 2006, at 2:32 PM, Brent Wood wrote:

> Hi,
>
> I have prototyped some background map data to be served by  
> Mapserver. There are
> about 7Gb of Postgis data and 4Gb of images, The images comprise 3  
> zoom layers,
> of 2, 100 & 800 tiles each, each addressed via a shapefile  
> tileindex. Just
> using the basic CGI mapserv application & a mapfile.
>
> The prototype system is an AMD 64bit 3500+ cpu, with 1Gb memory & 2  
> 80Gb SATA
> drives. The PostGIS database is on a software RAID0 partition with  
> a nominal
> 100Mb/sec I/O. It is running SUSE 9.3 A64 with all the GIS related  
> apps
> compiled from scratch so they are all 64bit apps. I'm more than  
> pleased with
> the performance.
>
> I have only ftp & remote Postgres access to the production server...
> (don't ask !!!!! :-) so am limited in what I can do (even more than  
> my normal
> limitations).
>
> The server this is to be implemented on is running a Java digital  
> asset
> management application as an image database under Windows 2k3  
> server. Mapserver
> is implemented only as a Java mapscript capability, embedded in the
> application, to provide a location based facility for selecting  
> images.
>
> The server is supposedly an Intel 3.5Ghz hyperthreaded cpu with  
> 3.5Gb memory &
> a reasonable SCSI RAID array. Postgres performance seems fine, so I  
> don't think
> it is a database performance issue (but I could be wrong about  
> this- our tests
> have been not been for large geometry objects such as are retrieved by
> mapserver, but for large numbers of small tuples)
>
> Mapserver, however, is very slow. It is taking about 5x as long to  
> render the
> maps with only 20% of the data being implemented in the mapfile &  
> no rasters.
>
> Also, unlike the Linux box, repeat accesses/redraws do not speed up  
> compared to
> the original (Linux vs Windows caching perhaps?)
>
> Does anyone have any suggestions/ideas about the performance of  
> Java mapscript
> vs cgi mapserver, Linux 64bit vs Windows 32bit, Intel vs AMD, etc.  
> There are so
> many points of difference, & I'd like to narrow my search for the  
> basic
> cause/solution if at all possible.
>
> We may be able to stick a Linux A64 box as the postgis/mapserver  
> server, but if
> it is a Java mapscript vs CGI mapserve issue, this may not do  
> anything to help.
>
> Running a separate WMS Linux mapserver server & the image db as a  
> Javascript
> WMS client will (as I understand it) remove virtually all the load  
> from the
> Windows box, so may be a suitable solution. Any comments on this  
> approach? Is
> it feasible with Java mapscript?
>
>
> Thanks,
>
>    Brent Wood

Brent,

I'm not surprised that a mapscript application would be slower than  
the CGI. Remember, the CGI gets more use and abuse, and has been  
continually profiled and improved. Your Java developers may have  
produced less efficient code. I'm a Python mapscript user and find  
that I have to be very diligent if my Python apps are to keep up with  
the CGI program.

Now, some speculation. I'm not much of a Java developer, but I recall  
that Java is quite thread-happy, yes? MapServer has a number of  
coarse-grained locks around code that is not thread-safe. In particular:

- mapfile parsing
- class expression parsing and evaluation
- raster IO

Your developers may want to check and see if these have become  
bottlenecks in your app.

cheers,
Sean

---
Sean Gillies
http://zcologia.com