Re: kqueue, multithreading and architecture
Re: kqueue, multithreading and architecture
- Subject: Re: kqueue, multithreading and architecture
- From: Chris Newman <email@hidden>
- Date: Wed, 14 Nov 2007 14:36:06 -0800
I've worked on pure event driven, thread-per-connection, and thread-pool server
designs (what you describe is one approach to the latter).
In general, I would recommend using a thread-per-connection design for servers
unless you need a _very_ large number of simultaneous open connections. While
thread-pool designs are in theory more scalable (particularly due to the
reduced per-thread stack space), it turns to to be very complex to tune them
and unless you plan a lot of time for real-world-style load testing tuning, you
may end up with code that is much more complex than thread-per-connection and
doesn't perform any better. The changes in CPU design these days (where there
are more cores, but shared caches at various levels) actually make the tuning
problem for thread-pool designs significantly more complex. A given connection
context needs affinity to a cache in order to get the best performance, and
while a simple thread-per-connection design will get that largely for free from
a good server OS, it's a highly non-trivial problem for a thread-pool-design.
To top things off, bugs in thread-pool server code are much harder to track
down as stack traces become much less useful -- you need to build your own
equivalent of a stack trace facility into your connection context dispatch
facility if you want to be able to turn around sustaining fixes quickly.
- Chris
Marco Bambini wrote on 11/9/07 10:35 +0100:
Hi guys,
I am writing a network server that should also be both high performance and
scalable, the architecture I decided to adopt is a threaded pool with a
kqueue queue for each thread.
Each kqueue will receive read notifications for the various connected sockets
and then it will be responsible to do the required job.
The idea was to have Thread1 blocked in a "listen" loop and each time a new
socket connects, Thread1 pass that socket to the kqueue in Thread2.
Thread2 is simply blocked waiting for socket events (or busy doing other
operations).
My question is if that could be a good solution and if I can safely add an
event to a kqueue queue owned and created by another thread.
Please note that I simplified the solution, because in my case Thread1 could
also decided to pass the newly connected socket to Thread3 or Thread4.
Please note that I don't want to use the listing socket inside the kqueue
owned by the working threads because much of the time they will be busy
trying to build a proper reply for an already connected socket.
Any suggestion on how to improve that architecture is more than welcomed.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden