Re: [Geoserver-users] Overworked CPU .. GeoServer & Oracle

[Tom (J. Solutions) <tom...@jd...>]

Now there might be something in that... A short while ago I asked whether
the bounding box was needed for anything and was told that it's not so I've
not been worrying too much about it's accuracy.  When setting up the feature
type because there are so many features in the table it takes too long to
calculate the max values (don't know why that should be seeing as there's a
spatial index and you'd think that would make it fast) so I've been relying
on waiting for the geoserver command prompt window to output the results
then convert them using Oracle into lat lng before entering them manually
into the bounding box fields.  Now, I'm fairly sure they're correct but the
amount of time it takes to calculate them would certainly slow the server
down if it's doing them with every request.  So I guess the next question
is, under what conditions does it attempt to calculate them?  Like I said,
despite the slightly strange method of entering them I'm confident they're
right.  Also, while geoserver and Oracle continue to whirr away Geoserver
outputs references to getLegendGraphic.  What does that do and what's it got
to do with a wfs request?

Andrea, if you don't mind trying this out that would be great.  I've
exported and zipped one of the layers and it comes out at a very respectable
181MB so I can upload that somewhere in a few hours for you to have a go
with.  For now though, enjoy your holiday!

cheers,

Tom



On 7/26/07, aaime <aa...@op...> wrote:
>
>
>
> Tom Dean wrote:
> >
> > Justin, thanks for your thoughts.  I'm zoomed in to a specific area of
> the
> > map, perhaps less than 1/400th of the total dataset and as I said, the
> > layer
> > seems to be rendered correctly and completely but geoserver and oracle
> > continue to work hard.
> >
> > Andrea, any thoughts?  I could supply the data for you assuming it
> remains
> > confidential (it's protected by strict copyright) but obviously it would
> > be
> > a large download, the export will prob be a gig for topo_line.
> >
>
> The dataset in "exp" format will help for sure, in "exp" format and
> compressed.
> It'll help when I come back from my vacation, that is. From here (sea side
> with
> a 6 old years notebook and a 20kbit/s connection) there is nothing I can
> really
> do.
>
> The load you see seem to suggest either a large data request, that
> Geoserver
> is trying to satifsy anyways, or a last resort bounding box computation:
> when
> the datastore is not able to compute the bbox quickly (usually because of
> some spatial index or geometry metadata mis-setup) it'll fall down on the
> "load all features and extract the bbox from each" approach, which would
> be really really costly.
>
> If this is the latter, you can spot easily, go to the feature type config
> and
> (after properly setting up the SRS) hit "generate bbox", this will compute
> the
> bbox in lat/lon and also store the native one on disk so that its
> computation is
> no more needed. When you've done that, apply/save and then try again
> hitting Geoserver with uDig.
>
> Good luck :)
> Cheers
> Andrea
> --
> View this message in context:
> http://www.nabble.com/Overworked-CPU-..-GeoServer---Oracle-tf4150028.html#a11818604
> Sent from the GeoServer - User mailing list archive at Nabble.com.
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Geoserver-users mailing list
> Geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>