We are using ARI for IVR application with complex logic which usually handle long calls - somethimes over an hour. Over the whole length of the call, it is handle only by ARI in the stasis application.
I have heard someone arguing that ARI was not designed for such cases, but rather for short operations where most of the call life time is handled by the dialplan.
Do you agree with this?
I think you may be confusing AGI and ARI. ARI is perfectly fine for long lived things.
Thats is what I thougth, but just wanted to be sure. Thanks.
Why no love for AGI? Why would AGI not be appropriate for long lived things?
AGI (not FastAGI) has a high penalty, and there can be weird interaction with running applications inside of an AGI.
I remember you saying this was a really expensive process (copy a bajillion memory pages, create a process or 2, recount all the votes in Georgia, …), but specifically in the context of ‘long lived things,’ this is something you pay up front and then you’re done. Even then, starting an AGI happens in the blink of an eye.
Actually, that’s a gross overstatement. I can start about 20 AGIs written in C on a Raspberry Pi 3b+ in the time it takes for a lazy blink
Fun observation – executing an AGI that just reads the AGI environment and sets a single variable with a static value (basically a ‘null’ AGI) takes about 0.026 seconds on a Pi3. The same task in PHP takes 0.129 seconds. A ‘real’ AGI application would do much worse in PHP because there is more source script to parse and interpret.
Of course, if you’re running on a Pi3, high ‘calls per second’ is probably not your goal.
In almost 2 decades of writing AGIs, every weird thing could be traced back to me doing something stupid like interacting with STDIN/STDOUT when I shouldn’t and breaking the AGI protocol.
Like all things, it depends on many variables. On a barely used system it’s nothing - like so. On a heavily used system it becomes expensive.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.