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.
regards,
Scott M. Stingel
Emerging Voice Technology Inc.
Palo Alto California and London England
Email: scott at evtmedia.com
URL:www.evtmedia.com
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Bill Michaelson
Sent: Sunday, February 29, 2004 1:18 PM
To: [EMAIL PROTECTED]
Subject: [Asterisk-Users] outgoing spool parallelism
Thanks for the suggestions on the hotel wake-up! Actually, I
don't have
a hotel, but my earlier request was unanswered because I
suppose it was
uninspiring. So I used a hard example that was readily identifiable.
Your helpful responses led me to the facility I had not
managed to find
by myself in the docs. Now that I've tried it, and it works, I've got
some more specific questions about it's operation...
How does * manage concurrency when processing files in the outgoing
directory?
Does it have some kind of intelligence or controlling mechanism which
serializes requests based on the capacity of resource combinations
required to satisfy the requests?
Or is it just a single thread/processing queue for all
requests found in
the spool dir?
Also, is there any way to control the sequencing (priority) of the
enqueued requests? Or is it a random free-for-all?
--
Bill Michaelson - COS, Incorporated - Software Development -
[EMAIL PROTECTED]
Thanks for putting up with my spam filter!
___
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
___
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
