Erlang/OTP R7 - speed test of new inet driver

Measurements

The messages contain all bytes of equal value, and no checking of the contents at the time of reception is done, as this would create a lot of overhead. The messages are received in passive mode.

The measurements has been done on two Sun Ultra 10 running Solaris 7, iluvatar (local) and gorbag (remote), connected with a 10 Mbit/s Ethernet. The Erlang/OTP releases were R6B-patched and R7A. There is no reason to assume that R7B should perform different from R7A.

The plots have the message size on the X-axis, and either the time or the bandwidth (bytes per second) on the Y-axis.

The code doing the measurements can be found here. It was invoked from this makefile with: make test.

Test type

• Echo test: One message at the time is sent on the socket. It is echoed at the other end, and when the message has been returned, the next message is sent.
• Flow test: Messages are sent as fast as the Erlang runtime system allows. At the receiving end the messages are just received and wasted.

Server node type

• Local: The server node, i.e the node that echoes or receives, is on the same machine as the client node, i.e the node that sends and measures the time.
• Remote: The server node is on another machine than the client node.

Number of sockets

• Single: Just one socket is tested. It has one client-server process pair at the socket ends.
• N parallel: N sockets are tested in parallel between the client and server nodes. Each socket has got a client-server process pair. The time is measured as the mean time for all sockets.

Data type

• List: The messages are lists of bytes.
• Binary: The messages are binaries.

Results

Echo tests

Note that the plots have latency on the Y-axis, so the lower the better.

The new driver is about 25% faster. This is probably because one intermediate process has been removed. The same also applies to binaries.

When the server is on a remote node, this improvement is not noticable. It probably disappears in the TCP/IP protocol overhead on the host machine.

Here the new driver is about 50% faster. In this case there are 16 intermediate processes less in the new system, so it probably has faster process scheduling. For binaries, this effect is not as pronounced, but the [16 parallel] is faster than [single].

In this case, the scheduling improvements becomes measurable (about 40%), at least for small binaries. The corresponding test for lists show the same result.

Flow tests

Note that the plots have bandwidth on the Y-axis, so the higher the better.

The new driver seems to be 2 to 3 times faster. The corresponding figure for binaries is almost 2 times.

Here the new driver is some 3 times faster for small binaries, but about 25% slower (i.e 0.75 times faster) for big ones. We find this strange. The same also applies to lists, also with a break-even at about 200 bytes.

For [flow test, 16 parallel] the results are as in the previous tests. The new driver is almost 3 times faster, but for remote tests of messages larger than 200 bytes it is some 20% slower. Weird. This plot shows [remote, list].