[mapserver-users] Controling the amount of concurrent GetMap requests

[Stephen Woodbridge]

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