[Openstreetmap] Re: Server Performance

[Christian van den Bosch]

Raphaël Jacquot wrote:

> 800x600 is obsolete. the pane size should be 768*512

"Obsolete" is a bit strong, particularly given that we're talking about 
users of the viewer as well as the editor. Maybe it would be best to use 
javascript to set the pane size to fit in the current browser window, 
with a sensible maximum like 768x512?

>> Would it be feasible for the server to combine requests

> that would make the javascript more complicated.

Not really! The javascript (client) knows what tiles it will request, 
and telling the server this should be trivial - the server side would 
become rather more complex though, yes.

> perhaps, asking for the tiles in a spiralling fashion as google maps do 
> it may be simpler

I like this idea; it should make the user experience seem faster, with 
no server side changes. However, it will still fetch the same tiles, 
just in a different order, so server load will be unaffected. What I'm 
mainly focussing on, in this thread, is reducing server load (with a 
tangent about rendering bugs).

> it would reduce the effectiveness of the browser's caching mecanism

It shouldn't affect the browser's caching mechanism at all; I did 
specify that the client still receives the same tiles as before, but 
gives the server slightly more information first, so it can generate 
uncached tiles in one operation instead of (some number up to) 20, and 
then serve them to the client from the newly-generated cache.

Often, we will find that the server has recently generated some chunk of 
the requested tiles already; in this case we can treat a row or column 
on its own as a supertile, or generate individual tiles if that seems 
most efficient, or even speculatively generate more tiles in the 
unexplored direction to anticipate the next request.

I would try to code this, but I'm up to my eyes in other projects for 
the next few months.

> better yet, select all lines,

Do you really mean all lines in the database? Surely, eliminating nearly 
all lines we don't want, while guaranteeing we get all the ones we do 
want, has to be better than that?

 > and do the calculations in the script prior to drawing the lines

No harm, but...

> of course, the better solution would be to contribute geometry culling 
> to cairo

...the line drawer itself, if at all well implemented, should be able to 
return very quickly when there's nothing to be done for the given line 
in the given tile / super-tile. To do a yes/no calculation for each line 
before calling the line drawer may even be duplication of effort, given 
that the line drawer will perform an almost identical calculation in 
order to figure out where to draw the line.

Christian / cjb

http://www.cjb.ie/