So are you in position to profile the code? We recently enabled the database online tests again, but they test conformance, not performance.
-- Jody Garnett On 1 September 2015 at 14:38, Martin Davis <mtncl...@gmail.com> wrote: > Yes, we are suspicious that the metadata queries are returning a lot of > rows when no schema is specified. But can't confirm this is happening, > until we can get DB-level tracing enabled. > > And as you say, why would this be happening on every GetMap ? And why > happening in one environment and not in a similar different one? > > On Tue, Sep 1, 2015 at 2:13 PM, Jody Garnett <jody.garn...@gmail.com> > wrote: > >> I have a silly suggestion, when not using a schema is the data store >> getting back an amazingly large number of oracle tables .. checking each >> one for a spatial index and so on? >> >> I would expect that to take a bit longer on startup ... but you are >> indicating that every GetMap request is consistently slow. >> >> -- >> Jody Garnett >> >> On 1 September 2015 at 12:46, Martin Davis <mtncl...@gmail.com> wrote: >> >>> An update on this issue. >>> >>> As Andrea predicted, using a JNDI connection made no difference to the >>> performance issue (no schema still substantially slower than using a >>> schema). >>> >>> We're now attempting to do Oracle logging to try and see what's getting >>> run that might slow a map request down. (We have only limited access to >>> the box where the problem shows up). Results are not conclusive so far, >>> but we think we are seeing several queries being run over as many as 5 >>> different "Geoserver sessions" during a single map request. Cannot tell >>> what these are yet, but seems likely they are metadata queries. This is >>> odd, since we are not seeing this happen in another similar environment. >>> One difference is that we are connecting via an Oracle Service rather than >>> a SID in the slow environment. Would be odd if this was the cause, though. >>> >>> >>> On Fri, Jul 31, 2015 at 10:02 AM, Martin Davis <mtncl...@gmail.com> >>> wrote: >>> >>>> Thanks, Andrea. >>>> >>>> We're using GeoServer 2.6.0 >>>> >>>> The performance issue occurs for map requests - so wouldn't this be >>>> something different to the issue with slow metadata loading (The metadata >>>> retrieval is an issue we've seen as well, but it only hurts the admin, not >>>> the users, so we're less caring about that 8^). >>>> >>>> We'll probably try using a JNDI pool and see whether that helps at >>>> all. If so, we may just use that approach. If not, we'll be looking for a >>>> code fix - which we can likely get funded and contribute back. >>>> >>>> >>>> >>> >>> ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Geoserver-users mailing list >>> Geoserver-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/geoserver-users >>> >>> >> >
------------------------------------------------------------------------------
_______________________________________________ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
