Thursday, June 21, 2012

RPC (Remote Procedure Call) with Hazelcast

Despite the fact that Hazelcast is a data distribution (particularly, peer-to-peer) platform for Java, its group communication mechanics can be utilized for remote procedure calls in a similar fashion to JGroups remote procedure calls. Further, to ease this workflow, Hazelcast provides distributed executor service to execute Callable and Runnable instances on the remote cluster members. Now, let's glue things together for making remote procedure calls on Hazelcast cluster members.

Assuming that you have some familiarity with executor services, check out below SimpleRPC class, which makes use of the Hazelcast executor service to invoke a Call instance on every cluster member.

Since SimpleRPC is a singleton, whose instance is accessible via its getInstance() method, foreign classes can easily invoke its callMe() instance method. Now let's implement the Call class, which is anticipated to encapsulate the necessary mechanics to make a call to SimpleRPC.getInstance().callMe() on each cluster member.

Simple, eh?

Monday, June 4, 2012

Performance of Linux IP Aliased Network Interfaces: Lessons Learnt

In an earlier post, I had put together a set of benchmarks to measure the performance of IP aliased network interfaces in Linux. While I was expecting a performance degredation due to IP aliasing related book keeping at the kernel level, suprisingly results were pointing out that the overall network throughput measured over the used physical interface increases proportional to the number of aliased interfaces. In this post, I will re-investigate the subject with the lessons I learnt from my previous try.

To begin with, I want to address Chris Siebenmann's concerns regarding the raw performance of the used network interface card. For this purpose, I first replaced the NIC with a real one (RTL8111/8168B) that is capable of achieving gigabit rates. Then, I started playing with iperf parameters. After a couple of tries, I figured out that the game changer is TCP MSS (maximum segment size) for me. Setting MSS to 1448 helped me to boost my speed to gigabit rates. Other configurations (e.g., disabling TCP delays, i.e., Nagle's algorithm) did not change the results that much, but I present them hereby anyway.

New results are as follows. (Each pass is set to run for 60 seconds.)

#tcpnodelay
1920,462921,261
2921,468921,184
4921,311921,179
8920,909920,832
16920,679920,629
32920,770920,732
64922,861921,521
96926,282925,444
128969,967945,879
160949,506949,204
192952,449953,509
224986,355973,846
254990,832993,143

Ok, the results are cool. But how do we explain them? For this purpose, by finding his name from Wikipedia IP aliasing page, I got in touch with Juan José Ciarlante ‐ the author of first IP aliasing support in Linux kernel in 1995 ‐ and he kindly replied my questions. Below, I directly quote from his own words.

you may be "just" exploiting the fact that you're using more TCP connections (==N_WORKERS) as number of aliases increases, and thus increasing the "parallelism of your transferring pipes", much in a way p2p networks do (spread the downloading between zillion of connections), suggest reading about TCP congestion window control semantics.

Finally, we have a valid answer!