[asterisk-users] asterisk manager interface stability

[Matt Florell]

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---

> If I end up writing something myself, I'll release it as OS...
> --
>
> Warm Regards,
>
> Lee
>
>
>
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
>