On-hook agent and system load

[rahat651]

Hi,
We have a group of remote agents on PSTN phone. For the call queue to dial the next number if the previous number is busy we had to set the On-Hook to 'Y'.
Question is since all the agents are on mobile phone and not using web login will it create serious load on the system?
i.e. on a 16GB RAM and 2Ghz core i3 machine will it be able to handle 15 concurrent calls if there are 5000 remote agents in the queue?

[mflorell]

5000 remote agents will probably cause load issues. We have seen this issue before, but I don't really have a detailed scaling recommendation, it depends on how everything is configured.

[williamconley]

5000 doesn't sound like "remote agents", it sounds more like "prospects" ... these should be leads not agents!

[rahat651]

5000 agents but not active at the same time on the same inbound group. They are divided into 20/30 groups and not all of them will be active at the same time. But yes, 5000 of them will be there as remote agents. Considering that what will the system be enough or we have to scale it up?

[carpenox]

def not enough on the specs....

[williamconley]

The Vicidial system isn't really aware of inactive remote agents. Inactive SIP phones? Yes, because they appear in the sip-vicidial.conf file even when not registered, which would take an inordinate amount of time to load at any point asterisk has to interact with the file, in addition to the berkeley (live, loaded into memory) table representing all those sip accounts.

But 5000 entries in the remote agent table all being ignored except 20-30? Not a problem except during the loading of the web page to display them all. I might advise creating a tool to activate/deactive them outside that interface (activate/deactivate is a simple mysql query for individuals or groups). In fact, remote agents have a special login so they can "activate" their own remote agent entry by logging in.

Of course, you'll need 5000 users to go with those 5000 remote agents, and that will cause issues with the showing of the Users listing page. Simple enough to test, load up 5000 fake entries and check it out. While loading the "List Users" page (and sections in other modules, such as Ingroups) and the "Remote Agents" page will be slow, however, it shouldn't be a problem for functionality. Just be patient when those pages load.

I will note, however, that "i3" means nothing. Sorta like saying "would it be better to drive a Red or a White car on the freeway?" Irrelevant: How Many Cores? Two? Not likely to be happy with the result. Four? Perhaps ... test it. Ordinarily for our standard server we like to suggest four cores at 2.3+Ghz with 2G RAM as kind of the bare minimum. But two cores? MAY work, but I'd be surprised.

[carpenox]

either way an i3 has 4 threads.....if its dual core then hyper threading is active already and if its 4 core such as the 8th gen 8300 then you would have 8 threads which would run A LOT smoother if you have 16gb of ram.

[williamconley]

Not all Core i3 CPUs have hyperthreading (being the cheapest offering) and if they do, it may (or may not) provide a slight advantage or disadvantage. We have not yet found an advantage to use of hyperthreading on a server from 2 cores to 40 cores. We have clients that leave it on, and clients that insist it be off. Everyone's experience is of course personal, but load testing has not (to date) proven that the microsoft-windows-advantage-designed hyperthreading system will "fool" perl hi-res timing.

Put it under severe load, and watch it disintigrate. Not as bad as vSphere or a truly virtualized CPU, but not anywhere near perfection, either. So far, we have not proven an advantage to hyperthreading except in 40 core systems with slower processors being able to keep ALL Eighty Cores busy and pushing out processes fast enough to not overload.

When the core count dwindles that advantage tends to die off quickly since they tend to become unstable too quickly ... defeating the purpose of hyperthreading: calls routing incorrectly (and unpredictably so) under heavy load is simply not viable from a "Customer Service" standpoint.

[rahat651]

William, thanks for the very insightful information.