[Geoserver-devel] Heavy slowdown in CITE wfs builds (DFT taking a lot longer?)

Hi,
I was trying to run the CITE WFS tests to double check some modifications I’m making
to the XML encoder and found out the test were taking… forever!

At first I thought it was due to some of my changes, but looking at the hudson build
time trend for the cite wfs 1.0 tests it seems it has been like that for some time already:

http://hudson.opengeo.org/hudson/view/cite/job/cite-wfs-1.1/buildTimeTrend

As you can see betwen build 352 and 353 there has been a solid jump from 1.5 minutes
to run the cite wfs 1.1 tests to over 7 minutes, in a rather stable manner.
So it seems between March 30 and March 31 a commit made WFS significantly
slower.
The builds on trunk also jumped the same day.

As far as I can see the slow requests are the ones that are post-ed, get requests are
fast as before, so I guess the slowdown occurred in xml parsing.

Looking at the commits in GeoTools I see nothing in the xsd module around those
dates though…

May this be just a coincidence, and the slowdown can be explained by something else?
(like, dunno, the VM on which hudson runs being moved to a busier or slower system?)

I’ll keep investigating in the meantime

Cheers
Andrea

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf


On Sun, May 22, 2011 at 5:16 PM, Andrea Aime <andrea.aime@anonymised.com.1268…> wrote:

Hi,
I was trying to run the CITE WFS tests to double check some modifications I’m making
to the XML encoder and found out the test were taking… forever!

At first I thought it was due to some of my changes, but looking at the hudson build
time trend for the cite wfs 1.0 tests it seems it has been like that for some time already:

http://hudson.opengeo.org/hudson/view/cite/job/cite-wfs-1.1/buildTimeTrend

As you can see betwen build 352 and 353 there has been a solid jump from 1.5 minutes
to run the cite wfs 1.1 tests to over 7 minutes, in a rather stable manner.
So it seems between March 30 and March 31 a commit made WFS significantly
slower.
The builds on trunk also jumped the same day.

As far as I can see the slow requests are the ones that are post-ed, get requests are
fast as before, so I guess the slowdown occurred in xml parsing.

Looking at the commits in GeoTools I see nothing in the xsd module around those
dates though…

May this be just a coincidence, and the slowdown can be explained by something else?
(like, dunno, the VM on which hudson runs being moved to a busier or slower system?)

I’ll keep investigating in the meantime

I guess I came to the wrong conclusions: enabled the request logging and all requests
are actually taking like 100ms to be executed (good thing the logging also reports execution
time).

So my guess would be that it’s the CITE engine that got a lot slower instead… I can see
the network being used in these idle times, would not be suprised if the thing was trying
to fetch schemas from somwhere in the network.

Any clue? :slight_smile:

Btw, if I wait and let it go it becomes fast past the DFT section of the tests
and everything passes.

Cheers
Andrea

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf


On Sun, May 22, 2011 at 5:35 PM, Andrea Aime <andrea.aime@anonymised.com.1268…> wrote:

Btw, if I wait and let it go it becomes fast past the DFT section of the tests
and everything passes.

As a last bit of info, WFS 1.0 cite tests are not affected, they are as slow as usual (due
to the smart people that decided to have tests with locks wait on lock for minutes
but it’s another story and has always been like that)

Cheers
Andera

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf


Interesting. There were some changes made recently to describe feature types with regard to schema references and some stuff specific to GML3, the patch was provided by Ben. I reviewed it but thought it should only affect app-schema stuff. Perhaps it creeped out. Ben any idea if recent changes are forcing us to download external schemas?

On Sun, May 22, 2011 at 9:39 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Sun, May 22, 2011 at 5:35 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Btw, if I wait and let it go it becomes fast past the DFT section of the tests
and everything passes.

As a last bit of info, WFS 1.0 cite tests are not affected, they are as slow as usual (due
to the smart people that decided to have tests with locks wait on lock for minutes
but it’s another story and has always been like that)

Cheers
Andera

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf



What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including clusters.
http://p.sf.net/sfu/intel-dev2devmay


Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.