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
