[nanomsg] mangos perf tools added / websocket improvements

From: Garrett D'Amore <garrett@xxxxxxxxxx>
To: nanomsg@xxxxxxxxxxxxx
Date: Mon, 16 Feb 2015 12:13:53 -0800
I’ve done some more changes;

1. Added a perf subdirectory.  This contains tools that are 100% compatible 
with nanomsg/perf.  You can use them to compare mangos and nanomsg — you can 
even mix and match server and client (except for inproc, of course!)

2. websocket got a bunch of improvements, mostly focused on making it easier to 
build Go webservers that serve up a nanomsg socket *and* other content — 
meaning you could serve a JavaScript page from one path, and the websocket it 
talks to on path, using the same TCP port number.   This is impossible to do 
with stock libnanomsg.  (If you’re curious about using this functionality, send 
me a message, or have a look at the ws_specific_test.go that shows at least one 
of the approaches to this.)  Btw, you could *also* use this to serve different 
mangos sockets on the same TCP port as well. :-)

Btw, I’ve become interested in the idea of someone building a vanilla SP 
implementation that speaks to the websocket transport (no need to do the 
others) in JavaScript.  This could be a very nice way to interface JavaScript 
with an SP fabric. :-)  I now view this websocket option as a *superior* 
alternative to the tcpmux work for sharing a single port.  It requires less 
crazy hackery with UNIX domain sockets or passing file descriptors (and is 
therefore more portable), and frankly is more likely to be acceptable to sites 
than running a magic service on port 1.   (Of course, the down side is that it 
only works if you are willing to live with an HTTP transport to start off the 
connection — its ill suited for connecting up random external programs like 
inetd does.)


With respect to performance, I’ve discovered some interesting things.

a. For inproc, nanomsg beats mangos on every metric.  Not too surprising, as I 
do an explicit message copy.  (This is to keep things simple.  I’ve quite 
intentionally decided against hand tuning inproc very much.)

b. For IPC and TCP, nanomsg seems to handily beat mangos in throughput tests.  
I believe this is because the mangos API (and Go in general) really don’t make 
it easy to receive into a preallocated buffer — so we wind up doing a certain 
number of allocations.  Even the cache stuff I’ve done isn’t perfect here.

c. For Latency over the same transports, (IPC and TCP/localhost), *mangos* gets 
the wind — about 2usec faster fairy consistently.  (Or, 4 usec for a round 
trip!)   This is pretty surprising to me, actually.  I don’t know why yet.

I’ve not tried the various mixing and matching, and there are all the size / 
count options that can be played with.  For folks interested in performance 
analysis, I recommend giving it a shot.  I’d be really, really interested in 
new ideas here, or if anyone is able to come up with either explanations for 
results or suggest (as a result of these tests) ways to improve things in 
*either* libnanomsg or mangos.

Anyway, enjoy.

        - Garrett
[nanomsg] mangos perf tools added / websocket improvements

Other related posts:
