[asterisk-dev] Realtime and call states in SIP

[Bryan Laird]

On May 30, 2007, at 5:12 AM, Olle E Johansson wrote:

>
> 30 maj 2007 kl. 09.42 skrev Loic Didelot:
>
>> Hello,
>> I know that you mentioned 500 just as a number but I think 500 is far
>> too low. Not sure if I understand everything right but my guess is  
>> that
>> one realtime buddy will take 0.4 kb maximum. So if I would like to  
>> only
>> use 256 MB of memory for the caching I could cache more than 500.000
>> buddies. I think if the aim is to reduce the load from the  
>> database it
>> should be able to cope with a big list. If you redesign the whole
>> realtime implementation, then you should think big.
>>
> Absolutely, I was just adding a number.  You also have to consider  
> that you
> can't have 500.000 simultaneous calls and you don't want to have peers
> in memory for too long, then you loose the synch with the database  
> and you
> can switch to static anyway and issue a reload whenever you want to  
> refresh
> in-memory copies.
>
> For chan_sip3 I'm trying to design a way to have all the devices in  
> memory
> and use manager commands to force resynch of individual devices or
> groups of them. We won't keep all data in memory, but enough so we  
> know
> if we have a peer and how to communicate and authenticate with it.  
> After
> auth, we can load the rest and keep it in memory for the  
> transaction processing,
> then release that part.
>


Forgive my arrogance and interruption but I'm curious.  Why is it  
important to cache
the authentication data again?  I can understand it if you are  
working with a massively
under-powered data repository or for some insane reason you have  
asterisk box in CA talking
to a single database in VA that you would want to do this.  However  
in my experience dealing
provisioning esq systems once you start 'caching' queries things  
become bloated and you
end up with a situation that inevitably causes problems for  
*someone*.  Now I admit I don't know
many databases other than MySql, but I've run sql for provisioning  
db's for a number of years and
routinely manage auth connections upwards of 30 per second to even a  
few hundred in a pinch.

I guess my question is, is there any reason to not simply cache the  
data for say 300 seconds and have a thread
that dumps the data > 5 minutes old.  Then when no data is found in  
the cache you reach out to the
db.   This keeps a standard cache running for all entries but would  
likely protect the db from broken clients
that perhaps just re-register constantly.  You should limit the need  
to ever have to "reload" or interact with
the CLI to refresh user data, baring some 'major' event.   
Understanding that it wouldn't be a 'flat' query rate but
at 10000 units you would probably level off to 33 dips to the db per  
second as a normal run-rate.  But again
going back to 600 seconds you can drop that in half.  This being  
something that the 'user' could determin based
on their enviroment.  Where I think 5 minutes isn't a massive delay  
for change to an account / user ofcourse there
will always be the request to "I made this change now I don't want to  
wait".  Either way It's an efficient method
where if someone was attempting to use asterisk for a "VERY VERY  
LARGE" system well thought out specs for
the provisioning system would suffice  (something like reasonable CPU  
and even solid state drives with high rate
of read i/o's per second)

Anyway just wanted to throw in my nickels worth.





>> Many sip devices have a short expiration time (+- 1 minute) to  
>> cope with
>> nat issues. I think it would not be a good idea to free them after
>> expiration and reload them form DB immediately again. Maybe we  
>> should be
>> able to set a configuration variable to define how long a buddy will
>> stay in cache after expiration: keepincacheafterexpiration=600
>
> Well, I think that's a broken model. Why not use NAT keepalives  
> from the device
> or from Asterisk, something that doesn't mean that you have to  
> authenticate? With a 1 minute
> expiration you will get a lot of auth messages and put un-needed  
> burden on
> your CPU.
>
>> Excuse me if I should be completely off topic.
> Not at all, not at all. This is the kind of feedback I was looking  
> for. I need all kinds
> of input, regardless of what I think ;-) in order to create a  
> useful solution.
>
> /O
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Bryan Laird,