[asterisk-app-dev] ARI in production

[Damir Kalashnikov]

Matthew,

I was not explicit - I meant scaling UP on a single machine. I plan to have
a cluster installation in future but for first version it will be a single
machine installation. We will be able to get a beefy machine in terms of
specs, but nothing extraordinary (up to 8 core Intel CPU and up to 32GB of
RAM).

We do not plan do a lot of I/O or CPU intensive things, 90% of time
connecting and routing incoming calls, collecting call statistics. 10%
playing saved audio and voicemail.

My main performance related concern was, if asterisk can support having 200
simultaneous channels sitting in stasis application/s, and 90% of those
channels are in a state when they are connected to one another or to
external line (i.e. no CPU or I/O intensive work is  being done). From what
I understood, it does not look like a problem.

Regarding stability of ARI. Are currently exposed ARI APIs stable enough to
the point that I can rely on them in production (at least to the extent
that I could rely on Asterist 11 version of FastAGI) ?

Thanks,
Damir


On Mon, Jun 16, 2014 at 10:59 PM, Matthew Jordan <mjordan at digium.com> wrote:

>
> On Mon, Jun 16, 2014 at 6:14 AM, Ben Merrills <b.merrills at mersontech.co.uk
> > wrote:
>
>> Asterisk is scalable, ARI's issue (some would argue) is that you
>> establish a connection with it for Stasis, not the other way round like
>> FastAGI.
>>
>> To that end, the current accepted work around is to have some sort of
>> local proxy on the Asterisk instances that establishes the ARI connection
>> for your application, and then forwards on messages (using a message bus)
>> to a central application.
>>
>> Most of what you want to do (by the sounds of it) can be done just as
>> easily with FastAGI. ARI has a use case more in common with Asterisk
>> Applications (e.g. app_queue etc). That's not to say however you can't use
>> ARI for your setup.
>>
>> I am not sure if anyone has a large production scale setup out there
>> using ARI, but all being well if they have they'll chip in to this
>> conversation. We have large FastAGI deployments out there though, so if you
>> feel ARI might not be the best solution right now, use AGI and revisit this
>> later maybe?
>>
>> Ben
>>
>>
>> Damir Wrote:
>> Hi Ben,
>>
>> Thank you for you answer.
>>
>> With regards to scalability I am not so much concerned with scalability
>> of .NET part, I am more worried about Asterisk itself. For example, would
>> current implementation support having 200 concurrent channels all 'inside
>> stasis'? Has anyone tried out anything like that?
>>
>> How about stability/robustness of the ARI itself? Would you consider it
>> production ready? At least to the extent of current APIs? Or would you say
>> that I am better off using FastAGI?
>>
>> Damir
>>
>> On Mon, Jun 16, 2014 at 6:20 PM, Ben Merrills <
>> b.merrills at mersontech.co.uk> wrote:
>> Hi,
>> A number of us are looking at scalability at the moment for Asterisk ARI
>> (multi node etc), Paul Belanger has created a solution to work with Python
>> and his ARI framework (https://github.com/kickstandproject/python-ari) ,
>> and I am currently investigating options for AsterNET.ARI (
>> https://asternetari.codeplex.com/) which is a .NET framework for
>> Asterisk ARI.
>>
>> ARI itself is of course still in development and improvements and
>> features are being added all the time. Myself (skrusty) and Paul
>> (pabelanger) are both on IRC and I am sure he, as I would be happy to
>> discuss what we've done in this area so far.
>>
>> Ben
>>
>> Damir Wrote:
>> Hi All,
>>
>> I am new to this mailing list and maybe this question was asked before.
>> Sorry if that is the case.
>>
>> I am starting a new greenfield project and I am strongly considering
>> using ARI. I have just started learning about ARI.
>>
>> The project itself is going to be .NET based and have features like IVR,
>> voicemail management, call routing etc.
>>
>> I plan to use ARI for as much as the API provides (and I have a feeling
>> that it will cover most of my needs) however I am not sure about its
>> stability/scalability, I know that version 12 is not a long term release
>> but it is still an official release.
>>
>> Do you think that ARI is considerably stable/scalable ( for handling ~200
>> simultaneous calls) so that I can use it in production?
>>
>
> In many ways, ARI is "closer" to the actual Asterisk core than Asterisk's
> other interfaces. While any layer of abstraction that involves external
> communication is going to add some overhead, I'd expect that whatever
> performance you can get out of a machine is going to be dictated by factors
> other than ARI.
>
> For example: if your intended use case is to record all calls, setting up
> a Snoop channel and issuing the /record operation is not going to be the
> bottleneck - your disk I/O will be.
>
> A few other thoughts:
>
> - "Scaling" is an ambiguous term. Do you mean to scale up on a single
> machine, or scale out? As Ben alluded to, there are things you have to
> consider when scaling out. Since your application connects to each Asterisk
> instance (currently, at any rate), a proxy to manage the location of the
> Asterisk servers can be beneficial. Being HTTP based, there are lots of
> options in this area. Scaling up, on the other hand, is much more a factor
> of your hardware choices and use cases.
>
> - I would treat each of your use cases separately. Building out an IVR in
> ARI is much different than building a VoiceMail system. ARI works well on a
> model of separate application spaces, which will help keep your separation
> of concerns in each application clean.
>
> --
> Matthew Jordan
> Digium, Inc. | Engineering Manager
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at: http://digium.com & http://asterisk.org
>
> _______________________________________________
> asterisk-app-dev mailing list
> asterisk-app-dev at lists.digium.com
> http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20140617/807842ba/attachment-0001.html>