FW: [Openstreetmap] Server Performance

Etienne Cherdlu openstreetmap-L at gj0.net
Tue Dec 20 08:59:00 GMT 2005


Steve
Is there anything I can do  to help?

As  Andy Robinson said, last night at 23:30 it was taking 3 minutes to pan
the map in edit mode.  Oddly, viewing the map seemed didn't seem to be any
slower than normal, it was just edit mode where it was slow.

I think there must have been an exceptional event last night to make it so
bad.  However, it is still pretty slow at the best of times and the way the
applet behaves when the server is slow is not at all user friendly.

>... the applet will
>remove a segment if it didn't get created instead of just leaving it there
>so you can tell if it was successful or what.

Isn't that what it doing already and isn't that the problem?  If *I* have
added a segment then nothing that isn't human should contradict this.  If
the server fails to add the segment (and it should be trying harder) then
the applet should simply try again.  When I add a segment I am not saying
"add this segment if you can", I am saying to the applet: "add this segment,
come hell or high water, and don't give up".

Given that there is a possibility that the segment might never get added, it
would make sense to add the segment using a grey line and only change it to
white when the server responds with a 200.  That way the user would know
what has stuck and what is still pending.  Making the user have to add the
segment two or three or even four times is not a friendly solution.

If there is anything I can do to help please ask, I'd like to see a quick
solution to some of these issues and I'm more than happy to help out a bit.

Etienne




-----Original Message-----
> From: SteveC [mailto:steve at asklater.com]
> Sent: 20 December 2005 03:47
> To: Etienne Cherdlu; Johnny Doe
> Cc: openstreetmap at vr.ucl.ac.uk
> Subject: Re: [Openstreetmap] Server Performance
>
> * @ 19/12/05 11:05:41 PM openstreetmap-L at gj0.net wrote:
> > I just added a whole lot of segments for a complex motorway
> > interchange using the java applet.  This required a lot of painstaking
> > and detailed work.  I then panned the view area and was dismayed to
> > find that not only
>
> I would be more than dismayed.
>
> I've synced the code used to generate the dev server with the live
> machine.
> I've added a bunch of code to do logging server side, and the applet will
> remove a segment if it didn't get created instead of just leaving it there
> so you can tell if it was successful or what.
>
> Hopefully logging will show up what is going wrong, because I havn't been
> able to reproduce it. What time (GMT) should I try to see when it's slow?
> Please mail me your problems, including java console output. I
> *am* looking at it.
>
> > What is it that is making the server slow anyway?  I've never seen
> > more than about 4 people editing at any one time, and I'm sure there
> > can't be than many people viewing the maps yet.  Is there some batch
> > process that kicks in to rebuild tiles or something?
>
> No, that's on the tile server. It might be something on the database
> server... or a backup script. Anything to figure out the timing of these
> problems is helpful.
>
> > This problem really needs addressing as an absolute priority.  The
> > most
>
> It is being dealt with, I know it sucks, I will fix it as soon as I figure
> out what's going on.
>
> * @ 19/12/05 11:56:59 PM uucp1 at yahoo.com wrote:
> >
> >  I had a similar painful experience, and IMHO the main problem  is the
> > download of tiles into the applet, which can't be  switched off.
> >  The http://brainoff.com/osm/change is so much  better, because of the
> > direct tile download.
> >  Unfortunately there is
> >  no comparable 'applet' functionality in the osmeditor :(
>
> It is something that's also a high priority...
>
> have fun,
>
> SteveC steve at asklater.com http://www.asklater.com/steve/
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20051220/621dc30a/attachment.html>


More information about the talk mailing list