System Configuration

[Frank Warmerdam]

Bruce Cheney wrote:
> We have been given a requirement to support 5000 simultaneous users.   
> What we are finding is that MapServer bogs down around 400 simultaneous 
> users on a test machine.  It looks like it is likely slowing because of 
> the threading issue.  We haven't tested on a production machine but are 
> estimating that it should support double what are test machine could 
> handle (double the processor and RAM).  So at least 800 simultaneous 
> users.  Divide that out with the 5000 and we need a minimum of 6-7 web 
> servers supporting MapServer.  We will certainly scale this as is needed 
> but I do need some idea going in as to what is going to be required.

Bruce,

I'm curious how many map requests per minute you expect 800 simultaneous
users to generate.

> Does this sound like results that others expect or is this quantity 
> above what others have tested?  Also Does anyone know of a solution in 
> the works to run make mapserver thread safe and/or up the overall 
> speed?  I am not complaining about the speed just wondering what is in 
> the works.

In various aspects MapServer is already thread safe though there are
also known "unsafe" components, and some components are wrapped by
big locks that significantly reduce the value of multiple threads.
Progress occurs by fits and starts, largely based on support from user
organizations depending on multi-threading.  For instance, in 5.0 I
implement locking around OGR for a client of mine in Australia.

(This is a subtle way of suggesting you hire someone to make this
happen if it is what you want!)

All this aside, by default MapServer is *massively multi-threaded*.
I say this since the default operation is to start a new cgi instance
for each request - each is essentially an independent thread.

Of course, the downside of whole-process cgi style multithreading is
that very little context is preserved from request to request.  Map
files, data file headers, etc all need to be reparsed for each request.
My point here is that you need to think carefully about the application
flow to take much advantage of multiple threading within a single process.

Also, if I may channel Ed, if you wanted to squeeze more performance out
of mapserver, you really need to start by figuring out what it is spending
it's time doing.  Where is it spending it's time?
  o waiting for disk?  (perhaps you are reading more data than you need?)
  o rendering (perhaps your data is overdense, or you are using expensive
    rendering options?)
  o parsing mapfiles (perhaps you mapfile has too many unused layers?)
etc.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org