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