<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
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.<br>
<blockquote>- In the AGG renderer, hitting under 1:100 caused the
server to consume steady 50% CPU.<br>
- In GD, nothing happened. The server continued to respond the same as
in normal conditions. <br>
</blockquote>
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.<br>
<br>
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?<br>
<br>
Thanks for your help.<br>
<br>
<br>
Traian Stanev wrote:
<blockquote
cite="mid:D20FC5C02CA4AB41891CFE76D91C57A93802EC5A41@ADSK-NAMSG-02.MGDADSK.autodesk.com"
type="cite">
<pre wrap="">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
</pre>
<blockquote type="cite">
<pre wrap="">-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:mapguide-users-bounces@lists.osgeo.org">mapguide-users-bounces@lists.osgeo.org</a> [<a class="moz-txt-link-freetext" href="mailto:mapguide-users">mailto:mapguide-users</a>-
<a class="moz-txt-link-abbreviated" href="mailto:bounces@lists.osgeo.org">bounces@lists.osgeo.org</a>] 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:
</pre>
<blockquote type="cite">
<pre wrap="">This issue is identified in RFC 52 as AGG-specific, and was in my
initial testing as well:
<a class="moz-txt-link-freetext" href="http://trac.osgeo.org/mapguide/wiki/MapGuideRfc52">http://trac.osgeo.org/mapguide/wiki/MapGuideRfc52</a>
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
</pre>
</blockquote>
<pre wrap="">upgrading
</pre>
<blockquote type="cite">
<pre wrap="">to 2.0?
We experienced extreme CPU and/or memory consumption when we tested
</pre>
</blockquote>
<pre wrap="">MGOS
</pre>
<blockquote type="cite">
<pre wrap="">2.x with some of our data. We created a ticket(#459
<a class="moz-txt-link-freetext" href="https://trac.osgeo.org/mapguide/ticket/459">https://trac.osgeo.org/mapguide/ticket/459</a>) to document our problems,
and I have been testing this issue with all of the updated releases,
</pre>
</blockquote>
<pre wrap="">and
</pre>
<blockquote type="cite">
<pre wrap="">I continue to see the same results. We can't zoom all the way into
</pre>
</blockquote>
<pre wrap="">our
</pre>
<blockquote type="cite">
<pre wrap="">maps without the server locking up and consuming all of the CPU,
</pre>
</blockquote>
<pre wrap="">which
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">another
</pre>
<blockquote type="cite">
<pre wrap="">direction.
So far, that has been a killer for our migration.
</pre>
</blockquote>
<pre wrap="">_______________________________________________
mapguide-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mapguide-users@lists.osgeo.org">mapguide-users@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/mapguide-users">http://lists.osgeo.org/mailman/listinfo/mapguide-users</a>
</pre>
</blockquote>
</blockquote>
</body>
</html>