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