Nigel Kukard wrote: > > Eg, suppose you set a rate of 10 messages per 60 seconds, and you >> sent 1 message every 6 seconds. After the first message, the counter >> will be 1, after another 6 seconds, the counter will be 1 - ( 1 * >> 6/60 ) + !, which is previous counter less 6/60ths of it's previous >> rate because we've gone 6s since the last message, plus 1 for the new >> message. So we now have 1.9, not 2. >> >> After the next message, the rate will be 1.9 - ( 1.9 * 6/60 ) +1, >> which is 2.71 and not 3. >> >> And so it goes on. >> >> In your case, you've sent those messages over a period of 3 1/2 >> minutes, so your counter has been reduced somewhat as a result. The >> x/y reported is obviously a rounding of the floating point value (as >> you can see where it doesn't change from 5/8 to 5/8 for the 5th and >> 6th messages. Then for the 7th message, there is a significant gap in >> time and so you can see the counter has reduced somewhat. >> >> >> Hope this helps. > >Awesome response Simon :) I'm thinking a little FAQ on the site may be >a good idea, or even adding the above to the quota docs page.
Feel free to copy/adapt as you wish - I've added a bit more that you can use, or not, as you wish. Not having looked at the code, I assume the actual calculation is Cm = Cn * (1 - t/T), and add 1 if the message is passed. where: Cm=new value of counter Cn is previous value t is time since last message was passed T is time period specified for the quota. With the condition that if t>T then Cm=1 since you don't want the counter going negative and storing up credit. Or If t>T then Cm=0 else Cm = Cn * (1 - t/T) If Cm > Q then block message; Cn=Cm else pass message; Cn=Cm +1 where Q is the message count specified in the quota. Which sort of leads on to the question of what T should be - and not something I'd considered greatly before now. This may also be of use to people struggling to get their heads round what limits to set. If someone tries to send large volumes of messages continuously, then having a rate of (say) 60/minute would have the same effect as 3600/hour in the long term. In the steady state, both would allow one message per second. One would settle at : 60 * (1 - 1/60) +1 = 60 the other would settle at : 3600 * (1 - 1/3600) +1 = 3600 The difference would be when the user wants to send a batch of messages out when they have not sent much (or any) for a while. In effect, T controls the burst capability. Lets say the client and server can process very large volumes indeed (so we can ignore limits imposed by the ability of the server to handle the messages etc), then with a value of 60 for T, messages would get blocked after sending 61 within a second and after that would be throttled to 1/second. Whilst with a value of 3600, the user could spit out 3601 in the first second before being throttled down to 1/second. Of course, they aren't likely to spit out that many in that short a time, but the principal holds - the larger the value of T for a given limit expressed in messages/second, the larger the number of messages that can be sent in a burst. For someone sending (say) 1800 messages, a limit of 60 per 60 seconds would throttle them down so the messages take nearly half an hour to send, while a rate of 3600 per 3600 seconds would allow them all to be sent as fast as the client and server can process them. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. _______________________________________________ Users mailing list [email protected] http://lists.policyd.org/mailman/listinfo/users
