Dne 6.6.2016 v 17:42 Joshua Colp napsal(a):
Happy Monday all,
Since I sent my previous email a lot has been learnt about our
UnixODBC problem and a path has emerged ensuring both better
performance while
making sure people are not required to upgrade their UnixODBC unless
they want to.
So what's this mean?
As of Asterisk 13.10.0 our own connection pool will be used in the
res_odbc module. Under testing this has shown to be more performant
than the UnixODBC implementation and also does not suffer the slowdown
present in UnixODBC 2.3.3 and above. As well since our own connection
pool has a fixed size we can restore behavior to that of previous
versions so those using UnixODBC 2.3.1 will not experience the crashes
that have been seen.
This is done by having the default be 1 connection, thus disabling
connection pooling. To turn connection pooling on you will need to
ensure you are using UnixODBC 2.3.2 or above with latest database
connectors and configure a maximum limit on concurrent connections in
res_odbc.conf. To facilitate figuring out the right limit for your
environment I've made the current count and limit available using the
"odbc show" CLI command.
This change is up for review[1] and any feedback would be welcome,
both from code review itself and testing.
Cheers,
[1] https://gerrit.asterisk.org/#/c/2943/
whats the recommended settings in odbcinst.ini
Pooling = no
threading = 0
?
do you think it is possible backport this to 13.9 or are there some
problematic dependencies?
--
---------------------------------------
Marek Cervenka
=======================================
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
