[mapguide-users] what's holding people back from upgrading to 2.0?

Jonathan Manafi jonathan.manafi at cctechnol.com
Tue Oct 7 17:19:35 EDT 2008


We had some scale ranges in use that implemented some area styling, but 
I went ahead and added another, specifically for high zoom ranges(tried 
0-1000). For our previous styling, we had a dashed line border(line04) 
and a feature label of the NAME property. I went ahead and just 
implemented a solid line border.

    - In the AGG renderer, hitting under 1:100 caused the server to
    consume steady 50% CPU.
    - In GD, nothing happened. The server continued to respond the same
    as in normal conditions.

So, I tried changing the area style to a dashed line. In GD, using a 
dashed line caused the server to start eating up memory under 1:100, 
which really started occurring around 1:50. While zooming in, the memory 
would temporarily jump to over 200MB, and once the server was no longer 
using the CPU, the memory would restore itself to around 48MB. At the 
next zoom level, the memory would jump a little higher, perhaps 
280-300MB and then restore itself. At around 1:6, the memory stayed at 
520MB usage and would increase at sequential zooms. After that, the 
memory was never released by the server. Also, once the memory started 
increasing that much, the layer would no longer be displayed beyond a 
certain zoom scale; it seems to occur under 1:30.

If I remember correctly, when I gave the layer to be tested way back 
when, I think Jason made a comment that this layer was made up of 
thousands of vertices. I understand that styling and rendering all of 
that data for a layer is expensive, but how come in this situation two 
standard styles offered by Autodesk(solid and dashed lines) differ so 
differently in performance?

Thanks for your help.


Traian Stanev wrote:
> Did you try to use scale ranges to control the style and visibility of the bad layer at high zoom factors? This may alleviate your problem.
>
> Traian
>
>
>   
>> -----Original Message-----
>> From: mapguide-users-bounces at lists.osgeo.org [mailto:mapguide-users-
>> bounces at lists.osgeo.org] On Behalf Of Jonathan Manafi
>> Sent: Tuesday, October 07, 2008 3:57 PM
>> To: MapGuide Users Mail List
>> Subject: Re: [mapguide-users] what's holding people back from upgrading
>> to 2.0?
>>
>> Short answer: yes.
>>
>> However, testing the package that is available in that ticket, I am
>> only
>> getting CPU load issues using the AGG renderer. The GD renderer seems
>> to
>> work fine with that small subset of our data. But, when I test our
>> entire site maps with either renderer, I am still having the same
>> issues. AGG causes CPU lockup as well as memory-hogging, and GD still
>> causes memory-hogging.
>>
>> It is still being caused by the same layer, so I will see if it's
>> possible to get an updated dataset to test with.
>>
>>
>> Jason Birch wrote:
>>     
>>> This issue is identified in RFC 52 as AGG-specific, and was in my
>>> initial testing as well:
>>>
>>> http://trac.osgeo.org/mapguide/wiki/MapGuideRfc52
>>>
>>> Are you seeing the same results when you switch to the GD renderer in
>>> 2.0.x?
>>>
>>> Jason
>>>
>>> -----Original Message-----
>>> From: Jonathan Manafi
>>> Subject: Re: [mapguide-users] what's holding people back from
>>>       
>> upgrading
>>     
>>> to 2.0?
>>>
>>> We experienced extreme CPU and/or memory consumption when we tested
>>>       
>> MGOS
>>     
>>> 2.x with some of our data. We created a ticket(#459
>>> https://trac.osgeo.org/mapguide/ticket/459) to document our problems,
>>> and I have been testing this issue with all of the updated releases,
>>>       
>> and
>>     
>>> I continue to see the same results. We can't zoom all the way into
>>>       
>> our
>>     
>>> maps without the server locking up and consuming all of the CPU,
>>>       
>> which
>>     
>>> is stopping us from moving a production environment to MGOS 2. We've
>>> been able to modify 1.2 to suit our needs for almost everything with
>>> plugins; and if we couldn't add a specific feature, we went in
>>>       
>> another
>>     
>>> direction.
>>>
>>> So far, that has been a killer for our migration.
>>>
>>>       
>> _______________________________________________
>> mapguide-users mailing list
>> mapguide-users at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapguide-users
>>     
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapguide-users/attachments/20081007/b9e502d9/attachment.html


More information about the mapguide-users mailing list