9:06 a.m.
We have had a short discussion on putAll, getAll. I’m pushing the info here
>> getAll and putAll and nothing more than a glorified
sequential call to get / put in a for loop.
>> The execution of gets and puts in parallel for it costs o(n) network trip in
latency rather than o(1).
>> How could we improve it ?
> Historically getall and putall were not intended as hotrod operations and were
actually implemented only to honor the map interface.
> The most we can do RPC wise to optimize these operations is to group all keys mapping
to the same server node into a single request. That would reduce the number of RPCs, but
in big O talk it would still be O(numKeys). Executing them in parallel sounds like a good
idea to me. Curious to hear other thoughts on this. Galder?
So there are actually three improvements:
* getall and putall as hotrod operations (no matter how that will be implemented by the
server itself)
Galder, is it possible in current HR design to execute requests in parallel, without
consuming one thread for each node? That was something my async client should solve, but
afaik it's not possible without substantial changes, and we were rather targetting
that for future JDK 8 only client.
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.
Anyway, we could route the HR request to the node with most matching
keys.
I don’t think that’s a good idea.
The best option is to take all keys, divide them by server according to hashing and send
paralell native Hot Rod getAll operations contain N keys requested to each server. The
same thing for putAll.
I’ve create a JIRA to get getAll/putAll implemented in the Hot Rod 2.0 timeframe:
https://issues.jboss.org/browse/ISPN-4752
9:15 a.m.
On 23 Sep 2014, at 16:06, Emmanuel Bernard <emmanuel(a)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?
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).
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 :)
2:13 a.m.
On 23 Sep 2014, at 16:15, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
On 23 Sep 2014, at 16:06, Emmanuel Bernard <emmanuel(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
3690
days inactive
3691
days old
infinispan-dev@lists.jboss.org
2 comments
2 participants
participants (2)
-
Emmanuel Bernard -
Galder Zamarreño