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
