[mapserver-dev] More Performance

[Paul Ramsey]

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
>>
>