Re: [reSIProcate-users] Resiprocate design
A while back a separate thread per transport was implemented. But this
implementation was not used much, and thus was not maintained. Due to
this, it was deprecated a while back. If I remember correctly, the main
thought at the time was that the application and the stack would require
a similar amount of load, and that threading out the transports did not
provide much benefit. However I suspect this assumption may not longer
be the case with today's quad-core cpu's.
Scott
> -----Original Message-----
> From: resiprocate-users-bounces@xxxxxxxxxxxxxxx [mailto:resiprocate-
> users-bounces@xxxxxxxxxxxxxxx] On Behalf Of Neil
> Sent: Thursday, January 31, 2008 5:24 AM
> To: resiprocate-users@xxxxxxxxxxxxxxx
> Subject: [reSIProcate-users] Resiprocate design
>
> Hi,
>
> I had a question regarding the design of Resiprocate.
>
> We are using the resiprocate stack in our Server product. What we
> notice is that in load
>
> scenarios of 20000+ users, the cpu usage of resiprocate goes up very
> significantly.
>
>
> I feel the Stackthread to be the bottleneck, since that thread is
> doing a lot of operations
>
> - handling transport(which is heavy in server products), sigcomp
> processing(we are using
>
> sigcomp) and transaction layer processing.
>
> Do you think it'l be a good idea to have a separate transport thread
> to do the transport
>
> layers operations, and let the stack thread do the sigcomp and other
> stack related
>
> operations?
>
> Thanks
> _______________________________________________
> resiprocate-users mailing list
> resiprocate-users@xxxxxxxxxxxxxxx
> List Archive: http://list.resiprocate.org/archive/resiprocate-users/