AGI C vs Perl addon

Hello all,

I am implementing Asterisk in a production environment to handle incoming calls only. The system will be required to handle high call volume with each call approximately less than 1 minute.

For this solution, I require some manipulation of data within a mysql DB and some advanced logic processing. My question is in regards to performance optimization.

Would AGI calls to external C apps (using the MySQL C API) be more efficient as C is compiled and presumably much faster than scripting languages with low overhead, or would it be easier and possibly faster to eliminate AGI calls by using the so-called Perl addon for built-in interpretation?

If anyone has deployed such a system with these considerations, please let me know your recommendations.

Once your lines are picked up, the scripting engine or whatever you use are not going to be a bottleneck.
Think about it: 120 lines, call time 60 seconds. That is 2 call connects per second , and i assume you need to execute something at call start and call end.
That sums up to 4 scriptcalls per second.
What modern webserver would stop picking its nose for that?
I think you do not need to worry much.

just my 0.05 euro.

Hmm, I see your analysis… and it’s very true :smile:

Now, suppose I am a performance freak. What would be the optimum method to implement such external logic and DB interaction?
Im just wondering in case I ever scale larger or make any changes - might as well build the foundation on something solid, right?

I may just run some tests to get to the bottom of this :wink:

Also, im planning to use G.726 will that only support 120 concurrents?

Well if you are a true freak i guess writing your application directly in C (or even ASM lol) would be a performance gain, but also much, much more work.
AGI communicates entirely through the standard pipes (stdin stdout stderr) so writing an application in , well, anything that can handle that, is not going to be impossible.
But with the speed of modern computers and the unlikelyhood of the speed of your server going down much even i realy dont see the sense in it.
I mean if you abide to some simple rules:

  • dont run your database on the same server
  • dont run your main website on the same server, nor use the same database for it
  • if you need to expand the amount of lines first check if it is a good idea, if not just use a second server
    The you are safe.

Being a PHP addict i am using it now and the speed is good.
Less then a millisecond for some task including some file inclusions and a lot of logging… your database connection is going to be more important.

Interesting, this has been very helpful
Yes all of my AGI work so far has been in PHP - it’s a greal language IMO
I’ll keep the database advice in mind

Ill be sure to report here any information I discover from my experimentations

it is wrong
if you want better performance, you must not use AGI, but write an application(like app_dial) to handle it. or use internal ivr system(see app_ivr example in sources)

[quote=“meral82”]it is wrong
if you want better performance, you must not use AGI, but write an application(like app_dial) to handle it. or use internal ivr system(see app_ivr example in sources)[/quote]

after discussing performance here - I was thinking about this…
writing custom applications in C to be loaded into Asterisk and used in the dialplan - yes this would be most optimal and practical

Ive looked over app_ivr briefly, it’s great for superior performance in a production environment - interfacing custom Asterisk applications with the MySQL C API would be perfect


Is there away for an AGI (PHP or PERL) script to stay resident in the server memory? I have asked this question because if the AGI requires to query to a database which is geographically miles apart. It means every call it will handles requires a connect statement before the actual query. Whereas, in most C applications with database requirement, they maintain a single connection for the whole time the asterisk is running. This single connection will serve all call threads, it means we have to lock and unlock the database connection. Is there a better way to have threaded also.