Thanks for your analysis, John. I am not sure what is going on. Rini?

I don't think joining is going to help you if you are only using one 
source table.

Where are you getting your feature IDs? CQL in idExpression is another 
cause of performance degradation.
http://docs.geoserver.org/latest/en/user/data/app-schema/mapping-file.html#idexpression

Kind regards,
Ben.

On 15/10/12 19:25, jdoley wrote:
> Ben,
>
> I had very carefully setup joining support, following the doc for 2.2.x
> (even though I'm not really joining anything since I'm only using one table
> and I only use the mapping file to change the names of the features). The
> doc says I must use datasources, so I am (I also tried WebLogic Server 11g,
> but app-schema with datasources fails with Oracle - I think this is a jdbc
> driver conflict, but haven't pursued it).
>
> I'm using Geoserver 2.2, Apache on Red Hat 5.7, and Oracle 11g with a simple
> Oracle Spatial table. As I said, my test layer uses a datasource and I start
> Apache with -Dapp-schema.joining=true (and also tried the other approach of
> app-schema.properties file)
>
> For comparison, I have 2 namespaces/datastores using the exact same Oracle
> table: one in a default SF-0 layer created from the GUI, and the other is my
> simplest of app-schema setups. With the joining support turned on, I always
> get the same behavior for a GetMap with BBOX as I do without the joining
> support (which I can see with verbose logging):
>
> 1) one select for the BBOX
> 2) one select for each individual feature returned in select '1'
>
>
> I've been looking at the GeoTools 8.2 code in
>
>
> modules\library\render\src\main\java\org\geotools\renderer\lite\StreamingRenderer.java
>
> and my suspicion is that inside the while loop in
> StreamingRenderer.drawPlain
>
>              Iterator iterator = null;
>              if (collection != null)
>                  iterator = collection.iterator();
>              if (features != null)
>                  iterator = features.iterator();
>
>               etc
>
>                  while (iterator.hasNext()&&  !renderingStopRequested) {
>                      try {
>                          rf.setFeature(iterator.next());
>                          process(rf, liteFeatureTypeStyle, scaleRange, at,
> destinationCrs, layerId);
>
> the complex feature iterator.next method is triggering the unwanted selects
> I'm seeing.
>
> This is the flimsiest of theories, though, since I don't have any way to
> actually debug the code in my environment. I see you're an author of parts
> of the app-schema extension so you know much better than I do, but is it
> possible that this is a real bug or issue and it hasn’t been noticed because
> app-schema may not be used much for GetMaps (or GetMaps with thousands of
> results)?
>
>
> Thanks for thinking about this.
>
>
>
>
> --
> View this message in context: 
> http://osgeo-org.1560.n6.nabble.com/app-schema-GetMap-very-slow-with-larger-feature-sets-tp5008265p5008694.html
> Sent from the GeoServer - User mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Geoserver-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-users

-- 
Ben Caradoc-Davies <[email protected]>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Geoserver-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Reply via email to