On Sat, Sep 12, 2009 at 11:58 PM, Clint Webb <[email protected]> wrote: > On Sat, Sep 12, 2009 at 4:18 PM, Dean Michael Berris > <[email protected]> wrote: >> >> * If you just wanted to track the amount of things done in a given >> period since the first occurrence of an event, then the expiration set >> on the first event should suffice. >> * If you want to limit the cumulative occurrence of things within >> certain time periods, then you need to be able to extend the >> expiration. > > Actually both of those points sound like the same situation to me. How are > you defining "certain time periods", when you are extending that time > period? How does the time period have value when it is not definable? >
Nope, they have a subtle difference. Let's say you only want a user to be able to do only 10 things within 10 seconds from the first time they do that thing, then you are the first case where you just set the expiration the first time they do something (set the key to value "1") and you don't need to do the extension of the expiration of the key. When you for instance want to let people try to log in for only 3 times within 10 minutes of the first failure. Then let's say you want to be able to let users only do 10 things within 10 seconds _from the last time they did that thing_ or in other words, 10 consecutive occurrences within 10 seconds of each other, then you are the second case. For instance you only allow users to post 10 posts within 10 seconds of each other -- and lock them out if they're trying to do one more. >> >> This means sure, if you just want to make sure users can only do 10 >> things in 5 seconds, then you track from the first occurrence of that >> "thing they did" and let the 5 seconds expire. > > Go back to the design of your system. In this scenario, how does an expiry > help you. Either use it because you dont want the information anymore after > a certain known time, or dont use an expiry. If you use an expiry, it > should be because you NEED it to expire for your design to work. > Correct? > Yes, I need it to expire because it gives me an indication that the time is up for that tracking duration -- I don't need to keep the information of how many it did before or if the key ever existed. >> >> If you however want to say "just do 10 things within 5 seconds of each >> occurrence" then you can't just track from the first occurrence. This >> is the kind of behavior I would like to be able to track -- for >> example, track each user and flag those that do 10 things within 2 >> second of each occurence. >> > > I don't understand "10 things within 5 seconds of each occurrence". I'm > assuming that the initial set of the key, would have a 5 second expiry. You > wont ever know if those 5 seconds is up, because the key expires silently. Yes. > If you go to incr the key, you would not really know if the key expired, or > never existed to begin with. That assumption needs to be part of your > design. It is. > Are you incrementing and then checking the value to see if it is > greater than 10, and if so, doing something? Are you wanting to change > the expiry to 5 seconds after each incr? > Yes, if the value is greater than 10 then I can do something -- but I need to reset the expiry to 5 seconds after each incr. > So by the time it reaches a value of 10, anywhere from 0 to 50 seconds could > have transpired, but you dont care about that as long as there is no gap > larger than 5 seconds between each action? I dont understand the usefulnes > of that. > It may not be useful to you, but somehow in the application I'm working on it is useful. Let me give you a scenario: In the realm of what's "humanly possible" you can usually only do some actions within 1 second of each action -- that's granted that you don't move really quickly or do something deliberately fast, like multiple clicks on a link or multiple presses of a key. In the cases that you do break that "1 thing within 1 second of each action" you're stepping into unnatural behavior -- either that of you've written a bot that would do it for you. From the back-end side of a system that would ensure there's no abuse being done by any particular user to "game" the system, you'd enforce a cumulative count on the number of times an occurrence occurred relative to each occurrence. This is where you'd want to make sure "at most 3 things happen within 2 seconds of each occurrence" or something like "at most 2 things happen within 1 second of each occurrence". This is the situation where it does matter that you're able to move the expiration after every increment. > So I am therefore assuming that you either care about 10 things in a 5 > second period, or 10 things in a 50 second period. Neither situation > requires the ability to update the expiry of a key. > Not 10 things in a 50 second period -- I want to track the acceleration, not enforce an average velocity. 10 things in a 50 second period doesn't mean not allowing 10 things to happen within 5 seconds of each occurrence. So a valid use case in my system is: do 9 things within 5 seconds, wait 6 seconds and do another 9 things. This isn't allowed in the 10 things in 50 seconds situation you're proposing. I'm enforcing a maximum acceleration, while you're enforcing an average velocity. > So if we break this down further, you dont care about the 5 to 50 second > range, you care about the 0 to 5 second range. If you hit a count of 10 > within that first 5 seconds, then you want to know about it. So how does > updating the expiry help you here? > Nope, you got it wrong -- what matters to me is how close in between the 10 things are to each other, making sure that all 10 happen within 5 seconds of each other, not that all 10 things happen within 50 seconds. > The only reason I can think of to use this kind of thing is for throttling. > If you reset the expiry to 5 seconds after each incr, then you give the > users an unpredictable result. When users find something unpredictable, > they assume it is broken. Bad Karma. > Unless you're building it into a system which is intended to track abusive behavior and tracking usage that is not within the realm of what's humanly possible. > >> >> I hope this makes sense and it may be a valid need for not only me but >> others using memcached. > > I understand the technical feature you are requesting (ability to update an > expiry of a key when using an incr/decr), but I cant find a practical use > for it. > I hope my explanation expands your horizons. ;) > But on a side note, you can always update the expiry yourself by performing > a seperate set (using CAS you could even ensure you dont lose any counts in > the middle of it), but its probably not as optimal as you would like. > Yup, not as optimal as I'd like. ;) -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/mikhailberis linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com
