[asterisk-users] Lookup ${EXTEN} in database, update context/route if found... AGI?

Steve Edwards asterisk.org at sedwards.com
Thu Jun 3 11:39:52 CDT 2010


> ----- "Doug Lytle" <support at drdos.info> wrote:

>> I use the mysql add-on, I'd create a subroutine that gets called at 
>> dial

On Thu, 3 Jun 2010, Tim Nelson wrote:

> Thank you for the example. I'm using something very similar to this now, 
> looking up the destination ${EXTEN}, and using GotoIf if the number of 
> results from the query are > 0. It seems to be working quite well.
>
> I do have a few additional questions however:
>
> -How reliable is the MYSQL application?

Very reliable. I have a MySQL server serving a couple of Asterisk servers 
that has been running for almost 1,000 days -- not a record I'm sure, just 
a single example.

> -In the event of a failed database query (load too high), what happens 
> to the call?

> -Also, what about slow queries? If a query takes a few seconds to 
> complete, does the call wait for the query to complete or are there 
> timeouts for the query that could result in dropped calls?

(I prefer to call MySQL from an AGI instead of the dialplan. I find 
"dialplan MySQL" ugly and limiting. I also don't like exposing a bunch of 
code in an environment where someone can "fat-finger" a difficult to find 
error.)

Back to your question, what ever you want to happen. If you don't code for 
the eventuality, a slow query will introduce an annoying delay in the 
execution of the call. If the delay is annoying enough, your customers 
will "drop" the call. If you have adequate resources and monitor the MySQL 
slow query log, this is a non-issue.

> -Are there any problems with concurrency? What if there are 50 
> simultaneous calls that need to perform this database lookup? Providing 
> the MySQL server is fine with that number of simultaneous queries, will 
> the MYSQL app and/or Asterisk handle it gracefully?

This is where a database really shines. Concurrency is a non-issue. 50 
calls accessing the database is peanuts. If they are executing the same 
query it's even less since MySQL can cache the query and the result set.

> -Does it make sense to open, disconnect, and clear every connection for 
> every call? Is there a way to have a persistent connection for better 
> performance?

I don't see this as an issue in this environment. This system handles 
about 300 simultaneous calls (again, not a record, just my example) with 
every call executing at least a dozen AGIs per call -- 3 AGIs before the 
caller hears "first audio." Each AGI creates a new process, a connection, 
a query or two, and a disconnection. Performance has never been an issue. 
I do write all my AGIs in C though. You can execute hundreds of AGIs 
written in C in the time (not counting "database" time) it takes to load a 
single interpreter (PHP or Perl) and parse your script.

A persistent connection for the life of a call would make sense. In my 
environment, merging several of the AGIs into a single AGI would make 
sense (from a performance standpoint), but the client is happy with the 
performance and won't spend money for no perceivable benefit.

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



More information about the asterisk-users mailing list