[mapserver-dev] More Performance
thomas.bonfort at gmail.com
Mon May 12 15:32:40 EDT 2008
>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.
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.
> >>> 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
More information about the mapserver-dev