How to simulate vicidial with certain number of remote agent

[jessiekidfernando]

Hello Everyone,

We have new vicidial servers under development stage. We can do performance testing using the test leads and dialplan based from PERFORMANCE_TESTING.txt's instructions. However we are thinking of how we will be able to simulate a scenario wherein there are 50-100 agents connected to server and making an outbound call (predictive) without having an actual agents connected to it.

Also, may I know the most effective way to stress test the server? Thanks in advance.

Regards,

Jessie

[williamconley]

1) Welcome to the Party!

2) As you are obviously new here, I have some suggestions to help us all help you:

When you post, please post your entire configuration including (but not limited to) your installation method (7.X.X?) and vicidial version with build (VERSION: 2.X-XXXx ... BUILD: #####-####).

This IS a requirement for posting along with reading the stickies (at the top of each forum) and the manager's manual (available on EFLO.net, both free and paid versions)

You should also post: Asterisk version, telephony hardware (model number is helpful here), cluster information if you have one, and whether any other software is installed in the box. If your installation method is "manual/from scratch" you must post your operating system with version (and the .iso version from which you installed your original operating system) plus a link to the installation instructions you used. If your installation is "Hosted" list the site name of the host.

If this is a "Cloud" or "Virtual" server, please note the technology involved along with the version of that techology (ie: VMware Server Version 2.0.2). If it is not, merely stating the Motherboard model # and CPU would be helpful.

Similar to This:

Vicibox X.X from .iso | Vicidial X.X.X-XXX Build XXXXXX-XXXX | Asterisk X.X.X | Single Server | No Digium/Sangoma Hardware | No Extra Software After Installation | Intel DG35EC | Core2Quad Q6600

3) That's part of the performance testing instructions. The recordings that will "answer" the calls have varying lengths, varying length calls will stay "live" long enough so you can alter the "remote agent count" by altering the "Number of Lines" and by adding extra remote agents. You can also alter the number of leads with various last digits to force longer recordings to be more or less often invoked. The last digit of the number determines the response, if I recall correctly.

4) To be able to VIEW these agents in the real time screen, be sure to create a User for each remote agent, remembering that "10 lines" for a remote agent with User ID "2001" will result in users 2001 through 2010, so you'll need to create all 10 users to see their present status in real time (if you don't want to see their status in real time: you need only create user 2001). The first user is required, the rest are only useful for the real time screen. Also remember to avoid overlaps!

[jessiekidfernando]

Thank you so much for your inputs William.

[jessiekidfernando]

Hello William,

Quick question, is there any way except for remote agents that we can simulate having like a real 300 agents doing predictive outbound calling?

Regards,

Jessie Kid Fernando

[williamconley]

1) No. To "simulate" having agents you must actually have agents logged in. There are two types of agents: Logged in Agents with a web browser and Remote agents without a web browser. So to simulate agents you'll need to use one of these two. While it would be possible to write software to log in and "act" like an agent, that seems a bit crazy when Remote agents already exist and they don't need to simulate web interaction, they just need to be "active".

2) That's what those 60000 sample records are for. They have special fake numbers which have linked patterns in the extensions.conf file to simulate various outcomes (busy, answer, ADC, etc). Look in /etc/asterisk/exensions.conf and find "999XXXXXX". Those patterns are there to catch each fake number for load testing and simulate the associated response. Load up as many leads as you want which fit that dial pattern and then put as many remote agents on as you ike and "go". Note that the remote agents will need to answer and at least play back silence. They can also be on the Vicidial server for simplicity, but for load testing they should probably be on another asterisk "agent" server.

3) I believe this is covered in the Manager's Manual.

[jessiekidfernando]

Hello William,

Thanks a lot for your points. However we would like to simulate the dialers making really an outbound calls going to our provider and merging it with the current active meetme conference bridge where the agents are currently logged in.

Basically we want to simulate a real scenario and not just the load testing. Hope you could provide additional inputs.

Regards,

Jessie

[williamconley]

now you've breached into ".... Why?" territory. What's your endgame?

Of course, software could be written for this, but before we go there you are asking to simulate which end of this spectrum? I mean, you want to simulate inbound call? simulate logged in agents with agent screens? or both? if you're simulating both ends of the call, that's load testing alright. But WHY?

[jessiekidfernando]

Hello William,

We just like to simulate only outbound calls and how these are being connected to agents with total# of logged in agents with agents screen. Mainly because we are getting high wait time. It is though happening intermittently.

Regards,

Jessie

[williamconley]

OK: So your goal is to find out why you have high wait times, but NOT to experiment with this during production as that causes a loss of $$.

You'll need to get some information about what is causing the wait time from your live system. Otherwise, you could spend a year trying to simulate a condition that can't be determined any other way than "live".

Next time the high wait time occurs, check the DB server's processlist for "stuck" sql queries. You can also check the mysql slow query log.

Also check:
* Hopper for the campaign with high wait time. Empty hopper can cause this issue and is often overlooked by showing ALL campaigns instead of ONE campaign, since that shows hopper level for all instead of one. Empty hopper can sometimes be caused by MySQL slow queries, however. But it's a good place to start if that's the problem.
* "Short/Fill" values in the real time screen. This can be an indicator that your system is overloaded and/or your manager is pushing the system incorrectly (one campaign requesting 500 channels when only 300 are available systemwide ... means other campaigns may get NO channels at all).
* Carrier stats (an option in the real time screen). Often there is a surge in congestion. Your percentages in each call type should not vary much over time. If congestion was 3% over 24 hours, but jumps to 35% in the last 5 minutes, something is amiss).

But if you want to simulate a crap ton of outbound calls, thats what those extensions I showed you previously are for. Either load the 60k sample leads, or just use a spreadsheet to generate leads matching those patterns. Then add some remote agents and fire it up. You may find your bottleneck.