Why so many threads per JVM?
--
You received this message because you are subscribed to the Google Groups "Hazelcast" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hazelcast+...@googlegroups.com.
To post to this group, send email to haze...@googlegroups.com.
Visit this group at http://groups.google.com/group/hazelcast.
To view this discussion on the web visit https://groups.google.com/d/msgid/hazelcast/1f71938e-a471-4844-8e13-1cedd4cbb792%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
I'd start with 1 per CPU and then test from there. Each thread has overhead - 500 is a lot.
N
To view this discussion on the web visit https://groups.google.com/d/msgid/hazelcast/d636e16c-a986-45f0-b791-286fb912ea3d%40googlegroups.com.
It certainly looks like Hazelcast communication. As a general guideline, just increasing threads often doesn't translate into increased throughput - often it decreases it (due to increased context switching). While you can make educated/informed guesses on the number (one thread per core is a good starting point) the optimal figure for your application can only be found through load testing a known revision on known hardware. Code changes, jdk changes and hardware changes all have big impacts on multi thread app performance. This implies a new round of load/performance testing ideally at every single build and every time hardware changes. Don't overlook environmental factors, especially with networked apps.
What's your goal here (puts per second)?
Are you using distributed/XA transactions?
What's your network speed / connectivity?
What's your HZ map config?
What are the machine specs for each node?
What JVM are you using?
How big are the objects you are putting in the map?
To view this discussion on the web visit https://groups.google.com/d/msgid/hazelcast/2dcf693a-9d03-415c-8d5a-852629461aa0%40googlegroups.com.