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

[Venefax]

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