Hi Dk/Eric/Leif, Thanks for the advice. Our use-case simply requires sending out the queued requests at a fixed rate (although variable by site). My plan was simply put all incoming transactions in separate queues by site, and then invoke "transaction.resume()" at fixed interval via a timer for each queue. Would the delay (calling "transaction.resume()" asynchronously) disrupt the ATS event processing? If yes, what's correct way to avoid that? If no, is there any example plugin implementing such a timer (was thinking about AsyncTimer in atscppapi)?
The TokenBucket is a very interesting data structure, but I've not figured out how to apply it yet. Will look into it a bit more. Thanks to Eric's point, TS_HTTP_SEND_REQUEST_HDR_HOOK will indeed be too late. But for this use-case the "rate-limit" only applies to cache-misses and revalidations (fresh cache-hits should be served as fast as possible). Therefore the hook probably should be TS_HTTP_CACHE_LOOKUP_COMPLETE_HOOK. The plugin then lets the transaction resume immediately if the cache hit is fresh, or queue the transaction otherwise. Still learning ATS, let me know if I'm wrong. Thanks! From: dev@trafficserver.apache.org At: 06/21/19 23:11:03To: Weixi Li (BLOOMBERG/ PRINCETON ) , dev@trafficserver.apache.org Subject: Re: Implementing Rate-limiting in forward proxy mode Uhm! why async timers? You'd want to implement a leaky/token bucket per site. Check out... https://github.com/rigtorp/TokenBucket It's single header file lock free implementation for token bucket and it works very well... On Fri, Jun 21, 2019 at 7:38 PM Weixi Li (BLOOMBERG/ PRINCETON) < wli...@bloomberg.net> wrote: > What a great community! So many good tips in such a short time! > > Especially the atscppai, I would've never noticed it. the async examples > look very promising. > > It looks like the following might be necessary (let me know if I'm wrong): > * A hook to TS_HTTP_SEND_REQUEST_HDR_HOOK > * A map of queues (one queue per rate-limited site) > * A map of async timers (one timer per queue) > > I will study the ATS code more to understand the event and threading model > better. > > Thank you all. > > From: dev@trafficserver.apache.org At: 06/21/19 19:52:44To: > dev@trafficserver.apache.org > Subject: Re: Implementing Rate-limiting in forward proxy mode > > I have implemented rate-limit in my plugin using atscppapi. We are using > ats in > security context for mitigation. If the request matches certain criteria > (ip, > method, host, uri and header values) then we apply rate-limit to that ip. > > Dk. > > > On Jun 21, 2019, at 3:15 PM, Leif Hedstrom <zw...@apache.org> wrote: > > > > > > > >> On Jun 21, 2019, at 16:09, Weixi Li (BLOOMBERG/ PRINCETON) > <wli...@bloomberg.net> wrote: > >> > >> Hi team, > >> > >> We are experimenting with ATS in *forward* proxy mode. Our use-case > requires > a rate-limiting component that enforces rules based on the destination. > >> > >> For example: > >> > >> For all incoming requests targeting "www.cnn.com", we want to limit > the > outgoing rate to be 10 requests per minute; for "www.reddit.com", we want > the > rate to be 20 requests per minute; and so on. If there were more requests > than > the limit specified, the requests must be queued before they could go out. > > > > Seems very straight forward to implement as a plugin. For example the > geo_acl > plugin might be a good start, since it limits access based on source IP. > > > > Would be interesting to hear more about your use case too, it’s always > exciting to hear about different solutions that people use ATS for. Maybe > at > the next ATS summit? :-) > > > > Cheers, > > > > — Leif > >> > >> Is it possible to implement this requirement using a plugin? > >> > >> If not, we wouldn't mind forking the code and modifying whichever parts > that > would be necessary. But which are the potentially relevant components? > >> > >> If any experts could give us some pointers on the design, that would be > really appreciated. > >> > >> Thanks, > >> Weixi > > > > >
