Hi, I am not sure session thread pool enabled by default is such a good idea.
For most applications where media processing is enabled the maximum call (and thus thread-) count is not that high that one could not spend one (mostly sleeping) thread per call. But if blocking operations like e.g. DB access is used, thread pool can possibly harm performance.
Thread pool is really only to be recommended for high volume signaling only B2BUA / SBC applications.
Stefan o Raphael Coeffic on 03/20/2011 02:11 AM:
Module: sems Branch: master Commit: ef85d6eae880f6771f20a3407248099d7752d6ce URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sems/?a=commit;h=ef85d6eae880f6771f20a3407248099d7752d6ce Author: Raphael Coeffic<[email protected]> Committer: Raphael Coeffic<[email protected]> Date: Wed Mar 16 14:23:50 2011 +0100 session thread pool enabled by default --- Makefile.defs | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile.defs b/Makefile.defs index f3f3ff5..e79c687 100644 --- a/Makefile.defs +++ b/Makefile.defs @@ -50,7 +50,7 @@ CPPFLAGS += -D_DEBUG \ # if compiled without thread pool support, every # session will have its own thread. # -#USE_THREADPOOL = yes +USE_THREADPOOL = yes # compile with spandsp DTMF detection? see soft-switch.org # this needs a fairly new version of spandsp - tested with 0.0.4pre11 _______________________________________________ Semsdev mailing list [email protected] http://lists.iptel.org/mailman/listinfo/semsdev
_______________________________________________ Semsdev mailing list [email protected] http://lists.iptel.org/mailman/listinfo/semsdev
