[Tilesathome] Processing delays

[Milenko]

It would mean a little more work for the server when handing out work units, 
but couldn't the server require the client to send username and password 
when the client requests (just like it does to upload), and then like you 
said, the server could keep track of what active tileset belongs to which 
client.  When the client connects again to request another tile, the serve 
would just have to check and see if there are already x number of actice 
tiles that belong to that client.

Even a fairly high number like 10 or 20 would keep misbehaving clients from 
sucking down huge numbers of tiles.

According to the stats from yesterday there were ~130,000 requests for 
renderings and only ~56,000 of those were actually uploaded.

-Jeremy
----- Original Message ----- 
From: "Robert (Jamie) Munro" <rjmunro at arjam.net>
To: "Milenko" <milenko at king-nerd.com>
Cc: <tilesathome at openstreetmap.org>
Sent: Monday, October 22, 2007 12:39 PM
Subject: Re: [Tilesathome] Processing delays


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Milenko wrote:
>> What's the cause of the ever-increasing processing delay on the t at h
>> <mailto:t at h> server?
>>
>> As seen here:
>>
>> http://munin.openstreetmap.org/openstreetmap/dev.openstreetmap-tah_delay.html
>>
>> Seems to have started when we took the break over the weekend that the
>> new API was implemented.
>
> Clients seem to still be taking hundreds of tiles from the queue and
> never processing them. We really must make sure that taking a request
> from the queue is an authenticated procedure, and people aren't allowed
> to take more than a certain number of requests until they have finished
> the ones they already have. I'd suggest starting with about 3 active
> requests allowed at any one time, but if we can make a system that lets
> clients tell the server when they had a rendering error, one at a time
> should be fine.
>
> People who run multiple clients should be able to request higher limits
> (number of clients they run + a few spare for when rendering errors mean
> they can't complete them).
>
> Robert (Jamie) Munro
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFHHNIiz+aYVHdncI0RApIAAKDmtiqJd8UMtxYpP+UNNENMclbiQQCeMOr/
> KFgvxLjNQDoNHnpKaQDCuZc=
> =EwdK
> -----END PGP SIGNATURE-----
>