Hi Chris,
cc'ing the list for you, though hidding your other email address.
truth is, it is very possible the perf slowdown is due to the changes in the
geotools arcsde plugin. That is because during development I didn't have
access to an SDE instance with enough bandwidth as to notice it (ever thought
the slowness came with the ADSL connection).
But we introduced a good bit of locking in the plugin, to cope up with the
fact SeConnections are not thread safe, nor its possible locking strategies
fit our API/workflow, so its not that a surprise there are perf slowdowns I
didn't notice, and yeah, the numbers you're talking about are scary.
On the bright side, Jody is starting up to implement a plan to alleviate that
locking maddness we designed a couple weeks back but I didn't have the time
to implement myself, though I will be following the development closely.
About the improvements, I feel like I wrote about them too many times being so
stupid that did it only on email and not at the wiki. So here we go, so
the "Fetures" section at
<http://docs.codehaus.org/display/GEOTDOC/ArcSDE+DataStore>
So if this is not a huge blocker for you, I'd recommend waiting for a couple
weeks so we can release the transaction queue work being started by Jody,
since spotting the performance problem right now sort of makes non sense
since the most probable candidate for that problem is going to be reworked.
Cheers,
Gabriel
On Tuesday 15 April 2008 02:51:57 am Chris Tweedie wrote:
Gabriel/Oscar, in any other case I would agree re: grid sizes however the
tables we are using 1.6.x on are identical to our current performance using
1.4.xDeavi noted the performance drop based purely on the Geoserver upgrade. I
would not worry too much at this stage, it could be our environment, but
are you able to comment on the SDE improvements that Andrea alluded to? I
could not find any reference in GT or GS about any major SDE modifications
and it worries me if they "snuck" inThanks
Ps. Not CC'd to list as email will bounce using this account
---------------------------------------------------
Chris Tweedie
Senior Geospatial Specialist - Business Programs
Information Access
Landgate
(08) 9273 7520
www.landgate.wa.gov.au
--------------------------------------------------------Original Message-----
From: Gabriel Roldán [mailto:groldan@anonymised.com]
Sent: Tuesday, 15 April 2008 3:46 AM
To: Oscar Fonts
Cc: Deavi Purnomo; Chris Tweedie; geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] unpredictable ArcSDE behaviourHey Oscar,
sure, that may well be the root of the problem.
I'm a bit hands tied right now as I don't have a server reachable server
with enough bandwidth as to assess performance (ie, the low bandwidth is
too much a bottleneck).Deavi could you follow Oscar's advise and report back your findings?
Cheers,
Gabriel
On Monday 14 April 2008 08:08:09 pm Oscar Fonts wrote:
> Hi,
>
> Try rebuilding the spatial index, even if loading in other applications
> is fast [1].
>
> <verbose>
> I also had a speed problem rendering an SDE8.3/Oracle9.2 layer with
> GeoServer 1.6.0RC3.
> Retrieving a small amount of features (say 20) took over 30 seconds
> (Gabriel, remember talking about this at Girona?).
> The featureclass could be loaded quite fast in ArcMap, etc.
>
> Playing with spatial grid sizes, I replaced the 1000 default with 3
> levels (100, 1000 and 10000) and rebuilt the spatial index.
> Now I get the same render 300x faster (< 100 ms for a 256px tile).
> Not shure if changing grid size is necessary, or just re-creating the
> index is enough.
> Anyway, setting an optimal grid size is a good practice.
>
> Hope this helps.
> </verbose>
>
> [1]
> http://webhelp.esri.com/arcgisdesktop/9.2/index.cfm?TopicName=Setting_spa
>ti al_indexes
>
> Regards,
>
> Oscar.
>
> ------------------------------
>
> > *From:* Deavi Purnomo
> > *Sent:* Sun 13/04/2008 11:53 AM
> > *To:* 'Gabriel Roldán'
> > *Cc:* Andrea Aime; geoserver-users@lists.sourceforge.net; Chris Tweedie
> > *Subject:* RE: [Geoserver-users] unpredictable ArcSDE behaviour
> >
> > HI Gabriel,
> >
> > Thank you for your reply.
> >
> > I just tried the nightly build for the arcsde plugin (12 Apr 2008) and
> > now I am able to create a new ArcSde layer based on a view.
> >
> > Regarding the timing:
> > We have another version of geoserver (I am not sure what version, I
> > will find out from Chris T and get back to you on that). When I call
> > the layer on this version (using the same method and the layer itself
> > is from the same arcSDE view/table), it took only less than one second
> > (I cannot get the exact time sample).
> >
> > I have also tried to change the global maximum number feature (maximum
> > feature =2000 or 10000000) to see it there is a difference but there
> > seems to be no correlation in that. In both of the cases, I still get
> > the same amount of time to pull 100 features (PS: the 100 features is
> > the initial setting provided by GAIA)
> >
> > Maximum Feature = 2000
> > Result:
> > 13 Apr 12:07:45 INFO [geoserver.filters] - "POST
> > /geoserver163_sde080412/wfs" took 35859ms
> >
> > Maximum Feature = 1000000
> > Result:
> > 13 Apr 12:09:48 INFO [geoserver.filters] - "POST
> > /geoserver163_sde080412/wfs" took 35958msThis e-mail and any files transmitted with it are intended only for the use
of the addressee(s). It may contain information that is confidential and
privileged, in which case neither is intended to be waived or lost by
mistaken delivery to you. If you are not an intended recipient, any use,
interference with, disclosure, distribution or copying of this material is
unauthorised and prohibited. If you receive this e-mail in error, please
notify the sender by return e-mail and delete the message and any
attachments from your system. Unless specifically indicated, this e-mail
does not constitute formal advice or commitment by the sender or the
Western Australian Land Information Authority (Landgate). Information in
this message not relating to the official business of Landgate shall be
understood as neither given nor endorsed by it. It is your responsibility
to check any attachments for viruses and defects before opening or sending
them on. Landgate’s liability is limited to re-supplying affected
attachments.!DSPAM:4045,4803fc3749228992556831!
