[Tilesathome] Rate Limiting & be gentle with you requests

[80n]

On 8/10/07, Robert (Jamie) Munro <rjmunro at arjam.net> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> spaetz wrote:
> > Hi all,
> > up to yesterday we would accept all requests and hand them out to as
> many
> > renderer clients as were willing to take up jobs. As the 2500 concurrent
> > render jobs were too much for the API server TomH had to restrict access
> > from renderer clients yesterday in order to keep the API server alive.
> > So changes are needed!
>
> > I implemented a simple rate limiting, which basically only hands up to
> > 500 active jobs out at the same time. While that number might need
> > tweaking, it seems to work reasonably well (although the API seems
> > still too slow, we currently have very little uploads).
>
> It's not the number of active jobs that's important. It's the number
> that are in the "requesting data from the API" stage of the process. If
> 500 jobs are rendering blank areas, they are not going to take very long
> before they complete and come back (say 30 seconds), so the API server
> will get 1000 hits / minute. If they are rendering complicated areas, it
> may take 10 minutes to render, so the server will only get 50 hits /
> minute. We also may want to take into account how much effort the API
> takes for a request - We can give the API more requests if they don't
> place much strain on it.
>
> I think we need to concentrate on directly making sure that T at H clients
> don't overload the API.
>
> When T at H clients request data from the API, they need to request it
> low-priority. The API should be able to not give it to them if it is a
> bit busy.
>
> Due to the APIs inefficient use of memory (building the whole request as
> a DOM before sending any of it rather than streaming the results as they
> are created), it may be better to make 4 zoom level 13 requests than 1
> zoom level 12 request - especially as that level 12 request already
> fails sometimes, and the code is already implemented to stitch multiple
> smaller requests together.
>
> Another thing that would help is if the server didn't send complete
> ways, only complete segments when serving to a T at H client. JOSM likes
> complete ways, but T at H doesn't need them, and they impose a huge
> processing overhead on the server. A toggle could be added to the API to
> switch this feature off.


T at H does need complete ways.



> On the other hand, making requests is not limited at all. Yesterday
> > LosHawlos requested at least 2.5k tilesets and over night within a
> > couple of hours somebody fired off >2.5k requests with a bulk
> > rerendering of the whole of norway, leading to around 5000 bulk
> > requests within 24 hours.
> [snip]
> > What do people think? Should we limit request making and in which ways
> > would you think it should be done?
>
> Requests go into a queue, and can stay there. There's no point in
> limiting them entering the queue. It might be worth giving certain
> requests in the queue a higher priority, but if you try to rate limit
> the incoming queue, I'll just have to make a local queueing system and
> have a daemon put my requests on the real queue at a slower rate, which
> is just a waste of everyone's time.
>
> Robert (Jamie) Munro
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFGvErsz+aYVHdncI0RAqm0AKCRrGhhsHc32s4VG3eNXIRn9mka0wCfQ5r0
> BQAwdnW+GyECu6a8khGiYIE=
> =pOow
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Tilesathome mailing list
> Tilesathome at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/tilesathome
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tilesathome/attachments/20070810/0805189c/attachment.html>