[asterisk-dev] 1.4 and CDRs -- The Breaking Point

Tilghman Lesher tilghman at mail.jeffandtilghman.com
Sat Feb 7 09:32:13 CST 2009


On Saturday 07 February 2009 04:40:32 Venefax wrote:
> Your statement about Freetds is untrue. I hired Frediano Ziglio of the
> Freetds team to work with Murphy and he did not find any problem by tracing
> the driver.

You also hired Digium to trace the problem, and we couldn't find a single
problem with our stack, either.

> Furthermore, it can be proven that Freetds works fine since I 
> use AGI and Perl to the same job that slows Asterisk to a halt.

That's not the same job.  By your own admission, it opens and closes the
database connection for every single job and runs each query in a completely
separate process.  That's quite a bit different from sharing resources and
running many queries on the same connection.

> There is 
> like a bottleneck in Asterisk. When the amount of calls to a func_odbc
> driver goes above 10-15 per second, the rate of calls to the database
> versus calls to func_odbc starts dropping dramatically.

Except that it doesn't, when you use a backend like MySQL.  It's only when you
use the FreeTDS backend that it slows down.

> I call that 
> constipation. Please ask Steve Murphy about the case.

I actually worked closely with Steve Murphy on this case, and I'm fully aware
of the testing done.

> The only way to make 
> it work is to call a Perl script that opens and closes a connection to the
> database for each call, which is absolutely inefficient and makes me use a
> very expensive SQL machine. The mechanism to share the connections to SQL,
> called "pooling", is flawed. Just picture it this way: Asterisk cannot
> handle more than 20 queries per second to the database using func_odbc,
> while I can get to 100+ calls per second using AGI and Perl. I have not
> reached yet any upper limit using Perl.

Right, but you're using a completely different methodology that relies on
hundreds of different engines running concurrently, as opposed to running
hundreds of different instances on the same engine.

> I think that we need to redesign 
> the entire ODBC technology from scratch.

You are certainly welcome to redesign it and contribute your new design back
to the community.  Many others, who are not using FreeTDS, have no problem
using func_odbc.

-- 
Tilghman



More information about the asterisk-dev mailing list