On Sat, Apr 28, 2012 at 4:29 PM, Andrea Aime
<andrea.aime@anonymised.com> wrote:
The other thing that raises my interest and worries me is "starting up in
seconds".
My understanding of the current startup slowness is mostly due to the
validation checks we do on startup to see if a layer/feature type/store are
working
and valid, that results in opening all stores, computing the feature types
and so on.
yeah, mostly. On my laptop the validation takes something between ~60%
of the time, while listing and parsing the xml's the other 40%. It is
using a fast SSD though, mileage will vary depending on CPU/Disk. To
try out:
1- apply the attached patch, which logs the time spent loading the
catalog and disables all the validation calls at CatalogImpl
2- clear disk cache. (as root, run echo 3 > /proc/sys/vm/drop_caches)
3- start up GeoServer
I get the following logged: Catalog read in 65628 ms
4- Do not undo the changes to CatalogImpl (i.e. restore the validation
checks), but let the load time logging on:
git co main/src/main/java/org/geoserver/catalog/impl/CatalogImpl.java
5- repeat 2) and 3). I get the following with validation enabled:
Catalog read in 156869 ms
Repeat with PRODUCTION_LOGGING logging profile, so that logging
doesn't eat up valuable time:
Without any validation: Catalog read in 58732 ms
With validation: Catalog read in 148411 ms
Maybe the jdbc config is that much faster because it's not loading
everything up front
and thus those listeners are not being called?
Indeed it is not doing that.
If so we have a problem at hand, since the listeners are there to prevent
the caps
documents to error miserably with a service exception at the first sign of
trouble.
Ah, right. Thanks for pointing that out. Easy to forget, we should
document that.
You may say that's a design issue in the caps generator and I would agree,
me
and Justin discussed it a bit during the FOSS4G-NA code sprint, we basically
can remove those checks if we can make the XML documents generation
"transactional" in some way, that is, put a mark on the ouput stream,
generate
the xml for a layer, if it's ok push it out, in case of exception throw away
the
buffer and start back from the mark, and so on.
This would have to be made for all caps document, for rest-config parts that
do list resources, and for all Describe* calls (since they need to accept
the
lack of an identifier as a request to describe all that you have in the
server).The above would be very welcomed, but we need to make sure it's there
before un-plugging the listeners that keep GeoServer caps generation sane
You bring up a very good point here.
By one side, re startup checks, I think they're a good think and we
may want to enable them on each and every catalog implementation. The
way it's been currently done is not too friendly to other
implementations though, as it's calling add(XXXInfo) to the Catalog
and relying on it performing the needed checks. But yeah, we could
look into some way of telling the CatalogFacades if/whether to do a
full scan and verify the sanity of all resources.
By the other hand, this seems a little bit weird, as doing so we're
only validating the full config at start up time, so you know you
started up with a sane config but can't do nothing if it breaks
afterwards, like a database going down (re capabilities generation at
least).
So of course what you propose in that regard makes sense and looks
good. Back to the original point of full scan of resources for sanity
check at start up, I'm not sure whether other systems with large
amounts of configuration objects do that, and if so whether the
startup slowness is acceptable, but it can certainly be done if it's a
must for GeoServer. I just overlooked at it I think because afaik the
dbconfig module doesn't do that either and it didn't occur to me.
Cheers,
Gabriel
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.
(attachments)
no_validation.patch (5.08 KB)