[asterisk-users] asterisk manager interface stability

[Lee Jenkins]

Matt Florell wrote:
> On 5/16/07, Lee Jenkins <lee at datatrakpos.com> wrote:
>> Matt Florell wrote:
>> > The issue has more to do with the sheer amount of data passed to the
>> > client from within the Asterisk application when you have 50-100+
>> > clients connected to the AMI on full output mode. Running a system with
>> > FreePBX/Trixbox especially generates vast amounts of output that has to
>> > be generated on every AMI connection for every client. This is not
>> > trivial and can result in lockups very easily, although this has gotten
>> > much better since the early 1.0 versions.
>> >
>> > The new Asterisk Manager web API in 1.4 is a good step where sending of
>> > Actions does not require an actual Telnet conneciton to the AMI, but I
>> > think to be able to handle larger numbers of concurrent connections 
>> that
>> > a separate send-only and a separate receive-only type of interface be
>> > built where Asterisk would just output all AMI data to a single
>> > server-like application that would then broadcast it to all connected
>> > clients. This would remove the burden of so many connections going
>> > directly into Asterisk and would allow for much larger scaling of
>> > AMI-type applications that require real-time output of AMI events.
>> >
>>
>> I definitely agree here personally.  Clients could connect to this
>> "proxy" and subscribe to only the events that are interesting or 
>> applicable.
>>
>> > As for how to go about doing this, I can't help you there. I did 
>> build a
>> > very specialized version of something like this 4 years ago for the
>> > astGUIclient project called the Asterisk Central Queue System(ACQS) It
>> > is based on 1.0 Asterisk but it still works with 1.2 and 1.4. It is
>> > limited in what it does, but it does scale much better than using 
>> direct
>> > AMI connections.
>>
>> I've been considering writing something like this for a project that I'm
>> thinking about doing that would require potentially high number of
>> concurrent clients to consume AMI services.
>>
>>  From your experience, does the software that you wrote require
>> significant CPU to cache and then doll out the kind of volume of
>> messages that AMI can send?
> 
> One of the great parts about removing the broadcasting of AMI events
> outside of the Asterisk process is that the broadcast server process
> can exist on a separate physical server removing any kind of overhead
> on the Asterisk server.
> 
> In my experience doing the "proxy" on the same machine uses less CPU
> resources than the same number of AMI connected clients, and doesn't
> have any of the deadlock issues that can happen with a lot of direct
> AMI connections.
> 
> For my application(ACQS) I use MySQL as a storage engine for all of
> the recent events received and sent so that they can be independantly
> queried by any client apps that need to see them.
> 
> MATT---
> 

Neat.  So the clients use a polling model?  Individual clients then 
query only for events that are interesting?
-- 

Warm Regards,

Lee