On Feb 4, 2014, at 7:14 AM, Galder Zamarreño <galder(a)redhat.com> wrote:
On 21 Jan 2014, at 17:45, Mircea Markus <mmarkus(a)redhat.com>
wrote:
>
> 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.
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)