Re: [reSIProcate-users] Resiprocate design
In my experience with heavily loaded servers the biggest load is in
the transaction processing and not the transports. We found that
running the transports on separate threads had a negligible
improvement in performance even on SMP machines.
A few notes:
- If you are doing SIGCOMP, this is not the case. It may make sense to
move the sigcomp processing to be in a thread pool.
- If you are doing lots of TCP connections, the current open source
implementation is not efficient at all and will not scale without
design changes.
- The current design of the transaction state machine will make it
very difficult to process transactions in separate threads. It would
require a major overhaul.
Hope this helps.
Jason
On Jan 31, 2008 9:30 AM, Scott Godin <slgodin@xxxxxxxxxxxx> wrote:
> 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/
>
> _______________________________________________
> resiprocate-users mailing list
> resiprocate-users@xxxxxxxxxxxxxxx
> List Archive: http://list.resiprocate.org/archive/resiprocate-users/
>