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

Tilghman Lesher tilghman at mail.jeffandtilghman.com
Sun Feb 8 00:26:36 CST 2009


On Saturday 07 February 2009 14:25:30 Venefax wrote:
> I did not test it. I don't think that the driver has anything to do with
> this. If you read carefully what has been written you may achieve the same
> conclusion.
> a) Freetds allows me to execute 100+ simultaneous queries to the database,
> on separate channels. Open Connection, Execute, Close Connection.
> b) Asterisk slows down to a halt in the same scenario. The difference is
> that the connections are never closed, are "pooled".

If you believe that reconnecting for every single query would make a
difference, that is a very easy change.  However, given the single-engine-
multi-instance aspect, I doubt this will have a positive effect.  But I'd be
happy to code it, if you're willing to test it.

> If you compare a) to b), there is no way to blame the driver. This
> absolutely absurd. The driver opens a connection and keeps a list of open
> connections in its internal structure. It is a black box. This black box
> does in fact work as expected, because at the same second I may have dozens
> of independent queries being processed using Perl.

I think you're revealing a fundamental lack of understanding about the
codebase.  The only way that I could see a relevant comparison is if your Perl
process was multi-threaded, running Fast AGI, and running multiple queries
without ever shutting down.  As it stands, I believe that you're running
multiple Perl instances, which means that you aren't testing FreeTDS for
concurrent queries, the way Asterisk runs.  As a result, your determination
that the driver is not at fault is sorely lacking.

> I think that a portion of the sharing mechanism inside Asterisk's ODBC
> technology is keeping a lock longer than necessary.

You're free to think whatever you like; the difference here is that the entire
codebase is open source, so all are welcome to look and determine for
themselves if any part is holding any lock for longer than necessary.  I've
reviewed the codebase multiple times, and I've found nothing to backup such a
claim.

-- 
Tilghman



More information about the asterisk-dev mailing list