I must concur with Greg; we have a layergroup that has layers from about 60
different database tables, though only up to 15 are visible at any one
time. This takes along time to render (up to a full minute) - and after
investigation it appears this is because of the database/GeoServer
interaction. The database is Oracle. We're doing a few things to try and
optimise it.
To find out what is taking time, turn on GEOTOOLSDEVELOPER level logging.
Then run the slow query. When it's finished look in the logs and you should
be able to gather what parts of the query are taking how long (or you can
post it to pastebin and link it here).
Jonathan
On 29 October 2013 10:04, Hans Gregers Petersen <greg...@septima.dk> wrote:
> Hi Ravyn
> (Sorry for the direct reply, this one goes to the list instead)
>
> > The source data is a database. Yes I mean 15 layers in the base map.
>
> In our experience, and I am sure that many here will agree, there are
> then several things you could look at DBS, Geoserver, caching, and
> clustering - the usual culprit we see is "poor" database design. The
> reason I say "usual" is that people often focus on tuning the front
> end - ie. GeoServer or GeoWebCache - and forget the backend.
>
> Most DBS support some sort of spatial index - in my experience the
> best and easiest are found in PostGIS, whereas for instance MSSQLs
> implementation needs to be (continuously) hand-tuned. If you have some
> common filters you use (either from Geoserver or in a WHERE-clause)
> then make sure that these are analyzed and properly index accordingly.
>
> Maybe you could give us a little more detail on your database system/setup?
>
> > I have had a look at the geowebcache and copied the war file in the
> apache
> > tomcat webaps folder but for some reason when I click on it , it gives
> me a
> > whole error file list so I am not to sure what exactly I'm doing wrong
> with
> > it. I'm sort of not 100% sure how it works with geoserver though either.
>
> Please do not do that, GeoServer comes with a built-in GWC which
> should suit most needs.
>
>
> Best regards,
>
> Greg
>
>
> ------------------------------------------------------------------------------
> Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this white
> paper to learn more about secure code signing practices that can help keep
> Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
> _______________________________________________
> Geoserver-users mailing list
> Geoserver-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>
--
This transmission is intended for the named addressee(s) only and may
contain sensitive or protectively marked material up to RESTRICTED and
should be handled accordingly. Unless you are the named addressee (or
authorised to receive it for the addressee) you may not copy or use it, or
disclose it to anyone else. If you have received this transmission in error
please notify the sender immediately. All email traffic sent to or from us,
including without limitation all GCSX traffic, may be subject to recording
and/or monitoring in accordance with relevant legislation.
------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
