asterisk users - Feb 2004 - Re: Outgoing parallelism

Thanks, Scott.  I'm in a general exploration mode, but I do have a small 
broadcast application in mind.  My limited experimentation leads me to 
suspect that there is no queue management at all.  I was testing with 
only a single call file just minutes ago, and the system tried to redial 
the destination as a retry (60 second interval had been spec'ed), even 
though the first call was still in progress!

I suppose I will have to manage throttling with some kind of completely 
external process, which is likely to be cumbersome.  For the immediate 
application, and given my current facilities, single threading will be 
adequate (and necessary), but from what I've seen, even this could be 
challenging.  If I put together anything generally useful, I'll share it.

From: "Scott Stingel" <scott@evtmedia.com>

Hi Bill-

I've built some load testers for asterisk, using the outgoing call facility.

It's been a little while, so you may want to test this yourself, but I
recall finding a couple of problems:

(a) I don't think it manages queuing very well if there are a limited amount
of outbound resources.  For example (again, from memory), if you define a
group ("g9" for example) of two lines for use in outbound calling, it
works
fine if the number of outbound calls to be made at any moment never exceeds
2.  A third call file in this example, will be grabbed by asterisk, but will
fail immediately.  So I had to create a mechanism in my Perl script to
ensure that the outbound calls actually completed - no easy feat since I
couldn't tell when that occurs from the perl script too easily.

(b) There was a problem dumping more than about 12-15 outbound calls at once
in the outgoing directory, even if there were plenty of channels available
to make the calls.  Asterisk would grab them but would not process some of
them. This is a load-testing scenario, and not too common I realise, but
something to be aware of.  It didn't seem to matter if I switched to a more
powerful processor.

These problems occurred using a December release of asterisk - maybe they
are fixed now??

Please let me know if you are doing any load testing, and I'll send you some
simple scripts if you like.

The outgoing facility works fine at lower call volumes, if you stagger the
creation of the files in the outgoing directory.

You can manage when the call starts by setting the atime (or is it
ctime?) of the blah.call file.  See my sample script at
www.fnords.org/~eric/asterisk  It's the Callback script.  You can also
manage it WITHIN the AGI application run by the blah.call script, of
course.

On Sun, 2004-02-29 at 10:49, Bill Michaelson wrote:
> Thanks, Scott.  I'm in a general exploration mode, but I do have a
small
> broadcast application in mind.  My limited experimentation leads me to 
> suspect that there is no queue management at all.  I was testing with 
> only a single call file just minutes ago, and the system tried to redial 
> the destination as a retry (60 second interval had been spec'ed), even 
> though the first call was still in progress!
> 
> I suppose I will have to manage throttling with some kind of completely 
> external process, which is likely to be cumbersome.  For the immediate 
> application, and given my current facilities, single threading will be 
> adequate (and necessary), but from what I've seen, even this could be 
> challenging.  If I put together anything generally useful, I'll share
it.
> 
> From: "Scott Stingel" <scott@evtmedia.com>
> 
> Hi Bill-
> 
> I've built some load testers for asterisk, using the outgoing call
facility.
> 
> It's been a little while, so you may want to test this yourself, but I
> recall finding a couple of problems:
> 
> (a) I don't think it manages queuing very well if there are a limited
amount
> of outbound resources.  For example (again, from memory), if you define a
> group ("g9" for example) of two lines for use in outbound
calling, it works
> fine if the number of outbound calls to be made at any moment never exceeds
> 2.  A third call file in this example, will be grabbed by asterisk, but
will
> fail immediately.  So I had to create a mechanism in my Perl script to
> ensure that the outbound calls actually completed - no easy feat since I
> couldn't tell when that occurs from the perl script too easily.
> 
> (b) There was a problem dumping more than about 12-15 outbound calls at
once
> in the outgoing directory, even if there were plenty of channels available
> to make the calls.  Asterisk would grab them but would not process some of
> them. This is a load-testing scenario, and not too common I realise, but
> something to be aware of.  It didn't seem to matter if I switched to a
more
> powerful processor.
> 
> These problems occurred using a December release of asterisk - maybe they
> are fixed now??
> 
> Please let me know if you are doing any load testing, and I'll send you
some
> simple scripts if you like.
> 
> The outgoing facility works fine at lower call volumes, if you stagger the
> creation of the files in the outgoing directory.
> 
> 
> 
> 
> _______________________________________________
> Asterisk-Users mailing list
> Asterisk-Users@lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
-- 
Eric Wieling <eric@fnords.org>
BTEL Consulting