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
Sounds like a good idea.
regards Klaus
On 29.03.2012 23:05, Peter Dunkley wrote:
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
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:
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
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:
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-
Anca Vamanu -
Daniel-Constantin Mierla -
Klaus Darilion -
Peter Dunkley