FastAGI_log

[bobbymc]

Can you please explain to me what exactly each of these does? im currently trying to push 300 simultaneously calls and need to know what to set these to exactly

$VARfastagi_log_min_servers
$VARfastagi_log_max_servers
$VARfastagi_log_min_spare_servers
$VARfastagi_log_max_spare_servers
$VARfastagi_log_max_requests
$VARfastagi_log_checkfordead
$VARfastagi_log_checkforwait


Thanks for all the help matt

[mflorell]

for 300 calls you shouldn't have to change anything. I've pushed over 500 concurrent calls before anything weird started happening, and I don't think it was FastAGI log that caused it.

[bobbymc]

so what is the setting these should be and what do i need to configure to handel 400 calls at once?

[mflorell]

with 400 calls it should still be OK, but what kind of hardare are you pushing 400 calls out on?

[bobbymc]

4 cpu box qual core 2ghz... if we has it running on freeswitch we could push 3000 at once on a dual 2ghz... thats why i really want to work on freeswitch

[mflorell]

Could you tell me more about the 3000 calls?

What codec?

Was the media stream going through the switch or were the calls native bridged?

Were these calls going through a conferencing engine?

How many calls were being launched/hungup every minute?

I have pushed almost 1500 calls through Asterisk on a single CPU dual core server, but no media processing, and no conferencing engine so it wasn't really a good measure of VICIDIAL capacity.

[bobbymc]

Well freeswitch can proccess 3000 calls at once WITH media from confrence rooms.. it has confrence capabilities.. the 3000 is with ulaw . these were 3000 calls at once with no hangups.. constantly flowing.. thats all with freeswitch

[bobbymc]

i dont mind developing with you or the other developers to get it going.. think about it.. 3000 calls at once with a dual 2 ghz.. imagen the money u can save with that volume.. its amazing...

[mflorell]

As I mentioned, sustained concurrent calls is not very important as far as VICIDIAL is concerned, it's how the system handles a high volume of short calls in a short period of time. For instance, what is the load when you push 30,000 calls through the system in a single hour.

[chasejordan1]

If Matt is saying you can do 400 concurrent calls then wouldn't it be cheaper to just build/buy 7 more computers? I have a Dual Core AMD 2.0 ghz w/1 gig of ram and a 160 stata drive for my asterisk machine, I use this computer to do autodial with press 1. Example I make a call person answers hears a 30 sec message presses 1 is transferred to an agent, if no agents available they go to a VM box and hear another 30 sec message and then leave a VM for us. GSM is my codec. I run this 3 to 10 hours a day with perfect call quality and my CPU usage is 8% to 30% on both CPU's and the load balance is from .5 to 15.00 but averages 1.5 to 2.5 I have been doing this for over a year. The "server" cost me $450 to build colocation cost me $250 per month (10 megs up and down) and I do 15 call per second and almost never have an issue. So $450 per server multiplied by 7 is $3150. Sure it would cost $1750 per month to have the servers at the colocation but ya need the bandwidth if you are going to make 3000 calls either way or you would have to pay for the T-1's etc.

[mflorell]

One other important note, when I usually refer to "concurrent calls" I am talking about VICIDIAL concurrent calls, not just calls staying on the line for a long period of time.

"VICIDIAL concurrent calls" would mean a very high turn-over of the lines in use and a high rate of calls placed and hung up every minute. That is why this number is very much smaller than hat you would see on an Asterisk forum if someone as talking about concurrent SIP calls from an ITSP. it's apples and oranges.

[bobbymc]

so which part on asterisk takes the most resources? the hanging up and calling or a live call?

[mflorell]

hanging up and calling.

build up and teardown of a call will always take more processing power whether you are using FreeSwitch, CallWeaver or Asterisk.

[bobbymc]

i know its off topic.. im a bit confused how to use the dial level when you set the campaign to adapt. Do i set the dial level to 1 and max adapt level to 7 for example? does it ever look at dial level? does it matter what its set to? im really confused how this works can you please shine some light on this for me.. thank you

[mflorell]

In ADAPT modes the auto-dial-level just needs to be set at 1 or above and the predictive algorithm will take over from there. It will look at the max dial level as an absolute maximum dial level for the campaign.

The dial level is used by the dialing application to figure out how many calls to place.

[bobbymc]

thank you for that info.. the other question is what settings am i not allowed to change while the campaign is running.. can i change it from adapt to ratio ? can i touch the dial level.. what settings are sensitive to change in a active campaign?

[mflorell]

You can change just about any setting while the campaign is running. You may run into some agent problems if you change the dial method to or from MANUAL in the middle of a shift, but other than that everything else is made to be changed on the fly.

[bobbymc]

whats the difference between local closer and internal closer? and what is the difference between the tracking of both?

[mflorell]

As of 2.0.4 Internal closer is gone.

The only difference is 990009 vs. 90009

[bobbymc]

so i finally switched to ast 1.4.39 and hope the IAX trunk will be more stable. Matt whats the largest amount of concurrent "vicidial" calls on a load balanced system you have dealt with so far? and what were the hardware requirements if i may ask? I like to have a idea of how hard to push a individual server. What is the highest load avg that you let the server go to? for example on 8 cores 8.0 load avg would mean 100% of the cpu total is reached.. how much percent i guess do you let the server go to? i seem to have some issues where the agi scripts never end up getting the channel information when the call picks up which causes the transfer button not to light up when the call comes in on a manual call.

also any progress on supporting newer versions of asterisk? i would love to work on 1.8 if you can point out which scritps in the project need troubleshooting / upgrading

[mflorell]

by "system" do you mean a single server or a cluster?

we usually put many lower-end servers together to achieve higher call volumes because it is cheaper and more reliable that using large systems. The largest cluster I can think of that operates on a single database server has almost 3000 lines connected to it and could dial well over 1,000,000 calls per day.

As for loadavg, yes you should keep it at or below 1 x the number of real CPU cores.

[bobbymc]

by system i mean a cluster

what specific version of asterisk do you recommend and have what are your iax jitter settings you recommend. im not very familier with what the most optimal iax jitter and other settings are.. maybe you know specific variables that are best set to a specific value?

also what scripts should i concentrate on first to get them to be compatible with ast 1.8 or even 1.10

[bobbymc]

BTW since asterisk isnt best at taking full advantages of all cores i suggest to use xen server to virtualize the ast boxes into smaller servers to handle overall more calls.. and by simply commenting out the RTC requirement in ztdummy and setting the kernel HZ to 1000 as usual you can archive virtualization without having choppy calls. im currently still testing it out but it looks promising so far. let me know if you give it a shot =)

[mcargile]

The best version of asterisk so far is still Asterisk 1.4.21.2, but zaptel is not compatible with newer kernels. http://download.vicidial.com/required-a ... ici.tar.gz is the latest version that we have had good luck with.

As far as Xen is concerned we do not recommend any level of Virtualization. Virtualization adds another layer of complexity and does not address the major factor in scaling of Asterisk. Asterisk is both a processor intensive application and a I/O intensive application. There is only one system bus in any single server. This does not change when you add Virtualization on top of it. If the I/O does not get where it is suppose to go in time, you will have problems. It is far better and less expensive to build a proper cluster with multiple smaller servers than to try and shove tons of agents onto a huge server. A quad core with between four and eight gigs of Ram is more than plenty for 25 agents dialing at a 4 to 1 ratio. You can build servers like this for less than 700 dollars using quality components if you source them well.

As for asterisk 1.8 support, don't bother. I am mostly done with it. At this point Matt needs to adjust some things in the agent interface, but he needs to finish some pay development before he can get to this. When we get there we will be looking for beta testers. Also asterisk 1.8 probably wont be very stable for production use for a long time. Support for asterisk 1.4 was added about 1.4.10 and it was not properly stable till asterisk 1.4.18 and we did not start recommending it till asterisk 1.4.20. In my tests asterisk 1.8 is not crashing, but it has some very strange errors that are limiting its scalability and causing issues with recordings.

[bobbymc]

Thank you so much for all your input. I totally understand how 1.8 could be a long way to go. I wouldn't mind contributing backend coding to finish any pending tasks. is there a place i can download the source that works wth 1.8 and get some details which areas have already been worked on to study whats been developed?