On 5/18/07, Lee Jenkins <[EMAIL PROTECTED]> wrote:
Matt Florell wrote:
> On 5/16/07, Lee Jenkins <[EMAIL PROTECTED]> 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
_______________________________________________
--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