Can i access embedded into application cluster using client?

[Shimon Cherny]

Hello,

Currently we are deploying hazelcast as embedded at our application but we usually as we scale we encounter issues with cluster rebalancing that under load causes a high CPUs.

I have been thinking to switch to client server architecture but the problem is we have also on-premise installation i don't want really cause customers to install  separate hazelcast cluster on one hand an on the other hand to multiply my testing matrix by testing embedded vs client server.

Is it possible to use hybrid architecture meaning to switch to client-server but in some cases launch it also as embedded and connect to embedded cluster using client instance?

Thanks,

Shimon

[Neil Stevenson]

Yes, this is possible, with three caveats.

Firstly, the reason to change - rebalancing is mainly a network heavy operation, moving data about. The CPUs shouldn't be stressed, the network could be since you want to rebalance as fast as the network will allow. It could be worthwhile to investigate this more.

Secondly, the application code gets a `HazelcastInstance` and mostly can call the API without caring if the instance is a client instance or a server instance. There are some things, such as security, that necessarily differ. And there are some things, like read-from-backup, where you can optimize if you know whether it's a client or a server.

Finally, be sure if you go with the hybrid approach that all Hazelcast servers get an equal load. All instances of your app that has embedded Hazelcast should be handling work, or none of them. 

[Shimon Cherny]

Thank you for the answer.

Any tips how to achieve the last point of equal load distribution in case of embedded mode?

[Neil Stevenson]

> Any tips how to achieve the last point of equal load distribution in case of embedded mode?

 The default set-up is intended to deal with most cases, so you should get a fairly even workload.

 Facets of your data and data access might stop this occurring, so it's worth watching out for.

 Imagine you have 1,000,000 data records, a target of 10,000 transactions/second and a 3-node Hazelcast cluster.

 Each Hazelcast node should be hosting about 1/3 of the data records.

 If we assume (a) that each incoming transaction is for a different data record then those requests will spread across the 3 Hazelcast nodes equally. Request for key "1" goes to node 1, request for key "2" goes to node 2, etc.

 If we assume (b) that each incoming transaction needs the same amount of work, then we are evenly spreading work requests of equal weight.

 (a) and (b) won't be true. What matters is how far from true.

Neil

[Neil Stevenson]

Note ---->>  *should* !!!

If your application is an online shop, and everyone wants to buy the same thing, that data record will get more access.