10:45 a.m.
On Jan 21, 2014, at 2:13 PM, Sanne Grinovero <sanne(a)infinispan.org> wrote:
On 21 January 2014 13:37, Mircea Markus <mmarkus(a)redhat.com>
wrote:
>
> On Jan 21, 2014, at 1:21 PM, Galder Zamarreño <galder(a)redhat.com> wrote:
>
>>> What's the point for these tests?
>>
>> +1
>
> To validate if storing the data in binary format yields better performance than store
is as a POJO.
That will highly depend on the scenarios you want to test for. AFAIK
this started after Paul described how session replication works in
WildFly, and we already know that both strategies are suboptimal with
the current options available: in his case the active node will always
write on the POJO, while the backup node will essentially only need to
store the buffer "just in case" he might need to take over.
Indeed as it is today, it doesn't make sense for WildFly's session replication.
Sure, one will be slower, but if you want to make a suggestion to him
about which configuration he should be using, we should measure his
use case, not a different one.
Even then as discussed in Palma, an in memory String representation
might be way more compact because of pooling of strings and a very
high likelihood for repeated headers (as common in web frameworks),
pooling like in String.intern()?
Even so, if most of your access to the String is to serialize it and sent is remotely then
you have a serialization cost(CPU) to pay for the reduced size.
so
you might want to measure the CPU vs storage cost on the receiving
side.. but then again your results will definitely depend on the input
data and assumptions on likelihood of failover, how often is being
written on the owner node vs on the other node (since he uses
locality), etc.. many factors I'm not seeing being considered here and
which could make a significant difference.
I'm looking for the default setting of storeAsBinary in the configurations we ship. I
think the default configs should be optimized for distribution, random key access (every
reads/writes for any key executes on every node of the cluster with the same probability)
for both read an write.
> As of now, it doesn't so I need to check why.
You could play with the test parameters until it produces an output
you like better, but I still see no point?
the point is to provide the best defaults params for the default config, and see
what's the usefulness of storeAsBinary.
This is not a realistic
scenario, at best it could help us document suggestions about which
scenarios you'd want to keep the option enabled vs disabled, but then
again I think we're wasting time as we could implement a better
strategy for Paul's use case: one which never deserializes a value
received from a remote node until it's been requested as a POJO, but
keeps the POJO as-is when it's stored locally.
I disagree: Paul's scenario, whilst very important, is quite specific. For what I
consider the general case (random key access, see above), your approach is suboptimal.
I believe that would
make sense also for OGM and probably most other users of Embedded.
Basically, that would re-implement something similar to the previous
design but simplifying it a bit so that it doesn't allow for a
back-and-forth conversion between storage types but rather dynamically
favors a specific storage strategy.
It all boils down to what we want to optimize for: random key access or some degree of
affinity. I think the former is the default.
One way or the other, from the test Radim ran with random key access, the storeAsBinary
doesn't bring any benefit and it should:
http://lists.jboss.org/pipermail/infinispan-dev/2009-October/004299.html
Cheers,
Sanne
>
> Cheers,
> --
> Mircea Markus
> Infinispan lead (www.infinispan.org)
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)