Hazelcast client pool and performance

[Bhavesh Jain]

Hi,

While going through below white paper which compares hazelcast with Redis.

https://www2.hazelcast.com/hazelcast-vs-redis-cache

I see that as throughput increases with number of clients.

I would like to ask , Is it correct to say that we can do pooling of hazelcast clients

during heavy load to get better throughput?

[Tom OConnell]

Hi -

Before you start application tuning, be sure to look at the system TCP properties. Keep in mind, that the network connections are all TCP/IP and there are many references for network tuning for Linux and Windows. High throughput applications will benefit from this. Keep in mind that socket tuning parameters should be applied to the clients and servers.

After that, you should look into serialization, async operations, and pipelining. Serialization will determine the size of the data that goes over the wire and the CPU cost of converting it. It’s generally advantageous to take advantage of the async abilities of the server to dramatically increase your throughput without hurting latency. You should look at backpressure, to ensure that the server is not overloaded with async requests.

After that, take a look at the client system properties. The link you have refers to the Java client and this is highly tunable.

There is no out-of-the-box client connection pooling - our approach would be to size your client fleet to your requirements. The Hazelcast client instance is a Java object and while you could certainly open multiple connections in your client app, you probably shouldn’t.

The likely place to start for tuning I/O intensive client applications would be the IO threading - there are hazelcast.client.io.input.thread.count and hazelcast.client.io.output.thread.count properties to control this. These default to “-1”, which means that the system will select thread counts – overriding with positive integers you can control the number of threads used for input and output. If your application has unusual requirements, you may want to try setting the IO thread pool sizes with these.

The hazelcast.client.io.write.through property allows the client code to bypass the IO threads and write to the cluster without a context switch to the other thread pool.

The hazelcast.client.response.thread.count property is an interesting one; it allows response handling (i.e. things returned from the cluster) to be performed on the IO threads (input threads). This is something that requires testing it can be a significant performance boost, but only under certain circumstances. It could also hurt performance. If testing this, consider testing in conjunction with the hazelcast.client.io.input.thread.count, to allocate more threads.

 Let me know if you run into challenges with application throughput - you should be able to scale Hazelcast clients for any load you need.

Cheers

Tom

[Bhavesh Jain]

Thanks Tom for your valuable suggestions !!

I will try with suggested options to improve through put.