Mapserver performance issue: why so much slower?

Ed McNierney ed at TOPOZONE.COM
Wed Apr 19 21:19:19 EDT 2006


Brent -

In other words, is a fish different than a radio <g>?  Yes, you're
definitely comparing apples and oranges!

There is, in general, no reason to think Windows is "faster" than Linux
or vice versa, nor that Intel CPUs are "better" than AMD or vice versa.
Your hardware specs for CPU, RAM, and disk subsystem (the three most
important factors) all clearly indicate the production Windows system is
a higher-performance machine for MapServer applications.

The first place I'd look is to understand how your Java MapScript
application is different than your MapServer CGI implementation, and I'd
probably do that by trying to implement and run the Java MapScript
application on your prototype machine.  That way you'd have a similar
application running in each environment, and you'd also have access to
your prototype system's analysis tools to try to figure out why the
application performs the way it does.

I'm also assuming that that production system isn't busy doing lots of
other stuff, too, right?  A system with 3.5 GB of RAM isn't quite the
same if another app is using 3 GB of it already.

Thanks for the complete description, too!

	- Ed

Ed McNierney
President and Chief Mapmaker
TopoZone.com / Maps a la carte, Inc.
73 Princeton Street, Suite 305
North Chelmsford, MA  01863
Phone: +1 (978) 251-4242
Fax: +1 (978) 251-1396
ed at topozone.com 

-----Original Message-----
From: UMN MapServer Users List [mailto:MAPSERVER-USERS at LISTS.UMN.EDU] On
Behalf Of Brent Wood
Sent: Wednesday, April 19, 2006 4:33 PM
To: MAPSERVER-USERS at LISTS.UMN.EDU
Subject: [UMN_MAPSERVER-USERS] Mapserver performance issue: why so much
slower?

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



More information about the mapserver-users mailing list