[asterisk-users] asterisk manager interface stability

[Matt Florell]

On 5/18/07, Lee Jenkins <lee at datatrakpos.com> wrote:
> 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

Yes, the clients only connect to the MySQL database and can query the
events as they need to for their display.

MATT---



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