[infinispan-dev] putAll, getAll and optimization fruits
Galder Zamarreño
galder at redhat.com
Wed Sep 24 03:13:25 EDT 2014
On 23 Sep 2014, at 16:15, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>
> On 23 Sep 2014, at 16:06, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>
>> Doing that it’s 1/2 of the story, because as I’ve already explained in Wolf’s efforts around putAll, the Netty server implementation just calls to Infinispan synchronous cache operations, which often block. So, using an async client will get you 1/2 of the job done. The way to limit the blocking is by limiting that blocking, e.g. splitting keys and sending gets to nodes that own it would mean the gets get resolved locally, similar thing with puts but as Bela/Pedro found out, there could be some blocking still.
>
> Galder, are you saying that I cannot execute put operations in parallel on the same node for the same transaction?
Err, not sure what use case you are talking about here but Hot Rod does not have transactions.
> I.e. could the netty server use a bounded queue + thead pool to parallelize put operation in case of putAll (the other case does not matter).
More than Netty, the Hot Rod server implementation could take a N-key putAll and parallize it if needed.
> Also, even if we keep the server synchronous and split the payload per server to run that in parallel, we will still gain enough I think:
>
> - we avoid i-1 times the latency between the client and a specific node (i is the number of keys going to a specific node)
> - with the key evenly distributed, you divide the overall latency by O(m) where m is the number of servers.
>
> Something like that :)
Sure, I agree that there’s benefit of course, but as you rightly pointed out, these puts either need to be putAsyncs and wait for all replies and then send the response to the client, or paralellize sync put calls manually.
Cheers,
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder at redhat.com
twitter.com/galderz
More information about the infinispan-dev
mailing list