Support A2Billing :

provided by Star2Billing S.L.

Support A2Billing :
It is currently Thu Mar 28, 2024 10:35 pm
Voice Broadcast System


All times are UTC




Post new topic Reply to topic  [ 10 posts ] 
Author Message
 Post subject: Batch processing calls
PostPosted: Tue Dec 23, 2008 10:06 am 
Offline

Joined: Mon Oct 01, 2007 10:44 pm
Posts: 230
Location: Bovey, Devon, UK
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


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 23, 2008 12:17 pm 
Offline

Joined: Fri Jun 23, 2006 3:56 pm
Posts: 4065
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


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 23, 2008 6:49 pm 
Offline

Joined: Mon Oct 01, 2007 10:44 pm
Posts: 230
Location: Bovey, Devon, UK
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 :)


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 23, 2008 7:05 pm 
Offline

Joined: Fri Jun 23, 2006 3:56 pm
Posts: 4065
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


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 23, 2008 7:48 pm 
Offline

Joined: Thu Oct 19, 2006 9:56 am
Posts: 300
Location: Athens, Greece
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...


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 23, 2008 8:06 pm 
Offline
Moderator
User avatar

Joined: Thu Jun 22, 2006 2:19 pm
Posts: 2890
Location: Devon, UK
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"


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 23, 2008 8:26 pm 
Offline

Joined: Thu Oct 19, 2006 9:56 am
Posts: 300
Location: Athens, Greece
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.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 23, 2008 8:31 pm 
Offline
Moderator
User avatar

Joined: Thu Jun 22, 2006 2:19 pm
Posts: 2890
Location: Devon, UK
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.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 23, 2008 11:22 pm 
Offline

Joined: Mon Oct 01, 2007 10:44 pm
Posts: 230
Location: Bovey, Devon, UK
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


Top
 Profile  
 
 Post subject:
PostPosted: Wed Dec 24, 2008 1:44 am 
Offline
Moderator
User avatar

Joined: Thu Jun 22, 2006 2:19 pm
Posts: 2890
Location: Devon, UK
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 
Hosted Voice Broadcast


All times are UTC


Who is online

Users browsing this forum: No registered users and 10 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group