On Wed, Oct 28, 2009 at 6:44 PM, Brian Hawkins <[email protected]> wrote:
> This will answer all of your serialization questions. > > http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking Yes, this is indeed a very good resource, I'm already evaluating libs based on this comparison. Though, I have two requirements that limit the possible solutions: 1) serialization of types not known at build time: Of course I know which fields of the session I have to serialize, but I have no knowledge of the types stored in the sessions attributes, as this are user types. 2) forward/backward compatibility of serialized types: I want to support "migration"/"upgrade" of stored/serialized user types to new versions, e.g. it should be possible to deserialize a type into a newer version of this type that has some field removed. To 1) I couldn't see how it would be possible to achieve this with e.g. protobuf or thrift. To 2) This is also a very rare feature, if you have filtered the list by requirement 1). For some libs that say it might come in future versions I already have asked if there's s.th. like a timeline/roadmap. Until now I only found jackson (json) to support both 1) and 2). And first tests show/confirm that it performs really good, as shown by the benchmark. If you have any hints regarding support of dynamic/unknown types and forward/backward compatibility please let me know, this would be great! Cheers, Martin > > > Brian > > > On Wed, Oct 28, 2009 at 2:54 AM, Martin Grotzke < > [email protected]> wrote: > >> On Tue, Oct 27, 2009 at 8:04 PM, Christian Becker <[email protected] >> > wrote: >> >>> Hi, >>> >>> 2009/10/27 Martin Grotzke <[email protected]> >>> >>>> On Tue, Oct 27, 2009 at 5:36 PM, Christian Becker < >>>> [email protected]> wrote: >>>> >>> They argument with too big session objects and too many requests/traffic >>> for the memcached - but i already did some calculations and there would be >>> max. 1500 req/s, which are no problem for memcached (i have some running >>> with more than 2,5k/sec) and traffic should also be easy to handle. >>> >> Ok, both are valid things to consider. Keeping sessions small is always a >> goal (IMO). How big are your sessions (e.g. when calculating the size of the >> object graph, or after they were serialized using java serialization)? >> What's the characteristics of your session attributes: lots of objects of >> the same class, or a deep object graph (if you might provide examples this >> would be great)? I'm actually interested in this because I want to compare >> several serialization strategies in respect to serialization performance and >> serialization size. >> >> Regarding the throughput: is 1500 req/s the number of requests you have to >> serve in total, or the number of requests per machine? What was your test >> setup and test that reached 2,5k/sec? >> >> Cheers, >> Martin >> >> >> >>> >>>> Cheers, >>>> Martin >>>> >>>> >>>> >>>>> >>>>> thanks again, >>>>> christian >>>>> >>>>> 2009/10/27 Martin Grotzke <[email protected]> >>>>> >>>>> Hi Christian, >>>>>> >>>>>> I created the memcached-session-manager (msm) for the relaunch of one >>>>>> of the biggest sites in germany, therefore it's designed to be performant >>>>>> and scalable :) (the relaunch is still under development). We're just in >>>>>> the >>>>>> process of integrating msm in other projects as well, as session >>>>>> failover is >>>>>> often not fully covered. >>>>>> >>>>>> However, some users should already be using it, according to the issue >>>>>> tracker and the mailing list (and some email conversations I had with >>>>>> others). >>>>>> >>>>>> Concerning performance and stability: as the memcached-session-manager >>>>>> itself does no resource intensive processing itself, performance and >>>>>> stability mainly depends on memcached and spymemcached (which is used for >>>>>> communication with memcached). Both are proven technologies which are >>>>>> used >>>>>> in production. >>>>>> >>>>>> In terms of performance it's interesting to consider, that session >>>>>> backup can be done asynchronously, so that your requests/responses do not >>>>>> have to wait until the session is sent to memcached (by default, the >>>>>> backup >>>>>> is done synchronously). If sessions are sent to memcached synchronously, >>>>>> you >>>>>> can specify the timeout for this. I just added these things (* >>>>>> sessionBackupAsync, sessionBackupTimeout) to the documentation, was >>>>>> still on my list, see >>>>>> http://code.google.com/p/memcached-session-manager/wiki/SetupAndConfiguration >>>>>> * >>>>>> * >>>>>> * >>>>>> *Cheers, >>>>>> Martin* >>>>>> >>>>>> >>>>>> On Mon, Oct 26, 2009 at 4:31 PM, Christian Becker < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> >>>>>>> Hi Martin, >>>>>>> >>>>>>> this looks really great. Since we also use tomcat for our platform, >>>>>>> we >>>>>>> would like to use it. >>>>>>> >>>>>>> But, can you please tell me a reference where you already use it? >>>>>>> It would be great if you can tell me a bit about the performance and >>>>>>> stability. >>>>>>> >>>>>>> thank you, >>>>>>> cheers, >>>>>>> Christian >>>>>>> >>>>>>> On 25 Okt., 01:38, "martin.grotzke" <[email protected]> >>>>>>> wrote: >>>>>>> > Hi, >>>>>>> > >>>>>>> > I just release memcached-session-manager 1.0: >>>>>>> http://code.google.com/p/memcached-session-manager/ >>>>>>> > >>>>>>> > It's a session failover solution for tomcat, sending sessions to >>>>>>> > memcached after a request is finished, so that this session can be >>>>>>> > picked up by other tomcats if one tomcat fails. >>>>>>> > >>>>>>> > It would be great if the memcached-session-manager could be listed >>>>>>> in >>>>>>> > the wiki on the page for related projects: >>>>>>> http://code.google.com/p/memcached/wiki/MemcachedOffspring >>>>>>> > >>>>>>> > Any other feedback is also welcome of course :) >>>>>>> > >>>>>>> > Thanx && cheers, >>>>>>> > Martin >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Martin Grotzke >>>>>> http://www.javakaffee.de/blog/ >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Martin Grotzke >>>> http://www.javakaffee.de/blog/ >>>> >>> >>> >> >> >> -- >> Martin Grotzke >> http://www.javakaffee.de/blog/ >> > > -- Martin Grotzke http://www.javakaffee.de/blog/
