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

[Steve Edwards]

> On Mon, Jul 11, 2011 at 5:29 PM, Steve Edwards
> <asterisk.org at sedwards.com> wrote:

>> Many times, I've made the statement that you can execute hundreds of AGIs
>> written in C in the time it takes to load an interpreter and parse a script
>> written in PHP or Perl.

I can see I'm going to spend the rest of my days erasing 'hundreds' and 
replacing it with 'dozens.' Everybody is quoting the obsolete ratio :)

On Mon, 11 Jul 2011, David Backeberg wrote:

> I've truly enjoyed this thread. And while startup time is certainly
> part of the equation, I'm curious whether you also recorded memory
> overhead while you were doing your benchmarks.

No I did not. My test was a single channel executing 1,000 AGIs one after 
the other.

> In my personal observation of 'Perl running in production', there's a
> significant memory complexity associated with running lots of
> simultaneous Perl interpreters. I'm guessing the PHP overhead is
> smaller but still a factor.

I tend to agree. Just the simple change of statically linking the C AGI 
reduced it's execution time from 16 to 6. That was for an AGI that didn't 
do anything useful, but imagine if every executable in your distribution 
was statically linked. (Check out http://sta.li/) Would the system be 
noticeably more responsive? Every command line you type creates a new 
process -- maybe a bunch. When I first started programming on Unix, I 
thought it was hot stuff to code several commands into the PROMPT_COMMAND 
environment variable. Every time I pressed <ENTER> all those commands had 
to be evaluated.

> Along with the narrowing gap you saw by 'throwing hardware at the
> problem' that shrinks the difference between C and interpreted
> languages, I personally now work with a production asterisk
> environment where systems have dozens of GB of ram. As such, it's not
> entirely crazy to say 'so what' about the whole thing.

Certainly it is 'cheaper' to throw hardware instead of labor in most 
situations, but once you 'know' one way of coding is more efficient than 
another, it helps you make better implementation decisions.

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