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

Sat Feb 7 14:25:30 CST 2009

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 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 that a portion of the sharing mechanism inside Asterisk's ODBC
technology is keeping a lock longer than necessary. 

-----Original Message-----
From: asterisk-dev-bounces at lists.digium.com
[mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Sebastian
Sent: Saturday, February 07, 2009 12:15 PM
To: 'Asterisk Developers Mailing List'
Subject: Re: [asterisk-dev] 1.4 and CDRs -- The Breaking Point

So have you test it?? The performance was improved??

If it was improved, the issue is the driver and not func_odbc right?

-----Original Message-----
From: asterisk-dev-bounces at lists.digium.com
[mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Venefax
Sent: sábado, 07 de febrero de 2009 02:50 p.m.
To: 'Asterisk Developers Mailing List'
Subject: Re: [asterisk-dev] 1.4 and CDRs -- The Breaking Point

There is certainly a "paid" version, extremely expensive, $1500 per box. If
you use virtual machines, exclusively, like I do, it would cost you a
fortune, I mean, literally. I explained the fact that in the US we are fully
virtualized and we use hundreds of virtual machines in cluster of big
servers, a cloud, instead of a big physical box, but the manufacturer in
London wanted $1500 per virtual machine and I had to stop using them, after
buying one copy. They are clearly still living in the 20th century. England
is still a place with a queen. I argued for a change on the licensing model,
but they would not follow any clues. You are welcome to contact them.
http://www.easysoft.com/products/data_access/index.html?gclid=CNTild_uypgCFQ
pgswodQB0W1Q

-----Original Message-----
From: asterisk-dev-bounces at lists.digium.com
[mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Sebastian
Sent: Saturday, February 07, 2009 11:32 AM
To: 'Asterisk Developers Mailing List'
Subject: Re: [asterisk-dev] 1.4 and CDRs -- The Breaking Point

Is there any other MSSQL driver to compare the results?

-----Original Message-----
From: asterisk-dev-bounces at lists.digium.com
[mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Tilghman Lesher
Sent: sábado, 07 de febrero de 2009 01:32 p.m.
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] 1.4 and CDRs -- The Breaking Point

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

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

__________ Information from ESET Smart Security, version of virus signature
database 3834 (20090206) __________

The message was checked by ESET Smart Security.

http://www.eset.com

__________ Information from ESET Smart Security, version of virus signature
database 3834 (20090206) __________

The message was checked by ESET Smart Security.

http://www.eset.com

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

__________ Information from ESET Smart Security, version of virus signature
database 3834 (20090206) __________

The message was checked by ESET Smart Security.

http://www.eset.com

__________ Information from ESET Smart Security, version of virus signature
database 3834 (20090206) __________

The message was checked by ESET Smart Security.

http://www.eset.com

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev