[mapserver-dev] More Performance

[thomas bonfort]

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