[Geoserver-users] GeoServer WFS-T: poor DELETE performance

OK. Thanks for your investigations! :slight_smile:

Sebastian

-----Ursprüngliche Nachricht-----
Von: Andrea Aime <aaime@anonymised.com>
Gesendet: 12.07.07 09:57:36
An: paasche-plaue@anonymised.com
CC: Chris Holmes <cholmes@anonymised.com>, geoserver-users@lists.sourceforge.net
Betreff: Re: [Geoserver-users] GeoServer WFS-T: poor DELETE performance

paasche-plaue@anonymised.com ha scritto:
> Hi Chris,
>
> sorry for the missing software version information: GeoServer 1.5.1
> PostGIS 1.1.2
>
> After a while of searching through log-jungle I picked out some
> fragments. The SQL query is fine. I tested the query directly and got
> a response about 500 ms later. By the way, deegree WFS handled the
> WFS-T requested in about 700 ms; GeoServer needed 1500 ms in the last
> run. I noticed that there's a warning which points to the
> xml-parsing process. Maybe that's a fact which could explain a delay?

No, that's not it.

> A further question: why does GeoServer perform a SELECT before?

Explanations below.

>
> FINE: request is Lock Id: null releaseAction: ALL handle: null Delete
> Feature Request feature type:topp:assessmentpoint filter:[[
> damagevalue = 70.4 ] AND [ comment = 2006-01-01;insert WFS test ] AND
> [ damagecaseid = 5161 ]] release:true
>
> FINE: SELECT AsText(force_2d(Envelope(Extent("geom")))) FROM
> "public"."assessmentpoint" WHERE ("damagevalue" = 70.4 AND "comment"
> = '2006-01-01;insert WFS test' AND "damagecaseid" = 5161)

This one is for the WFS validation subsystem, that can be used to
check the transaction keeps data within certain limits (you can think
of it as a trigger like check, but working in GeoServer, that is,
independent of the datastores used). See http://vwfs.refractions.net/
for more information.

It could be optimized away if no validation is active for that
particular feature type.

> FINE: sql is SELECT "id", "damagevalue", "date_stamp", "comment",
> "assessor", "deegree", "damagecaseid", "damageareaid",
> encode(AsBinary(force_2d("geom"), 'XDR'),'base64') FROM
> "public"."assessmentpoint" WHERE ("damagevalue" = 70.4 AND "comment"
> = '2006-01-01;insert WFS test' AND "damagecaseid" = 5161) Jul 11,
> 2007 5:13:50 PM org.geotools.data.jdbc.JDBC1DataStore executeQuery

This one is a little stupid in that we just need the ids, but anyways
it's used to unlock all deleted features. We could try to optimize
it away if no features is locked for that particular feature type,
unfortunately that would require a break in the GeoTools published
API so we cannot do this for Geoserver 1.5.x (and we're probably already
late for 1.6.x as well).
I think this query is the one that accounts for the large performance
difference.

Cheers
Andrea

_______________________________________________________________________
Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 3 Monate
kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=022220

paasche-plaue@anonymised.com ha scritto:

OK. Thanks for your investigations! :slight_smile:

No problem. If delete performance is critical to you and you want those two solved, can you open a jira issue and schedule it for 1.5.2?
jira.codehaus.org/browse/geos

Cheers
Andrea