[infinispan-dev] Store as binary

[Mircea Markus]

On Feb 4, 2014, at 7:14 AM, Galder Zamarreño <galder at redhat.com> wrote:

> On 21 Jan 2014, at 17:45, Mircea Markus <mmarkus at redhat.com> wrote:
> 
>> 
>> On Jan 21, 2014, at 2:13 PM, Sanne Grinovero <sanne at infinispan.org> wrote:
>> 
>>> 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.
>> 
>> 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.
> 
> Serialization has a cost, but nothing compared with the transport itself, and you don’t have to go very far to see the impact of transport. Just recently we were chasing some performance regression and even though there were some changes in serialization, the impact of my improvements was minimal, max 2-3%. Optimal network and transport configuration is more important IMO, and once again, misconfiguration in that layer is what was causing us to be ~20% slower.

yes, I din't expect huge improvements from storeAsBinary, but at least some improvement caused by the fact that lots of serialization should't happen in the tested scenario. 2-3% improvement wouldn't hurt, though :-)

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)