Hi Martin!

Our team is thinking about moving our configuration to sticky sessions
(we currently have things working in non-sticky mode). Through my
testing with non-sticky session, I've tailed the logs for both n1 and
n2 memcache nodes and they appear to both be notified on every
request. Is that valid?

While reading the home page of the project here (http://
code.google.com/p/memcached-session-manager), under the 'How it works'
section, it appears that in sticky mode, both memcache nodes are
notified on each and every request as well. Am I reading this
properly? The docs indicate that they need to be updated for non-
sticky configuration.

Could you briefly explain the differences between sticky and non-
sticky in terms of the frequency in which the memcache nodes (2 or
more) are updated. I'd like to fully understand what will perform
better theoretically.

Thanks in advance!

- Billy -

Search Discussions

  • Martin Grotzke at Oct 24, 2011 at 9:46 am
    Hi Billy,
    On 10/21/2011 10:22 PM, Billy Bacon wrote:
    Hi Martin!

    Our team is thinking about moving our configuration to sticky sessions
    (we currently have things working in non-sticky mode). Through my
    testing with non-sticky session, I've tailed the logs for both n1 and
    n2 memcache nodes and they appear to both be notified on every
    request. Is that valid?

    While reading the home page of the project here (http://
    code.google.com/p/memcached-session-manager), under the 'How it works'
    section, it appears that in sticky mode, both memcache nodes are
    notified on each and every request as well. Am I reading this
    properly? The docs indicate that they need to be updated for non-
    sticky configuration.
    The docs only outline the general idea without going into too much
    detail. In fact, there are optimizations with the goal to reduce session
    serialization and updates in memcached as far as possible.

    For sticky sessions: it's checked
    1) if the session has been accessed at all
    2) if attributes were read/set at all (if no attribute was read then the
    object graph also cannot be changed)
    3) if the serialized session differs from the previously stored version
    in memcached (by comparing the hashes of the serialized byte[]).

    If any of 1) - 3) is false then the session is not updated in memcached
    (step 3 is the most expensive one, as it includes actual serialization
    of the session to determine if any attribute or attribute object graph
    had been modified).
    To prevent expiration of such a session that was not updated in
    memcached sessions (stored in the internal session map) are pinged in
    memcached in tomcats background thread.

    For non-sticky sessions there's a separate headers/metadata object
    stored in memcached for each session that stores the lastAccessTime and
    2 more attributes. This is read and written for every request for a
    non-sticky session. Sessions that were not updated in memcached because
    they're not modified are pinged in memcached directly to prevent
    expiration (as there's no local session map that can be processed in a
    background thread).

    Could you briefly explain the differences between sticky and non-
    sticky in terms of the frequency in which the memcache nodes (2 or
    more) are updated. I'd like to fully understand what will perform
    better theoretically.
    I hope my description was helpful.

    In short, in sticky session mode there's less interaction with
    memcached. In sticky mode a session does not have to be loaded from
    memcached (as it's available in the local session map), and session
    backup in memcached can safely be done asynchronously, so that
    effectively no time should be spent in the request thread related to msm
    / session backup.
    So in terms of performance sticky mode is preferred.

    Cheers,
    Martin


    --
    Dennis Brakhane, Martin Grotzke und Ole Langbehn GbR
    Breitenfelder Str. 13c, 20251 Hamburg
  • Billy Bacon at Oct 24, 2011 at 5:36 pm
    This is excellent Martin, thanks so much for the explanation!
    On Monday, October 24, 2011 at 3:35 AM, Martin Grotzke wrote:

    Hi Billy,
    On 10/21/2011 10:22 PM, Billy Bacon wrote:
    Hi Martin!

    Our team is thinking about moving our configuration to sticky sessions
    (we currently have things working in non-sticky mode). Through my
    testing with non-sticky session, I've tailed the logs for both n1 and
    n2 memcache nodes and they appear to both be notified on every
    request. Is that valid?

    While reading the home page of the project here (http://
    code.google.com/p/memcached-session-manager (http://code.google.com/p/memcached-session-manager)), under the 'How it works'
    section, it appears that in sticky mode, both memcache nodes are
    notified on each and every request as well. Am I reading this
    properly? The docs indicate that they need to be updated for non-
    sticky configuration.
    The docs only outline the general idea without going into too much
    detail. In fact, there are optimizations with the goal to reduce session
    serialization and updates in memcached as far as possible.

    For sticky sessions: it's checked
    1) if the session has been accessed at all
    2) if attributes were read/set at all (if no attribute was read then the
    object graph also cannot be changed)
    3) if the serialized session differs from the previously stored version
    in memcached (by comparing the hashes of the serialized byte[]).

    If any of 1) - 3) is false then the session is not updated in memcached
    (step 3 is the most expensive one, as it includes actual serialization
    of the session to determine if any attribute or attribute object graph
    had been modified).
    To prevent expiration of such a session that was not updated in
    memcached sessions (stored in the internal session map) are pinged in
    memcached in tomcats background thread.

    For non-sticky sessions there's a separate headers/metadata object
    stored in memcached for each session that stores the lastAccessTime and
    2 more attributes. This is read and written for every request for a
    non-sticky session. Sessions that were not updated in memcached because
    they're not modified are pinged in memcached directly to prevent
    expiration (as there's no local session map that can be processed in a
    background thread).

    Could you briefly explain the differences between sticky and non-
    sticky in terms of the frequency in which the memcache nodes (2 or
    more) are updated. I'd like to fully understand what will perform
    better theoretically.
    I hope my description was helpful.

    In short, in sticky session mode there's less interaction with
    memcached. In sticky mode a session does not have to be loaded from
    memcached (as it's available in the local session map), and session
    backup in memcached can safely be done asynchronously, so that
    effectively no time should be spent in the request thread related to msm
    / session backup.
    So in terms of performance sticky mode is preferred.

    Cheers,
    Martin


    --
    Dennis Brakhane, Martin Grotzke und Ole Langbehn GbR
    Breitenfelder Str. 13c, 20251 Hamburg

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmemcached-session-manager @
categoriesmemcached
postedOct 21, '11 at 8:22p
activeOct 24, '11 at 5:36p
posts3
users2
websitememcached.org

2 users in discussion

Billy Bacon: 2 posts Martin Grotzke: 1 post

People

Translate

site design / logo © 2022 Grokbase