Parallelizing calls to msDrawLayer()

[Paul Spencer]

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 cs.kent.edu>:
>>> 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 dmsolutions.ca    |
+-----------------------------------------------------------------+
|Chief Technology Officer                                         |
|DM Solutions Group Inc                http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+