Page 1 of 1
FastAGI_log
Posted:
Tue Apr 15, 2008 3:07 am
by 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
Posted:
Tue Apr 15, 2008 8:26 am
by 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.
Posted:
Tue Apr 15, 2008 1:49 pm
by bobbymc
so what is the setting these should be and what do i need to configure to handel 400 calls at once?
Posted:
Tue Apr 15, 2008 10:24 pm
by mflorell
with 400 calls it should still be OK, but what kind of hardare are you pushing 400 calls out on?
Posted:
Tue Apr 15, 2008 10:27 pm
by 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
Posted:
Tue Apr 15, 2008 10:36 pm
by 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.
Posted:
Tue Apr 15, 2008 11:06 pm
by 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
Posted:
Tue Apr 15, 2008 11:07 pm
by 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...
Posted:
Wed Apr 16, 2008 8:23 am
by 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.
Posted:
Wed Apr 16, 2008 9:57 am
by 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.
Posted:
Wed Apr 16, 2008 10:58 am
by 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.
Posted:
Thu Apr 17, 2008 8:37 pm
by bobbymc
so which part on asterisk takes the most resources? the hanging up and calling or a live call?
Posted:
Fri Apr 18, 2008 2:45 am
by 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.
Posted:
Fri Apr 18, 2008 2:47 am
by 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
Posted:
Fri Apr 18, 2008 2:52 am
by 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.
Posted:
Fri Apr 18, 2008 3:43 am
by 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?
Posted:
Fri Apr 18, 2008 7:57 am
by 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.
Posted:
Sat Apr 19, 2008 2:04 pm
by bobbymc
whats the difference between local closer and internal closer? and what is the difference between the tracking of both?
Posted:
Sat Apr 19, 2008 5:22 pm
by mflorell
As of 2.0.4 Internal closer is gone.
The only difference is 990009 vs. 90009
Re: FastAGI_log
Posted:
Tue Jul 10, 2012 5:58 am
by 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
Re: FastAGI_log
Posted:
Tue Jul 10, 2012 6:27 am
by 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.
Re: FastAGI_log
Posted:
Tue Jul 10, 2012 7:07 am
by 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
Re: FastAGI_log
Posted:
Tue Jul 10, 2012 7:10 am
by 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 =)
Re: FastAGI_log
Posted:
Tue Jul 10, 2012 12:33 pm
by 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.
Re: FastAGI_log
Posted:
Sun Jul 15, 2012 3:19 am
by 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?