[OSM-talk] Node download limits / Database priority

[Dirk-Lüder Kreie]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nic Roets schrieb:
> I think
> * tiles at home,
> * other rendering,
> * editing and
> * even newbies fooling around
> all contribute to the project but unfortunely also to the load. While
> our hardware (and bandwidth ?) is stretched we should have a
> mechanizism for trading off between the different applications.
> 
> ((OT: It's a lot like global warming : Cars alone are not the problem.
> But if you add airplanes and electricity there is one. 2 solutions :
> "cap and trade" (like above) and carbon tax. ))

Well you seemed to identify the rendering of map tiles as the main
source of distrubance, while I think I remember seeing some comments by
either Nick Hill or Steve C that the biggest impact on api usability
were "nonsensical queries" like requesting several square kilometers at
once.
Secondly if the tiles at home renderers pose a problem with the current
rendering rate that can be throttled (to a certain degree) by limiting
the amount of re-rendering that can be done on any one tile in a certain
timeframe.
Of course this will not limit the possibility of people rendering their
own tiles in private.

As another solution the server could prioritize the request by user
agent string, so the different applications could be separated.

Yet another solution would be to throw money at the problem and
implement some sort of replication, with a central server for writes and
several mirrors for reads, search the archive for details, I am no
database expert, but the proposition sounded well founded.

The solution of using yet another database query to store and retrieve
the user's "participation good will ratio" to reduce database load
sounds a little counterproductive to me.

Dirk-Lüder "Deelkar" Kreie

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFzRMvFUbODdpRVDwRAoWsAKC374XlUawbad1aDXJxOwM4XdqsBwCfQyRt
91rs3KgWTRbqACyss7U8LSk=
=S163
-----END PGP SIGNATURE-----