[mapserver-dev] More Performance

Mon May 12 15:47:39 EDT 2008

Paul,

if you download 2.4 from the agg site, you just have to type 'make' to  
get it to build a static library.  Its a very simple build really but  
if you try to run configure then it gets really complicated.

On 12-May-08, at 3:44 PM, Paul Ramsey wrote:

> Sadly, no, I don't have AGG working under OS/X 10.5 yet.
>
> http://trac.osgeo.org/mapserver/ticket/2368
>
> I can't even get a compile on my Linux Centos image... agg has been a
> real PITA to get compiled.
>
> P.
>
>
> On Mon, May 12, 2008 at 12:32 PM, thomas bonfort
> <thomas.bonfort at gmail.com> wrote:
>> From the graph it seems like gd's font rendering/cache is a good
>> culprit. Paul, is it easy for you to try the same thing with the agg
>> backend (with an up-to-date trunk as I just removed the gd font calls
>> from the agg code). from my tests agg was substantially faster than  
>> gd
>> at font rendering.
>>
>> thomas
>>
>> On Mon, May 12, 2008 at 9:24 PM, Steve Lime <Steve.Lime at dnr.state.mn.us 
>> > wrote:
>>> This sounds like a great opportunity to collaborate. We all want  
>>> to go fast and each project
>>> would push the other. Andrea mentioned in Victoria that they would  
>>> make their test framework
>>> available but I've never been able to find it on their site. Might  
>>> Andrea be interested in that?
>>>
>>> As for labeling. Does the label cache processing have an impact?  
>>> Could try BITMAP vs TTF fonts
>>> and TTF with and without the labelcache.
>>>
>>> Steve
>>>
>>>>>> On 5/12/2008 at 2:17 PM, in message
>>> <30fe546d0805121217n33217949ue308e0dbe42aa40d at mail.gmail.com>,  
>>> "Paul Ramsey"
>>>
>>>
>>> <pramsey at cleverelephant.ca> wrote:
>>>> I don't have an environment, I'm just taking the info from  
>>>> Andrea. The
>>>> effect of loading a font is definitely noticeable... my
>>>> small-map-on-large-file (no labels) case draws faster than the  
>>>> simple
>>>> draw-50-states (state name labels) case, and the difference is the
>>>> font loading. The curl init overhead is there too, though I see now
>>>> drilling lower into it that it is specific to curl-with-ssl,
>>>> initializing the SSL. Regardless, something that is removable for a
>>>> few ms gain.
>>>>
>>>> No details on the use cases, I'm afraid. Andrea sent me his test  
>>>> map,
>>>> but it's really just a simple shapes with colors and labels, no
>>>> selectivity case.  He is trying to build a performance testing
>>>> framework that he can use to regress geoserver over time, to ensure
>>>> new development doesn't destroy performance. It's all HTTP based,  
>>>> so
>>>> we could use the same infrastructure.
>>>>
>>>> P.
>>>>
>>>> On Mon, May 12, 2008 at 12:07 PM, Steve Lime <Steve.Lime at dnr.state.mn.us 
>>>> >
>>>> wrote:
>>>>> Do you have a GeoServer/MapServer test environment setup? I'd  
>>>>> really like to
>>>> get one
>>>>> in place. It's impossible to know how fast or slow MapServer is  
>>>>> with out it.
>>>> I'm assuming
>>>>> Andrea has one since he's still testing head-to-head.
>>>>>
>>>>> Are the various use cases detailed some place?
>>>>>
>>>>> Steve
>>>>>
>>>>> Thanks for the Shark tip, hadn't heard of that one.
>>>>>
>>>>>>>> On 5/12/2008 at 1:50 PM, in message
>>>>> <30fe546d0805121150t765a77bl80ecc5ab3092070d at mail.gmail.com>,  
>>>>> "Paul Ramsey"
>>>>> <pramsey at cleverelephant.ca> wrote:
>>>>>> Andrea Aime pointed out that Geoserver is still running about 3- 
>>>>>> times
>>>>>> as fast as Mapserver in some use cases, which has prompted me to
>>>>>> discover Shark (note to developers on OS/X, learn to run Shark).
>>>>>>
>>>>>> Among the things Shark tells me is that the epsg configuration  
>>>>>> file
>>>>>> remains the biggest (avoidable, but non-obvious) performance  
>>>>>> issue,
>>>>>> potentially hogging huge amounts of resources, since the  
>>>>>> projections
>>>>>> are loaded even for layers that aren't being rendered.  Even  
>>>>>> worse,
>>>>>> it's a performance issue that fcgi doesn't fix, since the loading
>>>>>> happens in msLoadMap.
>>>>>>
>>>>>> Another thing Shark tells me is that we are burning resources in
>>>>>> curl_global_init (called from msHTTPInit via  
>>>>>> msHTTPInitRequestObj)
>>>>>> even when there are no WMS or WFS layers defined.  This is eating
>>>>>> about 5% of the total cycles, on a fairly well-tuned map file,  
>>>>>> and
>>>>>> could be fixed.
>>>>>>
>>>>>> Finally, the biggest single resource muncher in this small-easy- 
>>>>>> map
>>>>>> case is loading the font file.  This could be an artefact of  
>>>>>> the OS/X
>>>>>> font loading, or it could be generic. It looks like gd has a font
>>>>>> cache, so perhaps this goes away in FCGI.  I guess that should  
>>>>>> be my
>>>>>> next test, because if it doesn't go away it's a big win in the  
>>>>>> FCGI
>>>>>> case to make it go away.
>>>>>>
>>>>>> P.
>>>>>
>>>>>
>>>
>>> _______________________________________________
>>> mapserver-dev mailing list
>>> mapserver-dev at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>>>
>>
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev

__________________________________________

    Paul Spencer
    Chief Technology Officer
    DM Solutions Group Inc
    http://www.dmsolutions.ca/