On Tue, Jan 24, 2012 at 9:05 AM, Bas Couwenberg <[email protected]>wrote:
> Momentarily we are trying to switch from our current GIS server to
> Geoserver and while comparing the two I noticed some performence issues.
> When executing a GetMap request for a single (256x256) tile with a Oracle
> datastore there is a 3-4 second delay which is shown in the log. This is
> before the actual query is executed and I don't see why this delay is
> there. The rest of the image creation is done in milliseconds. These 3-4
> seconds is between a CREATE CONNECTION and CLOSE CONNECTION:
>
>
> 08:41:03,819 INFO [STDOUT] 24 jan 08:41:03 INFO [org.geoserver.wms] -
> Request: getServiceInfo
> 08:41:03,833 INFO [STDOUT] 24 jan 08:41:03 DEBUG [org.geotools.styling] -
> number of fts set 1
>
> 08:41:03,845 INFO [STDOUT] 24 jan 08:41:03 DEBUG [org.geotools.jdbc] -
> CREATE CONNECTION <-----------------------
> 08:41:07,229 INFO [STDOUT] 24 jan 08:41:07 DEBUG [org.geotools.jdbc] -
> CLOSE CONNECTION <-----------------------
>
> 08:41:07,236 INFO [STDOUT] 24 jan 08:41:07 DEBUG [org.geotools.styling] -
> number of fts set 1
> 08:41:07,242 INFO [STDOUT] 24 jan 08:41:07 DEBUG [org.geotools.rendering]
> - Computed scale denominator: 3779.759863681462
> 08:41:07,248 INFO [STDOUT] 24 jan 08:41:07 DEBUG [org.geotools.styling] -
> number of fts set 1
> 08:41:07,254 INFO [STDOUT] 24 jan 08:41:07 DEBUG [org.geotools.rendering]
> - processing 1 stylers for...
> 08:41:07,259 INFO [STDOUT] 24 jan 08:41:07 DEBUG [org.geotools.rendering]
> - creating rules for scale denominator - 3.779,76
> 08:41:07,265 INFO [STDOUT] 24 jan 08:41:07 DEBUG [org.geotools.styling] -
> creating defaultMark
> 08:41:07,271 INFO [STDOUT] 24 jan 08:41:07 DEBUG [org.geotools.styling] -
> creating defaultMark
> 08:41:07,276 INFO [STDOUT] 24 jan 08:41:07 TRACE [org.geotools.styling] -
> ENTRY
> 08:41:07,282 INFO [STDOUT] 24 jan 08:41:07 DEBUG [org.geotools.styling] -
> creating defaultMark
> 08:41:07,287 INFO [STDOUT] 24 jan 08:41:07 DEBUG [org.geotools.rendering]
> - Expanding rendering area by 4 pixels to consider stroke width
> 08:41:07,292 INFO [STDOUT] 24 jan 08:41:07 DEBUG [org.geotools.rendering]
> - Querying layer ...
> 08:41:07,304 INFO [STDOUT] 24 jan 08:41:07 DEBUG [org.geotools.jdbc] -
> CREATE CONNECTION
> 08:41:07,308 INFO [STDOUT] 24 jan 08:41:07 TRACE [org.geotools.core] -
> ENTRY 4
> 08:41:07,313 INFO [STDOUT] 24 jan 08:41:07 DEBUG [org.geotools.filter] -
> exporting PropertyName
> 08:41:07,318 INFO [STDOUT] 24 jan 08:41:07 DEBUG [org.geotools.jdbc] - ...
> 08:41:07,324 INFO [STDOUT] 24 jan 08:41:07 DEBUG
> [org.geotools.data.oracle.sdo] - Using layer SRID: 90112
> 08:41:07,329 INFO [STDOUT] 24 jan 08:41:07 DEBUG [org.geotools.jdbc] -
> Setting parameter 1 as MDSYS.SDO_GEOMETRY(2003,90112,NULL,MDSYS.SDO_ELEM_
> 08:41:07,334 INFO [STDOUT] 24 jan 08:41:07 DEBUG [org.geotools.jdbc] - 1
> = POLYGON ((98287.00731434968 439283.53962355264, 98287.00731434968 439
> 08:41:07,347 INFO [STDOUT] 24 jan 08:41:07 DEBUG [org.geotools.rendering]
> - trying to render symbol square
> 08:41:07,352 INFO [STDOUT] 24 jan 08:41:07 DEBUG [org.geotools.rendering]
> - rendering mark @ PointRenderer square
> 08:41:07,358 INFO [STDOUT] 24 jan 08:41:07 DEBUG [org.geotools.rendering]
> - fetching mark of name square
> 08:41:07,362 INFO [STDOUT] 24 jan 08:41:07 DEBUG [org.geotools.rendering]
> - returning square
> 08:41:07,390 INFO [STDOUT] 24 jan 08:41:07 DEBUG [org.geotools.jdbc] -
> CLOSE CONNECTION
>
> Is this something that can be optimized in any way? It would make the
> request alot faster.
>
I don't know for sure what happens during that time, but if this is the
first
request that part is inspecting your database dictionary and geometry
metadata
tables to figure out the table structure (attribute and types) and the
geometry type
and native srid (from MDSYS views).
However that much should be cached in memory and the next query should be
fast.
Indeed locally I can run tens to hundreds of WMS requests per second
against
Oracle without problems.
Maybe you have a whole lot of layers, like a few hundreds? In that case the
feature type cache won't keep everything in memory, it's sized to keep
200 entries afaik, but you can go in the the "server" page and set a
different
value (normally it's 0, which really means "use the default").
Another possibility is that you're using a connection pooling solution that
does not
like GeoServer unwrapping the connections, something that happens if
you are runing WebLogic for example, when that happens the pool decides to
throw away the conneciton and thus you're always getting new connections.
In that case the pool can be instructed not to throw away the connections
(which reminds me, I have to prepare a Weblogic tutorial one day or the
other...)
Cheers
Andrea
--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
-------------------------------------------------------
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Geoserver-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
