[zeromq-dev] Too much ZeroMQ overhead versus plain TCP Java NIO Epoll (with measurements)

Bennie Kloosteman bklooste at gmail.com
Thu Aug 30 05:19:59 CEST 2012

On Thu, Aug 30, 2012 at 10:35 AM, Julie Anderson <
julie.anderson.uk at gmail.com> wrote:

> See my comments below:
>> They appear to
>> be single threaded synchronous tests which seems very unlike the kinds
>> of applications being discussed (esp. if you're using NIO). More
>> realistic is a network connection getting slammed with lots of
>> concurrent sends and recvs....which is where lots of mistakes can be
>> made if you roll your own.
> That's the point of NIO, which attracted me from the very beginning. Of
> course it is not the solution for everything but for fast clients you can
> SERIALIZE them inside a SINGLE thread so all reads and writes from all of
> them are non-blocking and thread-safe. This is not just faster (debatable,
> but specifically for fast and not too many clients) but most importantly
> easier to code, optimize and keep it clean/bug free. Anyone who has done
> serious multithreading programming in C or even Java knows it is not easy
> to get it right and context-switches + blocking is the root of all latency
> and bugs.

If you cant handle state that is true.. but if each thread has its own
state or caches state than you don't have to deal with it .  if you want
scalable high performance  you want asynch  , many threads. Putting them
all on one thread will eventually give you grief  either capacity or you
will hit some slow work and then  forced to off load stuff on threads and
that's where the bugs come as it was not your design .  Good async designs
which minimize state have few bugs , web servers are a great example .

re " context-switches + blocking is the root of all latency and bugs. "

.    Context switches are less of an issue these days due to  processor
improvements and especially when you have more cores than active threads.
Use your cores , in 4 years you will have 100 thread standard servers and
your using one . Blocking is an issue but putting it one thread is IMHO
more risky  for a complex / high performance app .
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120830/cde4c0ea/attachment.htm>

More information about the zeromq-dev mailing list