| asterisk2billing.org http://forum.asterisk2billing.org/ |
|
| Batch processing calls http://forum.asterisk2billing.org/viewtopic.php?f=18&t=4698 |
Page 1 of 1 |
| Author: | middletn [ Tue Dec 23, 2008 10:06 am ] |
| Post subject: | Batch processing calls |
Has anyone looked in to this at all? We are getting to a situation where our call attempts will be in excess of 1m calls/month with projections of 20m/month next year. I have my doubts that A2B will be able to handle this, so I'm looking at batch processing answered calls over night into A2B as the billing doesn't need to be real time. (And before anyone says it, no we're not even close to those numbers yet, just looking at advance orders for next year) My thoughts were to read the asterisk call logs (.csv) and insert them via the rating engine into the db) Regards |
|
| Author: | jroper [ Tue Dec 23, 2008 12:17 pm ] |
| Post subject: | |
Hi Some great strides forward have been made in the architecture and efficiency of A2Billing 1.4 This may be able to take up the slack on your extra call volume. Joe |
|
| Author: | middletn [ Tue Dec 23, 2008 6:49 pm ] |
| Post subject: | |
Great as A2B is, I'm not 100% convinced it'll handle the load. We're starting at 250 simulatenous calls as that's the max number of lines right now, but going repaidly to 4000 and then to 8k. Even running at 75 simulatneous call setups, we were on an 80%cpu load. For this volume of transactions, a) I don't need realtime and b) I'd need a monster server. I'm happy to be proved wrong though 
|
|
| Author: | jroper [ Tue Dec 23, 2008 7:05 pm ] |
| Post subject: | |
Realtime + Multiple Asterisk servers should work for you though, and a system of load balancing. I suspect the bottleneck is in asterisk, not A2Billing. Joe |
|
| Author: | xrg [ Tue Dec 23, 2008 7:48 pm ] |
| Post subject: | |
One limitation is the number of db connections. Even if the config limit changes, keeping >200 connections open sounds like a waste of resources and could congest the db engine itself. The other thing is keeping a whole PHP context (+process) open for the duration of a call. It is definitely a silly abuse of resources, too. Remember that the a2b code itself is light. The context overhead is what could be greatly optimized. In other news, welcome to the '10k' branch... |
|
| Author: | stavros [ Tue Dec 23, 2008 8:06 pm ] |
| Post subject: | |
xrg wrote: The other thing is keeping a whole PHP context (+process) open for the duration of a call. It is definitely a silly abuse of resources, too. Not forgetting that splitting the AGI into two sections (pre-call and post-call) would eliminate A2B's illegal usage of DeadAGI() and thus the warning we're all accustomed to seeing: "Running DeadAGI on a live channel will cause problems, please use AGI"
|
|
| Author: | xrg [ Tue Dec 23, 2008 8:26 pm ] |
| Post subject: | |
stavros wrote: Not forgetting that splitting the AGI into two sections (pre-call and post-call) would eliminate A2B's illegal usage of DeadAGI() and thus the warning we're all accustomed to seeing: "Running DeadAGI on a live channel will cause problems, please use AGI"
DeadAGI is dead, long now.. I've been using AGI without any problem in both 1.4 and 1.6 quite some time. I'm, however, afraid, that it is non-trivial to split the AGI stuff. You see, we /have to/ keep a stateful context during the call. What's more, if you remember v200, it is much better that you store the call in the db both before it starts and after it ends. |
|
| Author: | stavros [ Tue Dec 23, 2008 8:31 pm ] |
| Post subject: | |
xrg wrote: What's more, if you remember v200, it is much better that you store the call in the db both before it starts and after it ends. Yes indeed, you'll get no argument from me there. That's exactly what I do for the billing solution I've wrapped around GNUGK. I also update the call duration column every 30 seconds whilst the call is active.
|
|
| Author: | middletn [ Tue Dec 23, 2008 11:22 pm ] |
| Post subject: | |
OK guys, you're loosing me a little here, (been working on other projects for a while) Have there been any developments that can help me handle the afore mentioned call volumes? A2B db is on it's own server, so no asterisk locally Regards |
|
| Author: | stavros [ Wed Dec 24, 2008 1:44 am ] |
| Post subject: | |
As Joe pointed out, you're unlikely to find problems with the AGI as that cost is determined solely by the complexity of your rate-cards, etc. However, you probably will discover more scaling problems in the web interfaces. ISTR there have been two fixes to trunk recently dealing with these kinds of issues. Due to shortcoming in Asterisk's architecture you're unlikely to be able to reliably scale a single Asterisk v1.4 instance far beyond your current 250 calls, so multiple Asterisks will be necessary. The last time I measured it, an instance of the AGI used approximately 12MiB (on a 64-bit system) so size your server accordingly. |
|
| Page 1 of 1 | All times are UTC |
| Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |
|