I tried both ways to connect to DB from Asterisk via AGI/fastAGI and function ODBC but I am curious which is best and fast way?
There are so many ways
- dial-plan
- shell script
- any language(C, java, node-js, …)
It depends on you!
That’s correct but which approach is the best one when the resource and performance is the major concern?
AGI forks the process which takes time and incurs a penalty. Depending on the system it can even result in audio issues in some cases[1].
FastAGI won’t fork the process, but does require setting up a TCP connection and running another process. It’s better than AGI.
func_odbc runs inside of Asterisk, it’s likely the most performant option.
[1] https://www.freepbx.org/performance-improvements-in-freepbx/
2 Likes
This is not an easy question to answer for you.
I’ve been writing Asterisk applications for 17 years, and the best advice I can give is to choose the path that allows YOU to be most performant.
The design of your application may have a greater impact on performance than the efficiency of a database access method.
My bias is strongly towards writing AGIs in compiled languages. For me, that meant C because I know it best. Looking back, I wish I had decided on Perl. I compare how much code it takes to accomplish a task in C with how much I can accomplish in Perl – and I’m not ‘all that and a bag of chips’ as a Perl programmer.
If, after benchmarking and actually identifying a bottleneck, I could re-write an AGI in C for higher performance. (Avoiding the ‘startup cost’ of scripting languages. You can execute a bajillion compiled AGIs in the time it takes to start a scripted AGI.)
Executing a query in ‘dialplan’ using ODBC may be enciting because you avoid the process creation overhead and it is ‘just there’ but it comes with other costs like obtuse quoting and convoluted parsing. Also, your application will be more ‘fragile,’ more difficult to debug, and more difficult to maintain. In terms of ‘lifecycle costs’ maintenance can be dominant.
Here’s some of the reasons why I lean towards AGIs in no particular order:
You can leverage your skills in ‘real’ programming languages (yes, I am biased).
You get ‘real’ syntax errors.
You get ‘real’ error messages at run time and can deal with exceptions effectively.
When you write a query in the MySQL shell, you can frequently copy it verbatim into your AGI, no funky quoting.
You can ‘syslog’ your query and paste it into the MySQL shell to help figure out what’s wrong.
You can parse the result set more efficiently.
You can execute your code in a debugger and step through it, examining and changing variables. This is huge and under appreciated. Most programmers do not know how to use a debugger, especially for an AGI.
Your dialplan will be ‘cleaner’ and easier to comprehend.
You can package a task into a single ‘black box.’ For example, I have an AGI that takes a DID as input, confirms the ANI is valid for that DID, looks up a bunch (hundreds) of values and sets these hundreds of values as separate channel variables – for every call.
You can re-use code more effectively.
I’m sure there’s more, but that’s all the time I have right now.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.