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

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? A further question: why does GeoServer perform a SELECT before?

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)

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

FINE: About to execute query:
SELECT "id", "damagevalue", "date_stamp", "comment", "assessor", "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)

FINE: sql statment is
DELETE from "public"."assessmentpoint"WHERE ("damagevalue" = 70.4 AND "comment" = '2006-01-01;insert WFS test' AND "damagecaseid" = 5161);

INFO: Service handled
Jul 11, 2007 5:13:51 PM org.vfny.geoserver.util.requests.XmlCharsetDetector getCharsetAwareReader
FINE: First 4 bytes of XML doc are : 3C ('<') 77 ('w') 66 ('f') 73 ('s')
Jul 11, 2007 5:13:51 PM org.vfny.geoserver.util.requests.XmlCharsetDetector getCharsetAwareReader
FINE: Charset detection phase 1. Inferred encoding: UTF-8
Jul 11, 2007 5:13:51 PM org.vfny.geoserver.util.requests.XmlCharsetDetector getXmlEncoding
WARNING: Invalid(?) XML declaration: <wfs:T.
Jul 11, 2007 5:13:51 PM org.vfny.geoserver.util.requests.XmlCharsetDetector getCharsetAwareReader
FINE: Charset detection phase 2. Charset in XML declaration is `null`.
Jul 11, 2007 5:13:51 PM org.vfny.geoserver.util.requests.XmlCharsetDetector createReader
FINE: Trying to create reader basing on existing charset information: `UTF-8`.
Jul 11, 2007 5:13:51 PM org.vfny.geoserver.util.requests.readers.DispatcherXmlReader getRequest
INFO: getting request type from org.vfny.geoserver.util.requests.DispatcherHandler@anonymised.com
Jul 11, 2007 5:13:51 PM org.vfny.geoserver.servlets.AbstractService doPost

best regards,
Sebastian

-----Ursprüngliche Nachricht-----
Von: Chris Holmes <cholmes@anonymised.com>
Gesendet: 11.07.07 16:13:32
An: Sebastian Paasche <paasche-plaue@anonymised.com>
CC: geoserver-users@lists.sourceforge.net
Betreff: Re: [Geoserver-users] GeoServer WFS-T: poor DELETE performance

Could you put the logging level at FINE and check the logs for the sql
statement that's being executed for DELETE's? Then try out that
statement in postgis directly? And send us what the sql statement is.

My guess might be that indexes on the properties you're filtering on
could help. Though there could be something off in the code, if we're
not passing a good sql statement back to the db. Also what version of
GeoServer and PostGIS are you using?

thanks,

Chris

Sebastian Paasche wrote:
> Hi all,
>
> currently I am evaluating the GeoServer according to functionality and performance issues.
> While executing some DELETE Requests to a PostGIS datastore I have to wait unexpectly long for a response.
> The postmaster process runs with 100% on an AMD Opteron 2.2 GHz, but a single
> DELETE request takes still about 1200 ms. By the way, INSERTs are performed well (<20ms).
> Am I doing anything wrong? By which means this process can be accelerated?
> Here is my XML-file which is sent by HTTP Post to the server in a local network:
>
> <wfs:Transaction service="WFS" version="1.1.0"
> xmlns:wfs="http://www.opengis.net/wfs&quot;
> xmlns:topp="http://www.geoserver.org/topp&quot;
> xmlns:gml="http://www.opengis.net/gml&quot;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot;
> xmlns:ogc="http://www.opengis.net/ogc&quot;
> xsi:schemaLocation="http://www.opengis.net/wfs http://schemas.opengis.net/wfs/1.0.0/WFS-transaction.xsd http://www.openplans.org/topp http://localhost:8080/geoserver/wfs/&quot;&gt;
> <wfs:Delete typeName="topp:assessmentpoint">
> <ogc:Filter>
> <ogc:And>
> <ogc:PropertyIsEqualTo>
> <ogc:PropertyName>topp:damagevalue</ogc:PropertyName>
> <ogc:Literal>70.4</ogc:Literal>
> </ogc:PropertyIsEqualTo>
> <ogc:PropertyIsEqualTo>
> <ogc:PropertyName>topp:comment</ogc:PropertyName>
> <ogc:Literal>2006-01-01;insert WFS test</ogc:Literal>
> </ogc:PropertyIsEqualTo>
> <ogc:PropertyIsEqualTo>
> <ogc:PropertyName>topp:damagecaseid</ogc:PropertyName>
> <ogc:Literal>5161</ogc:Literal>
> </ogc:PropertyIsEqualTo>
> </ogc:And>
> </ogc:Filter>
> </wfs:Delete>
> </wfs:Transaction>
>
>
> Thanks in advance,
> Sebastian
> _______________________________________________________________________
> 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
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Geoserver-users mailing list
> Geoserver-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>
> !DSPAM:4005,4694aebb238071804284693!
>

_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000066

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