[asterisk-users] Benchmarking AGI performance in C, PHP, and Perl

[Steve Edwards]

> On 11/07/11 23:42, Steve Edwards wrote:

>> 'Standalone' AGIs still have advantages in lower complexity and less 
>> impact on failure. If a bug takes out your fastagi daemon it can affect 
>> all calls.

On Tue, 12 Jul 2011, Vincent Sweeney wrote:

> I'm pretty sure if you have a bug in your AGI code it's going to affect 
> all calls whether its fastagi or not.

I was thinking of a situation where not all calls follow the exact same 
path through the code and one of those paths caused the daemon to 
segfault.

> In a production environment any code will have gone through a testing 
> phase, so your argument about a compiled language detecting stupid 
> errors is pretty much irrelevant. Also most critical bugs will be in the 
> script logic not the syntax.

In a perfect world, we would all have regression testing in place to 
exercise every decision point and every value threshold in our code. I've 
never found a client willing to pay for that.

It has been my experience with many scripting languages that they do not 
syntax check my code, warn me if I have too many or too few arguments to a 
function, warn of undeclared variables or warn of unused variables. Gcc 
does all of these for me. Will 'strict' or 'taint' do this for me? In AEL, 
a single missing semicolon can cause large blocks of code to disappear. 
Maybe I'm just more clumsy at the keyboard, but I have had characters 
appear and disappear within an editing session.

> I'm also curious why you think the poor performance of a scripting 
> language actually matters for AGI code? As stated most of the time will 
> be spent by Asterisk streaming audio / waiting for a prompt. The few 
> extra milliseconds a php script takes to start up are not going to be 
> noticeable by any human listening to the call.

It matters once you know. It influences your decision making process.

In my home Asterisk box, it just doesn't matter. The dual cores (plus 
hyperthreading) of an Atom D525 with 4GB of RAM can handle the occasional 
2 or 3 simultaneous calls in its sleep.

Think of a system handling hundreds of simultaneous calls, tens of 
thousands of calls per day. All those milliseconds, all the memory 
footprints, all the disk accesses reading the 'uses' and 'requires' will 
add up.

Paraphrasing Senator Everett Dirksen, "A billion (th of a second) here, a 
billion (th of a second) there, and pretty soon you're talking about real 
money.”

Look back to the stats from my first post. Starting (not executing to 
completion) neutered-agi.pl (AKA agi-VDAD_ALL_outbound.agi) on the Geode 
took 2/3rds of a second. Obviously a Geode is the wrong platform for 
Vicidial, but that kind of delay can add up fast.

My first Asterisk system is still in production and making money for the 
client. It was designed (by me) very simplistically. Each AGI did one 
thing and then moved on. So an incoming call would execute set-globalid, 
block-ani, lookup-dnis, update-channel-status, update-caller-status and 
write-cdr all before the caller heard the first prompt. All the AGIs were 
coded in C, all but 1 access the database and it all happens in the blink 
of an ear.

I think I was lucky. I think if I had implemented the same design in Perl 
it would have fallen flat.

If I was to re-implement the system today I would obviously merge all 
these steps into a single AGI, but it works well and the client won't pay 
to fix what isn't broken.

-- 
Thanks in advance,
-------------------------------------------------------------------------
Steve Edwards       sedwards at sedwards.com      Voice: +1-760-468-3867 PST
Newline                                              Fax: +1-760-731-3000