Parallelizing calls to msDrawLayer()

David Fuhry dfuhry at CS.KENT.EDU
Sat Oct 13 20:39:06 EDT 2007


    Thanks, that's a good suggestion.

    I guess my thought is, given a really good implementation, a 
heavily-contended server with a bright scheduler would just end up 
scheduling the threads sequentially on the same CPU (perhaps likely, 
since a small bit of the necessary data is in that processor's L1 cache 
already).  Then the onus is on the implementer to make sure that the 
extra overhead is pretty low.

    It sort of pushes some of the responsibility to the OS scheduler. 
Which I think most of the time, will make better decisions than will a 
deterministically-ordered mapserv loop.



Paul Spencer wrote:
> David,
> While you can perhaps gain some performance in a single map draw, in 
> most real life uses of mapserver, folks are either serving many 
> simultaneous requests or generating tiles in some way.  I think in 
> either case, the addition of multi-threaded layer draws will actually 
> cause contention for processor time with the multiple processes that are 
> serving the requests and could hurt overall performance in high load 
> systems.
> I think that you could probably get more bang for your development bucks 
> by investing time in profiling the existing code.
> Cheers
> Paul
> On 13-Oct-07, at 6:37 PM, David Fuhry wrote:
>> Tamas,
>>    (responses inline)
>> Tamas Szekeres wrote:
>>> David,
>>> I consider it would be reasonable to establish such mechanism only
>>> when fetching the data of the layers. Likewise currently the WMS/WFS
>>> layers are pre-downloaded in parallel before starting to draw the map.
>>> We should have a similar approach when fetching the other layers as
>>> well.
>>    Yes, I noticed that WMS/WFS layers are downloaded in parallel 
>> before rendering begins.  And I agree, it would be advantageous to 
>> extend the parallel-data-fetching paradigm to all layers.
>>    For non-WMS/WFS layers though, wouldn't it be a significant 
>> disruption to the codebase to add lines 1 and 2 into msDrawMap()?
>> 1. for i=1 to layers.length (in parallel)
>> 2.   data[i] = fetch_data_for_layer(i)
>> 3. for i=1 to layers.length (serially)
>> 4.   msDrawLayer(data[i])
>>   ISTM that the data-fetching logic might be best left abstracted 
>> beneath msDrawLayer().
>>> However pre drawing all of the layers and later copying the layers
>>> over the map image seems to be much less efficient.
>> Drawing n layers onto n imageObjs is no more expensive than drawing n 
>> layers onto one imageObj, and the former can be parallelized across n 
>> threads.
>> Although yes, I agree that composition (the "merge" step) will cost 
>> something.
>> I'm entertaining the idea that the time saved by parallel fetching & 
>> drawing might outweigh the cost of composition.
>>> When using the parallel fetching approach we should deal only with the
>>> drivers from the aspect of the thread safety issues.
>> I might be misunderstanding your point here, but... Rendering a layer 
>> into an independent imageObj should be a pretty independent operation, 
>> and could be made so if it's not now.  Glancing at the mapserver 
>> thread-safety FAQ, it seems there are more unsafe & locked components 
>> related to data-fetching drivers than there are for rendering.  Which 
>> makes me wonder why you suggest parallelizing the data-fetching but 
>> not the rendering.
>> Forgive me if I'm playing a bit of devil's advocate here.  I'm aware 
>> that non-reentrant functions don't rewrite themselves, and that 
>> critical sections don't surround themselves with mutexes.  Surely 
>> though, it ought not to be a tremendous amount amount of work to keep 
>> separate layer-drawing operations from stepping on eachothers' toes?
>> Thanks,
>> Dave Fuhry
>>> Best regards,
>>> Tamas
>>> 2007/10/12, David Fuhry <dfuhry at>:
>>>> Has anyone looked into parallelizing the calls to msDraw[Query]Layer()
>>>> in msDrawMap()?
>>>> Although I'm new to the codebase, it seems that near the top of
>>>> msDrawMap(), we could launch a thread for each (non-WMS/WFS) layer,
>>>> rendering the layer's output onto its own imageObj.  Then where we now
>>>> call msDraw[Query]Layer, wait for thread i to complete, and compose 
>>>> that
>>>> layer's imageObj onto the map's imageObj.
>>>> In msDraw[Query]Layer(), critical sections of the mapObj (adding labels
>>>> to the label cache, for instance) would need to be protected by a 
>>>> mutex.
>>>> A threaded approach would let some layers get drawn while others are
>>>> waiting on I/O or for query results, instead of the current serial
>>>> approach where each layer is drawn in turn.  Multiprocessor machines
>>>> could schedule the threads across all of their cores for simultaneous
>>>> layer rendering.
>>>> It seems this could significantly speed up common-case rendering,
>>>> especially on big machines, for very little overhead.  Has there been
>>>> previous work in this area, or are any major drawbacks evident?
>>>> Thanks,
>>>> Dave Fuhry
> +-----------------------------------------------------------------+
> |Paul Spencer                          pspencer at    |
> +-----------------------------------------------------------------+
> |Chief Technology Officer                                         |
> |DM Solutions Group Inc       |
> +-----------------------------------------------------------------+

More information about the mapserver-dev mailing list