We recently revisited rate limiting in https://phabricator.wikimedia.org/T107934, but came to similar conclusions as reached in this thread:
- Limits for weak identifiers like IPs or user agents would (at least initially) need to be high enough to render the limiting borderline useless against DDOS attacks. - Stronger authentication requirements have significant costs to users, and will require non-trivial backend work to keep things efficient on our end. I believe we should tackle this backend work in any case, but it will take some time. - In our benchmarks, most off-the-shelf rate limiting libraries use per-request network requests to a central service like Redis, which costs latency and throughput, and has some scaling challenges. There are algorithms [1] that trade some precision for performance, but we aren't aware of any open source implementations we could use. The dual of rate limiting is making each API request cheaper. We have recently made some progress towards limiting the cost of individual API requests, and are working towards making most API end points cacheable & backed by storage. Gabriel [1]: http://yahooeng.tumblr.com/post/111288877956/cloud-bouncer-distributed-rate-limiting-at-yahoo On Tue, Sep 1, 2015 at 4:54 PM, Brandon Black <[email protected]> wrote: > On Tue, Sep 1, 2015 at 10:42 PM, Platonides <[email protected]> wrote: > > Brad Jorsch (Anomie) wrote: > >> I wonder if it got lost in the move from Squid to Varnish, or something > >> along those lines. > > That's likely, given that it was enforced by squid. > > We could easily add it back in Varnish, too, but I tend to agree with > Brion's points that it's not ultimately helpful. > > I really do like the idea of moving towards smarter ratelimiting of > APIs by default, though (and have brought this up in several contexts > recently, but I'm not really aware of whatever past work we've done in > that direction). From that relatively-ignorant perspective, I tend to > envision an architecture where the front edge ratelimits API requests > (or even possibly, all requests, but we'd probably have to exclude a > lot of common spiders...) via a simple token-bucket-filter if they're > anonymous, but lets them run free if they superficially appear to have > a legitimate cookie or API access token. Then it's up to the app > layer to enforce limits for the seemingly-identifiable traffic and be > configurable to raise them for legitimate remote clients we've had > contact with, and to reject legitimate-looking tokens/logins that the > edge choses not to ratelimit which aren't actually legitimate. > > -- Brandon > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > -- Gabriel Wicke Principal Engineer, Wikimedia Foundation _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
