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

Reply via email to