Re: [reSIProcate] The Million User Dilemma
I've found that there are very effective ways of improving performance
in resiprocate through concurrency and utilizing threads at the
transport level is not a very good one. The best for the stack itself
is to thread the transaction layer. I've made an implementation that
does this by using hash based concurrency that can be found in svn.
Dan
On 01/30/2011 10:23 AM, kaiduan xie wrote:
> This is an very interesting topic, but my experience told that putting
> transport into different threads did not improve the performance at all,
> and using Google's tcmalloc memory allocator can improve the performance
> of the stack. ReSiprocate is a very good general SIP stack, but like
> Francis pointed out, it does not scale well on multi-core CPUs. As to
> the TLS, adding SSL_MODE_RELEASE_BUFFER support, we can save 34K memory
> per TLS connection (http://www.openssl.org/docs/ssl/SSL_CTX_set_mode.html)
>
> I have built an Erlang/OTP based SIP proxy with TCP/TLS/UDP transports
> support, it almost linear scales on multi-core CPU. It can support more
> than 100K TLS connections, and more than 1000 CPS. If you are
> interested, please contact me offline.
>
> Best regards,
>