In that case turn on SQL logging, capture the SQL query that is taking so
long, and try it yourself with whatever query analysis tools provided by
Oracle. At the very least you can narrow the issue down to a) connection
time b) query execution c) result set processing/rendering
Tip: You may also want to cut down on the "Privileged/Confidential" footer
when posting to a public email list :)
Jody Garnett
On Thu, Aug 21, 2014 at 12:38 AM, Samyajit Talukdar <
samyajit.taluk...@scottishwater.co.uk> wrote:
> Hi,
> I understand that GeoServer 2.1.0 is quite outdated but there is no
> upgrade plan at the minute by the customer. Any suggestion would help us
> immensely.
>
> Thanks & Regards,
>
> Samyajit Talukdar
>
> ________________________________________
> From: Jody Garnett [jody.garn...@gmail.com]
> Sent: 20 August 2014 21:41
> To: Samyajit Talukdar
> Cc: geoserver-users@lists.sourceforge.net
> Subject: Re: [Geoserver-users] GeoServer2.1.0 with Oracle Spatial
> performance issue
>
> GeoServer 2.1.0 was released in 2011 and is no longer in development. Can
> you update to a newer version of GeoServer and run your benchmark again?
>
> Jody Garnett
>
>
> On Wed, Aug 20, 2014 at 11:11 AM, Samyajit Talukdar <
> samyajit.taluk...@scottishwater.co.uk<mailto:
> samyajit.taluk...@scottishwater.co.uk>> wrote:
> Hi,
> We have a GeoServer2.1.0 with Oracle plug-in deployed on Weblogic as an
> application. We have created layers for the Oracle Spatial data for
> projection on BIng maps. We are facing performance issues with a single
> overlay taking around 35 seconds to render on screen. On analysis of the
> GeoServer log(snippet below), it is noticed that there is a gap between
> 2014-08-20 15:37:03,232 and 2014-08-20 15:37:07,662. Is it the database
> queries running for 4 seconds? We are using JDBC connection pools to
> connect to the Oracle database. The spatial indexes have been analysed
> recently. Any suggestions to tune the database or tips to improving the
> performance will be highly appreciated.
>
> 2014-08-20 15:37:03,216 DEBUG [org.geotools.jdbc] - 1 = POLYGON
> ((-608830.7182036353 354213.0151268281, -608830.7182036353
> 578637.1600929049, -383996.34103620437 578637.1600929049,
> -383996.34103620437 354213.0151268281, -608830.7182036353
> 354213.0151268281))
> 2014-08-20 15:37:03,216 DEBUG [org.geotools.rendering] - Expanding
> rendering area by 2 pixels to consider stroke width
> 2014-08-20 15:37:03,232 DEBUG [org.geotools.rendering] - Querying layer
> http://sw.opengeo.org/iccsa:ICC_SA_LAYER_WOA_COVERAGE with bbox:
> ReferencedEnvelope[-16.89697265625 : -14.04052734375, 58.80260054809615 :
> 60.25095233761055]
> 2014-08-20 15:37:03,232 DEBUG [org.geotools.jdbc] - CREATE CONNECTION
> 2014-08-20 15:37:03,232 TRACE [org.geotools.core] - ENTRY 4
> 2014-08-20 15:37:03,232 DEBUG [org.geotools.filter] - exporting
> PropertyName
> 2014-08-20 15:37:03,232 DEBUG [org.geotools.jdbc] - SELECT
> ID,NAME,LOCATION as LOCATION FROM DW_GIS_STAGING.WOA_COVERAGE WHERE
> SDO_FILTER(LOCATION, ?, 'mask=anyinteract querytype=WINDOW') = 'TRUE'
> 2014-08-20 15:37:03,232 DEBUG [org.geotools.data.oracle.sdo] - Using layer
> SRID: 27700
> 2014-08-20 15:37:03,232 DEBUG [org.geotools.jdbc] - Setting parameter 1 as
> MDSYS.SDO_GEOMETRY(2003,27700,NULL,MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,3),MDSYS.SDO_ORDINATE_ARRAY(-456108.5008002104,1053235.9528774032,-263904.20541160624,1245178.5366634205))
> 2014-08-20 15:37:03,232 DEBUG [org.geotools.jdbc] - 1 = POLYGON
> ((-456108.5008002104 1053235.9528774032<tel:9528774032>, -456108.5008002104
> 1245178.5366634205, -263904.20541160624 1245178.5366634205,
> -263904.20541160624 1053235.9528774032, -456108.5008002104
> 1053235.9528774032))
> 2014-08-20 15:37:07,662 DEBUG [org.geotools.jdbc] - CLOSE CONNECTION
> 2014-08-20 15:37:07,662 DEBUG [org.geotools.rendering] - Style cache hit
> ratio: NaN , hits 0, requests 0
>
> Thanks & Regards,
>
> Samyajit Talukdar
>
> Privileged/Confidential information may be contained in this Email and any
> files transmitted with it. If you are not the intended recipient you should
> not retain, copy or use this Email for any purpose or disclose all or part
> of its contents to any person. If you have received this Email in error
> please notify the postmaster and sender immediately and delete this Email
> from your system.
>
> Opinions, conclusions and other information in this message that do not
> relate to the official business of Scottish Water ("SW"), Scottish Water
> Solutions Ltd ("SWS") or Scottish Water Solutions 2 Ltd ("SWS2") shall be
> understood as neither given nor endorsed by them. The contents of Emails
> sent and received by SW, SWS and SWS2 are monitored.
>
> WARNING: Although SW, SWS and SWS2 have taken reasonable precautions to
> ensure no viruses or other malicious software are present, SW, SWS and SWS2
> cannot accept responsibility for any loss or damage arising from the use of
> this Email or attachments however caused. The recipient should therefore
> check this Email and any attachments for the presence of viruses or other
> malicious software.
>
>
>
> Scottish Water
> www.scottishwater.co.uk<http://www.scottishwater.co.uk>
> www.scottishwatersolutions.co.uk<http://www.scottishwatersolutions.co.uk>
> postmas...@scottishwater.co.uk<mailto:postmas...@scottishwater.co.uk>
>
>
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds. Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> Geoserver-users mailing list
> Geoserver-users@lists.sourceforge.net<mailto:
> Geoserver-users@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>
>
>
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
