hardware

[Brent Wood]

--- Kim Allen <walker1145 at QWEST.NET> wrote:

> I have been given the chance to spec out a server for our mapserver and need
> some help to take advantage of this. What I would like to do is to run
> mapserver on apache using  postgresql/postgis as the database. I anticipate
> using only a few shapefiles  for state /province boundaries and all of the
> rest on the postgres database. On that spatial database I have a table with
> 1.6 million entries, another with 180,000 entries updated daily and both of
> these are points, I will also have several tables with ploygons. I am using
> an html template for the maps but would like to use an interface like ka-map
> down the road. Currently I am using about 68 GB of disk space out of 138 GB
> however after the upgrade I would like to start adding some raster images.
> The peak number of hits an hour are around 200 but I know that will go up
> with an increase of speed. Since we are a MS shop I am looking for something
> that should be able to handle at least 3 times the number of hits per hour
> running on a MS server. However I also anticipating migrating to a linux
> based solution in the immediate future but for now I have to satisfy the
> powers that be.
> 
> Any suggestions based upon the sketchy outline above will be appreciated.

Hi Kim,

Having wrestled with an unacceptably slow Windows server, and a much faster
Linux system, despite being on inferior hardware (we still run the Windows
server with a java mapscript client, but have abstracted PostGIS/Mapserver to a
separate Linux server - using WMS - about 400 miles from the Wndows box), my
first comment would be to go Linux ASAP.

I think you'll get more benefit properly configuring Postgres & indexing,
partitioning & clustering your PostGIS tables & perhaps using fastcgi for
mapserver than tweaking hardware.   

I have compared the same PostGIS database under Linux & Windows on the same
hardware, using in one case a 1.6m row table with points, lines & polygons.

The first (moderately complex) query took about 18 secs on both systems after
rebooting. Repeating the query took 18 secs again on the Windows box, but 3
under Linux. Linux file caching & Postgres seem a much better match than under
Windows.

As far as hardware goes, fast raided disks, striped if data security isn't a
huge issue & price is, or a more sophisticated raid 5, perhaps 0+1 if redundant
disks are required.

I have found AMD cpu's outperform Intel $ for $ in this sort of application,
but your mileage may vary. As much memory as you can afford is probably going
to help more than sheer cpu speed, or number of cores.

So my advice, worth all that I'm charging for it, spend your budget of the
fastest disks, as much memory & as much cpu as you can afford, in that order,
for Windows.

For Linux, with its superior file caching, I'd suggest the same, but put memory
first, as lots of memory will make up for (slightly) slower disks.

To make best use of all that memory, a 64bit OS is prefereable.

Enough memory to cache the entire database would be a good starting point,
there have been discussions on the Postgres user list about running it in a ram
disk for sheer speed, but if it fits in memory anyway, then the OS should do
that for you. 

You might also look at OpenLayers instead of Ka-Map! for your interface, it's
ability to cache clientside layers & download tiles, while a bit slower to
start, is much faster overall in my experience.


Cheers,

  Brent Wood