[asterisk-users] Concurrent calls including mysql taking lot of time for execution

[Steve Edwards]

On Wed, 21 Oct 2009, das sandesh wrote:

> I am using only asterisk code (dial plan) in extensions.conf which also 
> includes connection to the database: like exten =>nxxxxxxxx,1, 
> MYSQL(connect connid <ipaddr> uname pwd database) and then the required 
> select queries and the clear and Disconnect the connection.

I'm not a big fan of doing anything performance sensitive in scripting 
languages.

I'm also not a big fan of doing MySQL in dialplan. I think it makes for a 
very ugly and difficult to maintain dialplan. Since there is no 
substantial syntax checking, every time you edit your dialplan you risk 
"fat-fingering" something that you (or somebody less "skilled" than you) 
may not notice and may take considerable effort to debug.

> When the live calls are made to test and at 200th or at around 250th 
> call there is a point where it took like 5-10 sec just to connect to the 
> database and in the mean time we get dead air for that period of 
> time......how can we change the type of connection that you mentioned?

Since I don't do MySQL in dialplan, I may be wrong here, but in C all you 
have to do is change the host (or IP address) to "localhost."

I'd take a look at using AGIs written in C. They make nice little building 
blocks. They execute very quickly and can cleanup your dialplan. Here's 
how I broke down part of a recent project:

) block-ani -- lookup the caller's ANI in the database and set STATUS (a 
channel variable) to BLOCK, PASS, FAILURE.

) lookup-dnis -- lookup the dialed number in the database and set a bunch 
of channel variables from the database. My current project sets around 350 
variables in the blink of an eye -- at least less than a second. Sets 
STATUS to SUCCESS or FAILURE.

) auth-card -- creates a thread to play "Please hold while your card is 
being verified..." while the mainline code checks to see if the credit 
card is in a known bad database and issues an authorization request via 
TCP to the card processor. Usually we get the response before the prompt 
completes playing so it appears instantaneous to the caller. Sets STATUS 
to SUCCESS or FAILURE.

) messages -- kind of like a voicemail system where callers can record 
messages for other callers and listen to messages left for them. Lots of 
database activity.

) most-idle-agent -- find the online agent who has been idle the longest 
and has the skills (from the database) needed for the caller. Sets AGENT 
(a channel variable) to the agent's ID or GROUP.

) settle-card -- called when the caller hangs up, rates the call based on 
how much time they spent in each product and issues the card sale request.

Most of these could have been done in the dialplan, but it would have been 
completely un-maintainable and prone to failure.

> Or might be is it good to go with dual quad core processor instead of 
> just one inorder to handle the call capacity as well as connections?

I'm not a big fan of throwing hardware at something that may be easy to 
fix. What will you do if your business doubles?

You mentioned 400-500 simultaneous calls. You may want to re-think your 
architecture to split that across several hosts. I'd rather tell my client 
a host smoked and only took 100 calls with it -- each call in the above 
project is worth about US$30.

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