On Feb 4, 2014, at 7:14 AM, Galder Zamarreño <gal...@redhat.com> wrote:
> On 21 Jan 2014, at 17:45, Mircea Markus <mmar...@redhat.com> wrote: > >> >> On Jan 21, 2014, at 2:13 PM, Sanne Grinovero <sa...@infinispan.org> wrote: >> >>> On 21 January 2014 13:37, Mircea Markus <mmar...@redhat.com> wrote: >>>> >>>> On Jan 21, 2014, at 1:21 PM, Galder Zamarreño <gal...@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) _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
