Query latency vs number of partitions

Question

I am trying to measure the average latency per object retrieval using the query approach, and what I am finding is that as the number of instances of the server (a server being a single jvm running DefaultCacheServer with backup-count set to 1, and partition-count set to 1021) increases, the latency increases significantly as shown in the results below:
Latency (microseconds) for Number of server instances
Objects 2 4 8 16
In Cache srvrs srvrs srvrs srvrs
1K 593 730 889 1175
10K 592 720 880 1206
50K 580 724 879 1200
100K 585 726 877 1204
The query code is as follows:
final Filter filter = new EqualsFilter(idExtractor, key);
final Filter limitedFilter = new LimitFilter(filter, 1);
final Set spotPricesKeys = cache.keySet(limitedFilter);
if (spotPricesKeys != null && spotPricesKeys.size() > 0){
     spotPrice = (SpotPrice) cache.get(spotPricesKeys.iterator().next());
and
private static ValueExtractor idExtractor = new KeyExtractor("intValue");
Any idea why the latency is increasing with the added number of server instances?
Thanks
Adsen

Answer 1

Partitioning strategies is an "advanced" feature of Coherence. It works much like a hash function but instead of a hash code it calculates the partition number that will be used for each key. You can use more or less any deterministic algorithm based only on key information. Lets assume that you have a cache with strings as keys (representing for instance a persons name) and you would like to partition based on the first letter it could look something like this (this is just an example - in production code you would like to make sure the algorithm statistically makes as even use of all the partitions that you have in your cluster!):
public class MyPartitionStrategy implements KeyPartitioningStrategy, Serializable {
private PartitionedService partitionedService;
public MyPartitionStrategy() {
public void init(final PartitionedService partitionedService) {
this.partitionedService = partitionedService;
public int getKeyPartition(final Object key) {
if (key instanceof String) {
return ((String) key).charAt(0) % (partitionedService.getPartitionCount() + 1);
} else {
return key.hashCode() % (partitionedService.getPartitionCount() + 1);
With this filter you would know that all keys starting with the same first letter ends up in the same partition. You would specify the use of this filter once in the coherence configuration (dont remember the element to use on top of my head though).
Now assume that you for some reason want to do some query that only should apply to entries with a key starting with the letter 'a' you could do that with a PartitionedFilter (you would have to write some code that determines what partition the key 'a' would end up if it existed and then restrict the query to that single partiton). With this solution Coherence will only send the request to the single node holding the primary for that one partition holding all the "axxxx" keys and not to all the nodes in the cluster making the query scale close to linerary no matter how many nodes you have!
A problem when the number of partitions grow is to find a partitioning strategy that allocates a useful set of objects into a single partition. If you for instance have like 4000+ partitions and would like to divide addresses based on state in order to perfrom queries against all of your customers in a particular state there is no obvious way to do that since the number of states is much smaller than the number of partitions :-(
This kind of partitioning can however be very useful in many cases (we have used it to good effect in my current project).
In produktion code it is often some part of a composite key that is useful as a key partitioning criteria and you could then for instance return the standard hash code of that key part modulus he partition count.
Another possibly useful feature you may look at is when it comes to limiting the number of nodes invloved in queries is the KeyAssociatedFilter (if you use key association at all in your cache).
/Magnus