Re: [reSIProcate] resiprocate stack the performance using TCP or TLS?

[Ryan Kereliuk <ryker@xxxxxxxxx>]

I think you're correct about this.  Jasomi had to implement epoll in
its version of resiprocate in order to cope with scalability issues
for a b2bua servicing a massive number of connections (unfortunately
the patch was against an old version of resiprocate which made it too
difficult to contribute back).  In any event, as record-routing repro
deployments start to scale up, this will be very useful.  It would also
be nice to use /dev/poll to get scalability on Solaris too.

Thanks,
-Ryan

On 2007-03-29 at 10h59, Yuan, Frank wrote:
> 
> I find that the latest release of reciprocate still uses select()
> instead of poll() or epoll().
> 
> Func select( )  works very well if the total socket handles are less
> than 1024 and is fine for UDP, but is not scalable on TCP or TLS. Func
> poll() or epoll does not have this problem.
> 
> Does any one know the benchmark of reciprocate stack with TCP or TLS?
> 
> Should poll() or epoll() be implemented in the future release and has an
> option to use either select(), poll() /epoll()?