Performance tuning parameters

[Dinesh Kumar]

Hello,

I'm trying to identify the best possible configuration for production scenarios.

I have an IMap which stores the users logged in to our application at any point of time. This map undergoes a lot of get/put operations (1000 concurrent accesses) and size grows till 100K.

Q1. What are all the tuning parameters in hazelcast that I should be focusing on and what should be their ideal values ?

More Info : Currently I have the following configuration. I need to know if I can tune the performance further, as get() currently takes around [average] 250ms (there is no serialization hit, I verified it by replacing (BINARY + get()/put() APIs ) with (OBJECT type + operating on objects using EntryProcessor).).

        <property name="hazelcast.operation.generic.thread.count">1000</property>
        <property name="hazelcast.operation.thread.count">1400</property>
        <property name="hazelcast.io.thread.count">700</property>
        <property name="hazelcast.partition.count">1001</property>
        <property name="hazelcast.event.thread.count">700</property>
        <property name="hazelcast.client.event.thread.count">700</property>

Q2. Is there a way to set initial capacity, like Concurrent Hash Map ?

Q3. As a different question, is there any sizing guide available for hazelcast ?

Thanks,
Dinesh

[Peter Veentjer]

don't use 1400 partition threads and 1000 operation threads and 700 io threads Such huge number of threads is only going to cause problems. Please remove these threads settings and go back to the defaults.

250ms is very very high; especially as average! How big are your key/values? And what kind of hardware are you running on? In simple map.get tests we can easily do far below 1ms avg.

--
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/CAEgipTAMr5kskhnVXZQpU9ROVKBNs9TbqjPh-qcw3ejXxjOC3A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Dinesh Kumar]

Hi Peter,

Sorry for the delayed reply. I was waiting to hear from the IT / hardware folks. Apparently the processor turned out to be faulty and hence tests went haywire. They've fixed it and things are in control now. Thanks for your input.

Q1. Could you please point me to any performance / sizing guide of hazelcast, if available.

- dinesh

To view this discussion on the web visit https://groups.google.com/d/msgid/hazelcast/CAGuAWdDh%2B7gLi6SJ-YWiN6DSsijODDCtQuKj63EEi6%3D8UE9dvA%40mail.gmail.com.

[Peter Veentjer]

Hi Dinest,

we currently don't have a guide available. But what I have seen so far, and we do a lot of benchmarking and trying to squeeze more performance out of hazelcast, that the thread related stuff works very good with default settings on reasonable hardware (so not some kind of micro virtualized os)

To view this discussion on the web visit https://groups.google.com/d/msgid/hazelcast/CAEgipTAW3zjSXAshgO6pw49BquqjGf_oSra7HEpyF9GbYf%2BgMg%40mail.gmail.com.

[Dinesh Kumar]

OK. I'm currently working / evaluating with default generic op and partition op threads (2 * num cores). Except the classloader issue ( which I've posted in a different email), everything looks good now.

Thanks a lot for the support.

-dinesh

To view this discussion on the web visit https://groups.google.com/d/msgid/hazelcast/CAGuAWdC5Nz2wwEerztXw5cqe_0uOPP%3DqZZW9SOs8ZmMBrjujEg%40mail.gmail.com.