[infinispan-dev] Store as binary

[Sanne Grinovero]

On 21 January 2014 13:37, Mircea Markus <mmarkus at redhat.com> wrote:
>
> On Jan 21, 2014, at 1:21 PM, Galder Zamarreño <galder at 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.

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), 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.

> 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? 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 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.

Cheers,
Sanne

>
> Cheers,
> --
> Mircea Markus
> Infinispan lead (www.infinispan.org)
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev