The plan I plan to plan (with the paymaster's consent) is:
1. Achieve basic WFS 1.1, GML 3.1 capabilities required, implementing test
cases.
2. Deploy to time-sensitive testbed activity
3. Port to trunk, and debug against test cases and WMS capability
4. Hopefully update deployments to include
Chris Holmes wrote:
> Is all the community schema work still taking place on a forked module
> on 1.6.x?
Yes.
> It seems like a bunch of effort is being put into it there,
> which will then all have to be ported?
That is correct. And it sucks. We have hard deadlines that require
delivery now
Is all the community schema work still taking place on a forked module
on 1.6.x? It seems like a bunch of effort is being put into it there,
which will then all have to be ported? What readiness on trunk is being
waited for? It has the new feature model on it, and we've done an alpha
release
Oops, last email was CCed to Openlayers, should have been CCed to
[EMAIL PROTECTED] (a performance testing project being used for
WFS testing)
Cameron Shorter wrote:
> As part of our robustness testing of AWDIP deployments of Geoserver
> (which includes Community Schemas), we have signed up to d
Rob Atkinson wrote:
> 3) The database seems to be hit twice per query, which may be a
> significant overhead if the db side is slow
That was one thing I discovered when profiling the AWDIP Geoserver
yesterday. I talked with Andrea about that and he explained to me that
this is necessary to get
Chris Holmes wrote:
> Is all the community schema work still taking place on a forked module
> on 1.6.x? It seems like a bunch of effort is being put into it there,
> which will then all have to be ported? What readiness on trunk is
> being waited for? It has the new feature model on it, and
thanks Stefan, look forward to a report, which we'll put in the planning
pipeline! I;'m rather hoping for some dumb stuff to emerge, that we can fix
easily.
current performance seems adequate for data transfer use, WMS tends to be
used more interactively, so it will be useful to apply the tools e
Hi Cameron,
On 1.6.x there is the "stress" community module. It basically contains
some code which uses a freemarker template to whip up a jmeter script
which executes a bunch of random wms requests. We used it for our WMS
performance benchmarking we did last year. Once you have the jmeter
scr
WMS is not currently supported in this build., We decided to wait until the
trunk was ready and port to it rather than clone and hack the WMS module.
(AWDIP services are about data transfer, not visualisation), they need to be
judged against the requirements for this, so in fact blinding speed is
Good stuff.
Gabriel may have further insights, but here's my perspective on what might
be worth considering:
1) No serious profiling work has been done on this build, and it wouldnt
suprise me if significant gains can be made
2) Fixes should target the trunk, so we'll need to re-run the profiling
Cameron Shorter wrote:
> As part of our robustness testing of AWDIP deployments of Geoserver
> (which includes Community Schemas), we have signed up to do "White box
> testing". Ie, work out what is happening inside Geoserver for the AWDIP
> use cases.
> The end goal is to identify areas in the
As part of our robustness testing of AWDIP deployments of Geoserver
(which includes Community Schemas), we have signed up to do "White box
testing". Ie, work out what is happening inside Geoserver for the AWDIP
use cases.
The end goal is to identify areas in the code where performance can be
im
12 matches
Mail list logo
