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^). But I guess anything might be happening in there. We're attempting to get tracing on the DB side to see what's going on, but so far haven't found a friendly-enough DBA. 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. Will communicate any findings we have, to help improve the support for Oracle. (Postgres does tend to scare people at this particular client, unfortunately. We did float the idea of using a "local data cache" built on top of a special technology ideally suited for this purpose whose initials just happen to be PG... but so far no bites. However, if we can show a major improvement in map image request performance, we might still be able to make this fly...) On Thu, Jul 30, 2015 at 1:42 PM, Andrea Aime <andrea.a...@geo-solutions.it> wrote: > On Thu, Jul 30, 2015 at 7:56 PM, Martin Davis <mtncl...@gmail.com> wrote: > >> We have the following GeoServer setup: >> >> Datastore to an Oracle 12c Exadata instance >> Internal connection pooling >> No schema specified >> > > What GEoServer version? > > >> >> We noticed a serious performance anomaly, where each layer was taking >> about 4 s to render, even when the data was very small. >> >> When we switched to specifying an explicit schema in the Datastore >> config, the performance got significantly faster, and the time to render >> individual layers became more proportional to the query result size. >> >> So the questions are: >> 1. does omitting a schema name in the Oracle Datastore config cause >> connection pooling to be disabled or defeated? >> > > While I cannot ensure I won't be hit by an asteroid in the next hour, > that's unlikely. So is the idea that not setting > up the catalog can break connection pooling. > > It will likely slow down things for other reasons unrelated to connection > pooling instead. > Oracle is a database from hell, if you don't setup the catalog the jdbc > driver returns a huge number of tables (50k on some installations?) when > you get the > database metadata. > We had issues with caching metadata at the content data store level, with > the Oracle dialect not using prepared statements > for metadata (pull request still open, I'm unable to find the time to > review it, see here: > https://github.com/geotools/geotools/pull/905), and likely something else > that I don't remember. > > I would suggest to try trunk, with the above pull request applied, and see > if it gets any better. > > >> 2. Will this issue be avoided when using a JNDI connection pool? >> > > Not directly, but with JNDI you can setup a single connection pool and > then setup N datastores, one for each > of the catalogs you need to access. > > Investigations and patches welcomed too, we have a large disconnect > between people using and complaining > about Oracle and people actually doing something about it. The common > wisdom is to just drop > Oracle in favor of PostGIS, when one can (yes, I'm well aware that's often > not an option). > > >
------------------------------------------------------------------------------
_______________________________________________ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
