[zeromq-dev] Middleware du jour

Steven McCoy steven.mccoy at miru.hk
Mon Jul 11 17:14:52 CEST 2011


On 11 July 2011 09:28, Len Holgate <len.holgate at jetbyte.com> wrote:

> Steven McCoy <steven.mccoy <at> miru.hk> writes:
>
> > It is unfortunately not so good, along with the authors spelling.  Not
> quite as
> > bad as http://www.serverframework.com though.  Both follow the pattern
> of
> > including IOCP as a buzzword and not as a solution to a performance
> problem.
>
> So, Steven, what is it exactly that you think I'm doing wrong with
> http://www.serverframework.com and why don't you think it's a solution to
> a
> performance problem?
>
> I've been working with IOCP clients and servers for over 10 years and,
> well, it's
> been proving solutions to performance problems to me and my clients so I'm
> not
> quite sure what to make of your comments.
>

Hi Len, performance messaging exists at different performance levels and it
is common to witness that levels below are unaware of those above or
document the different advantages and disadvantages each provides.  One
example is XMPP, you can still find the discussion in some of the Jabber
mailing lists.  The XMPP developers have been studious with their
architecture and laud it as the fastest possible system.  Unfortunately
architecture alone does not make a system and there are fundamental truths
in implementation that cannot be ignored.

XMPP is a proven technology and you can find it behind Jabber, Google Talk,
and even gaming as the messaging middleware behind Id Software's Quake Live.
 However this does not assert any provenance for very high speed messaging
such as found in market data distribution systems.

Now lets look at IOCP, everyone tends to agree that the design is more
expedient than BSD sockets but Microsoft's deployment of the technology has
been two steps forward, three steps back.  The decision has been taken with
Windows NT to implement a new API that is both faster than the BSD sockets
API but also provides platform lock in with non-portability.  However above
that the BSD socket API could have been made a lot faster, you can see this
with Vista's Winsock Kernel API.  There is now a surfeit of APIs but only
sufficient testing and documentation of said process can lead to the optimum
solution.

A primary example on the Windows platform is WSAPoll, Microsoft have
documented in their blogs that this is a compatibility API to ease
transition of Unix applications using the POSIX poll API but have also
stated it is actually slower than their select API.

A common example with messaging systems is handling of IO scatter / gather,
it has been shown and can easily be reproduced that scatter / gather is
simply inefficient unless you are using large buffers.  0mq follows through
on this with the concept of Very Small Messages (VSMs).  The break even
point is around 9KB, i.e. above the cost of the kernel locking two user
pages in order to copy the buffers to the socket buffers.  Yet there are
many projects who have only taken the high level architecture viewpoint and
considered this an absolute truth and implemented it everywhere.  An
interesting example of such is the Lightweight Communications
and Marshaling (lcm) project use in the MIT DARPA Urban Challenge.

I've been breaking servers with over 20 years of code and across 30 terrible
platforms.  The only proven method for getting things right is by repeatedly
getting things wrong.

I'd like to see a more portable ServerFramework but more important would be
a complete suite of performance tests and comparisons between available
options.  The actual figures tend to be irrelevant, it is the relative
differences between each sampling that is of interest.  I also realize for
most users the present implementation is fast enough and correctness is of
higher regard for which I am impressed with the attention given.

-- 
Steve-o
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110711/564f121f/attachment.htm>


More information about the zeromq-dev mailing list