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: [EMAIL PROTECTED] [mailto:mapguide-users-
[EMAIL PROTECTED] 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
[email protected]
http://lists.osgeo.org/mailman/listinfo/mapguide-users
_______________________________________________
mapguide-users mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/mapguide-users
