On 5/26/2011 5:07 PM, Frank Warmerdam wrote:
On 11-05-26 05:01 PM, Mark Korver wrote:
I would think that the thinking here is that a server only scales well
to some number of concurrent requests. That beyond that number, all
requests suffer. In this case it's better to queue the requests
rather than try to process them, meaning queuing improves performance
overall.
Folks,
I will just note that Apache + FastCGI makes it pretty easy to
limit the number of concurrent requests being processed and when
saturated the new requests are queued. I presume they would timeout
after a while if there is just too much traffic.
Best regards,
Mark,
Yes, this is what I was trying to say. And to expand on this, to make
scalable systems, there is normally some layering of services. So while
mapserver know how to render maps, Apache is what receives requests,
queues them, knows how many requests are running, so this is the logical
place to deal with this, not in mapserver.
You can also place a load balancer in front of a farm of servers and
have it route requests to the least loaded system. But this even starts
to fail at some point, then you need to look at other solutions like
caching tiles.
In my 11+ years of working with mapserver, I can say that often
mapserver is disk I/O bound, and that you can do stuff to speed that up
which makes in CPU bound. It is best to test your setup to find where
the bottlenecks are and then work on eliminating the top ones, then
retesting to see how the bottlenecks have shifted. This optimizes a
single mapserver, then you need to look at how to scale that maybe
across multiple servers depending on your load and usage requirements.
-Steve W
_______________________________________________
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users