[asterisk-dev] scalability issue with realtime lastms update on qualify state change

[Jaco Kroon]

Hi,

On 16/11/2013 10:02, Olle E. Johansson wrote:
>
> 16 nov 2013 kl. 00:57 skrev Damon Estep <damon at soho-systems.com
> <mailto:damon at soho-systems.com>>:
>
>> I typically have 250 concurrent channels active per server.
>>  
>> RTP is not handled in the sip channel, but qualify and the realtime
>> database updates for SIP peers are.
>>  
>> High RTP load won't affect SIP scheduling. High SIP load will.
>>  
>> Apples and Oranges.
> Yes, there's one single thread in chan_sip handling all the Qualify
> and inbound sip messages. If we moved the database updates to a
> background thread the situation would improve. Then the monitor thread
> would just move on to the next message, letting another thread wait
> for the database.
Would this include updates to the astdb?  The only case of this I see is
with updates to astdb (not using realtime myself on the particular
cluster where I bumped into this) on REGISTER requests.  Since I don't
use astdb for anything other than the sip and iax2 registry for storing
registration data for reloads/restarts I opted to just put it on a tmpfs
and the problem went away.  Quite possibly that won't help the op here
(external DB?) but in case anybody else has a high frequency of inbound
SIP REGISTER requests, or don't care about losing the astdb on server
crash/reboot (not asterisk restart):

http://jkroon.blogs.uls.co.za/it/voip/asterisk-massively-speeding-up-those-register-requests

JK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20131123/f4c2093f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jaco.vcf
Type: text/x-vcard
Size: 231 bytes
Desc: not available
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20131123/f4c2093f/attachment-0001.vcf>