30 Mar
2012
30 Mar
'12
5:16 a.m.
Hello,
one more thing that can be added to increase performances is using own
timer process or a pool of timer processes -- in this way there is no
interference with other modules using the generic timer.
There are two functions fork_basic_timer() and fork_basic_utimer() that
can be used -- rtimer is a good example to look at for doing it.
These kind of timers don't sync back the interval -- i mean if a
function executed on timer takes too long, the process should sleep less
or at all to catch up, but this is easy to add if people think is important.
Cheers,
Daniel
On 3/30/12 10:05 AM, Anca Vamanu wrote:
Hi Peter,
A very nice approach. Still waiting waitn_timer for each Subscription
dialog but distributing the work through the whole interval. Sounds
good to me also.
Regards,
Anca
On 03/30/2012 12:05 AM, Peter Dunkley wrote:
--
Daniel-Constantin Mierla
Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany
http://www.asipto.com/index.php/kamailio-advanced-training/
Hello,
When under load RLS performs in a "lumpy" manner. I believe this is (at
least in part) because of the waitn_timer for sending NOTIFY requests.
This timer is needed because, as the RFCs point out, it is important to
buffer up RLS NOTIFY requests so as not to flood the network and client.
However, I was wondering if a small change might help smooth out the
lumps.
What I was thinking of is:
- Change the updated flag to be a number between 1 and the value of
waitn_time (0 means no update)
- Set the flag number based to the core_hash(did, NULL, waitn_time-1)+1
when the rls_presentity record is updated/inserted
- Have RLS NOTIFY requests sent each second. After the first second
records with the updated flag of value 1 are sent. After the second
second records with the updated flag of value 2 are sent. Wrapping back
to 1 after waitn_time seconds.
This should help smooth out the sending of NOTIFY requests from RLS
while
still making sure they are buffered and take at most waitn_time
seconds to
come out.
Can anybody see any reason why this won't work?
Would there be any objections to me making this change?
Regards,
Peter
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev