On Wed, May 9, 2012 at 8:09 AM, Bertrand, Matthew <[email protected]
> wrote:
> Thanks Justin!
>
> It sounds like there's a pretty steep learning curve to get up to speed on
> this part of the code, but I'd be willing to take a shot at figuring out a
> fix for this if you think it's potentially doable given enough time/effort.
>
Help would be great. I would suggest start by familiarizing yourself with
the DescribeFeatureType code and the underlying FeatureTypeSchemaBuilder,
that is where the schema objects used by WFS are build.
>
> One thing I should correct about my previous email response – it seems the
> excessive time it took to complete WFS transactions with PostGIS layers
> after changing the feature cache size was actually triggered by reloading
> the config & catalog from the server status page afterward. If I skip that
> particular step and just set the feature cache to a high value on the
> global settings page, then the response time is much better. I probably
> shouldn't try debugging & emailing about it at 5 in the morning!
>
> Haha no worries.
> One thing I've noticed is that the first WFS response after geoserver is
> started (or after a long enough period of inactivity) always takes awhile
> to complete, but subsequent transactions are much faster. However, those
> subsequent transactions have also slowed a bit as the number of layers has
> grown on our production server – from an initial speed of about 1-2 seconds
> (with ~2000 layers) to about 12-15 seconds now (with ~4200). The feature
> type cache size had already been set to 5000 a few months back.
>
Right, this startup cost is typically the building of the internal GML
schemas, which are huge and costly to load. But once loaded they are cached
so you don't pay the price for future accesses.
>
>
-Matt
>
>
> From: Justin Deoliveira <[email protected]>
> Date: Wed, 9 May 2012 09:40:04 -0400
> To: Matt Bertrand <[email protected]>
> Cc: "[email protected]" <
> [email protected]>
>
> Subject: Re: [Geoserver-devel] Slow WFS transactions when GeoServer 2.1
> catalog has thousands of layers
>
> Unfortunately this is a known issue and even more unfortunately not one
> that will probably be solved soon. The way we manage schema objects for the
> purposes of parsing/encoding gml is a rather sad story. There are two main
> issues.
>
> 1. There is no caching that occurs, which is the main problem here and is
> very problematic for large catalogs.
>
> 2. We do scan the entire catalog when we really don't have to. The only
> case where its necessary is for app-schema where the full scan occurs
> because you don't know ahead of time for any one feature type what
> application schema namespaces it may reference. So a full scan is done to
> include all of them.
>
> A while back I experimented on a branch to fix these issues, and had some
> success unfortunately it was pretty exploratory code and nothing that was
> suitable for commit. And I never really came up with a good solution for
> the app-schema issue.
>
> Long story short this one without funding or some other mandate probably
> won't be fixed in the short term.
>
> -Justin
>
> On Tue, May 8, 2012 at 7:40 PM, Bertrand, Matthew <
> [email protected]> wrote:
>
>> Hello,
>>
>> I've noticed that WFS transactions (insert, update) have become slower as
>> the number of layers in my GeoServer 2.1 instance has increased (it's
>> currently at a little over 4000 layers, most of them sharing one PostGIS
>> store and the rest are geotiffs). On every WFS transaction, GeoServer
>> seems to iterate over every layer in the catalog, I guess this is in order
>> to generate XSD schema objects? Do you think it might be possible to avoid
>> this somehow and get the information that it that needs to complete the
>> transaction only from the one layer being edited?
>>
>> -Matt
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Geoserver-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>>
>
>
> --
> Justin Deoliveira
> OpenGeo - http://opengeo.org
> Enterprise support for open source geospatial.
>
>
>
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
