thanks a lot for downloading the data and trying it out, I really appreciat=
It seems you got it right, now it makes complete sense to me.
aside, I didn't notice a throughput slowdown from 1.5. to 1.6 for GML2 outp=
yet we didn't establish a minimum throughput as a requirement, though even =
4M/s seems like not the higher possible rate, I would be glad if it scales=
well, say, serving 10 concurrent requests at 4M/s. But that's load testing,=
so I hope with the new servers we can at least have a manually ran jmeter=20
project, as long as we can make the time to work on it, of course.
On Thursday 20 December 2007 09:03:18 am Andrea Aime wrote:
> Gabriel Rold=E1n ha scritto:
> > Thanks Arne, this gives some relief, I'm still hoping it is just
> > something wrong on my side.
> I can confirm there is something wrong on my side too.
> I loaded the gshhs_land data (150MB right?) and asked to generate
> the gml2 out of it. The resonse was immediate:
> > gshhs_land.gml
> % Total % Received % Xferd Average Speed Time Time Time
> Dload Upload Total Spent Left
> 100 323M 0 323M 0 0 5379k 0 --:--:-- 0:01:01 --:--:--
> So with WFS 1.0, GML2 output all right, just slow because this
> is trunk (on 1.6.0 you can probably get something more like 10MB/s).
> The I tried GML3:
> > gshhs_land.gml
> and the result is:
> java.lang.OutOfMemoryError: Java heap space
> Ah ah, now I get it. The GML3 output defaults on lat/lon axis order, so
> we grab the coordinates and reproject them. In this case the coordinate
> array is too big to fit the 256MB memory limit I set.
> If I remove the transformation imposing a lon/lat output I get an OOM
> error too anyways... so indeed the GML3 has higher memory requirements
> or memory leaks... not sure were, I mean, with this big geometries it's
> enough to keep a few DOM elements representing features around and
> I tried with 512 too and 1024mb too, with 1024 in the end it was
> able to generate out the xml althought my PC was nearly killed by it
> (XP does not like having processes that do consume that much memory,
> it enters swap storm).
> This is some work for xml-man (aka Justin) to solve I guess. In the
> meantime we'll have to tell users to either stay away from huge
> geometries, stay away from GML3, or buy lots of memory (pick your
> poison) :)