Hi,

2009/10/27 Martin Grotzke <[email protected]>

> Hi Christian,
>
> On Tue, Oct 27, 2009 at 5:36 PM, Christian Becker 
> <[email protected]>wrote:
>
>> Hi Martin,
>>
>> thanks for your reply :)
>>
>> I found the website of your company and after reading your references, now
>> i am really confident that the session manager would be able to handle our
>> load :)
>>
> Great to hear that (it makes me really glad I have to admit :))
>
>
>>
>> Now the only thing left to do is the persuasion of our development team,
>> since they have the position, that this kind of session sharing is
>> impossible.
>>
> What are their arguments/concerns?
>

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.


> 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/
>

Reply via email to