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? > 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? > 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. 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. 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? 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. 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. 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? 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. > 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. 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. -- "Be excellent to each other"
