How did lowering pull-time from 2 seconds to 1 second helped it? ???
Pulse time works by checking the list of available agents every X seconds on the second based on when the URS was started.
Therefore if I have 2 URS and each check its list of available agents every 2 seconds, then its possilbe that URS 1 will check the list at 11:03:35 seconds and URS 2 checks at 11:03:37
Therefore URS 1 will always get to the agents first…
If its set to 1 seconds, the both URS will check the list at 11:03:35, 11:03:36, etc – and Reserve agent will work fine
I thought they fixed that problem in 7.5 where pulls are perfectly synchronized between multiple URS.
I am not very keen on reducing pull time to 1 second because I assume a very high increase in load on URS during the rush hours. Do you have some numbers on change in load when using 2 seconds and 1 seconds pulltime respectively?
Best regards,
Vic
Unfortunately our capacity planning was not that advanced at the time we made the change from 2 sec to 1 sec so we don’t have any data on the change. As I recall it was still a non-event.
The only item that has seemed to impact our URS seems to have been call volume. In fact we’ve recently changed over to a much more structured template-based approach for some of the calls (which requires lots of IF type statements, more logging, subroutines) and we have not seen any impact on performance.
I have been working on the template that Vic designed for me some time ago. I have one strategy loaded on all of my VDNs and then it uses IF() to decide how to route the call.
A few weeks he has modified it so that it uses this GetConfigOption to determine on routing and I was trying to figure it out (I am worried that I have already asked him way too many question about this).
He even made it so that I don’t need to load strategies even. Pretty cool!
Ahh pulse_time.
We have noticed that the default value ‘2’ causes some delay in routing to the agents while using verification time (all 3 of them!).
We are planning to change it to ‘1’ soon, which should resolve one of our prod issues.
I found pulse-time to be a bit of a drag, because making it short causes some of the calls routed first even though there are more qualified calls that should have been routed ahead of time. We have 8 URSs working together via several LDS connected to quite a few T-Server, so as you can imagine, it complicates the thing incredibly.