[Freeswitch-users] mod_limit and memcache

[Rupa Schomaker]

Ok, it was a bit more work than expected, but I have a first cut at
mod_limit using memcache checked in.  Test if you can.  I've not put
docs on the wiki 'cause some of the implementation / setup details are
going to change with regards to mod_memcache.   Oh, and mod_limit's
api may be changing to make it more pluggable.

Basically,

Setup mod_memcache (on wiki)

It uses the same user facing api as limit_hash and friends except it
is limit_memcache and limit_memcache_usage.  so follow mod_limit's
docs with suitable substitutions.


On Thu, Aug 27, 2009 at 9:42 AM, Rupa Schomaker<rupa at rupa.com> wrote:
> limit and memcache haven't been introduced to each other yet -- it is
> on my (semi-long) list of things to do.
>
> If you want it you can:
>
> 1) do it yourself and submit the patches
> 2) open a jira and hope someone does it
> 3) open a jira + bounty and someone will probably do it
>
> It will get done eventually, just hasn't been a itch for ME to scratch yet.
>
>
> To do it:
>
> 1) I need to make it possible to call inc/dec methods of mod_memcache
> to support an expiration time.
>
> 2) mod_limit.c - use the hash limit as a guide
>
> Initial pitfalls:
>
> hash limits concurrent access/modification of the hash and by
> implication limit_hash_item_t (hash data) by using a mutex.  We can't
> mutex across FS instances.
>
> So perhaps split up limit_has_item_t and spread it across multiple
> keys.  So instead of one key marked as realm_id, we could have
> realm_id_total_usage realm_id_rate_usage and realm_id_last_check.
>
> This does mean that rate_usage and total_usage can inc/dec independent
> of each other, but I think the logic will still be "ok" *IF* we
> remember to decrement earlier incremented items in the event a later
> item is failed.   (so, say we increment rate but fail on total we need
> to remember to decrement rate so that we have no net effect on the
> counters)
>
> Alternatively, we could use CAS support and pull the limit_hash_item_t
> item from memcache, twiddle it and then try to put it back only if the
> check info is the same (no one else has changed the entry).  If the
> entry has changed, pull the new version, do the limit logic, and try
> again.  Loop that a few times until you succeed or give up.  Problem
> is that CAS needs to be explicitly turned on in memcache (some distros
> compile with it off), is relatively new in memcache (hint: may have
> issues) and has some performance/memory downsides though by how much
> I'm not sure.
>
> Thoughts?
>
> On Thu, Aug 27, 2009 at 8:49 AM, Woody Dickson<woodydickson at gmail.com> wrote:
>> Hello,
>>
>> I read something that talks about using memcache for mod_limit before.   Is
>> it something that is available now?
>>
>> If I have multiple instances of freeswitch that need to share the same limit
>> status, it there any existing solution?
>>
>> If no existing solution is available, what is the best way to go about
>> modifying mod_limit to accomplish limiting for multiple freeswitch servers
>> together?
>>
>> Thanks,
>> Woody
>> _______________________________________________
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>>
>>
>
>
>
> --
> -Rupa
>



-- 
-Rupa