[jboss-jira] [JBoss JIRA] (WFLY-5233) Optimize marshalled size of web sessions

Paul Ferraro (JIRA) issues at jboss.org
Fri Aug 28 16:17:05 EDT 2015


     [ https://issues.jboss.org/browse/WFLY-5233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-5233:
-------------------------------
    Description: 
There are a couple of marshalling optimizations that we can make in the current web session clustering code:

* We currently marshal session identifiers as UTF-8 strings.  For the default session id length, this result in 42 bytes for each cache key.  Since session ids use a limited alphabet (modified base64) we can easily reduce this to 30 bytes (31 to support variable length).
* We currently store the metadata of a session in a single cache entry.  The metadata is composed of:
*# Creation timestamp (long)
*# Last access timestamp (long)
*# Max inactive interval (int)

#1 is static.  #2 updates every request. #3 is "effectively" static.  If we split the metadata cache entry into two: one containing static metadata, the other dynamic metadata; we can reduce the size of the data that needs to be replicated every request.  Additionally, #2 can be represented as a duration of time since #1, and thus can be expressed as a short or integer instead of a long.  Thus, for requests that do not modify the session, we only need to replicate 4 bytes or less instead of 20.

  was:
There are a couple of marshalling optimizations that we can make in the current web session clustering code:

* We currently marshal session identifiers as UTF-8 strings.  For the default session id length, this comes out to 42 bytes.  Since session ids use a limited alphabet (modified base64) we can easily reduce this to 30 bytes (31 to support variable length).
* We currently store the metadata of a session in a single cache entry.  The metadata is composed of:
*# Creation timestamp (long)
*# Last access timestamp (long)
*# Max inactive interval (int)

#1 is static.  #2 updates every request. #3 is "effectively" static.  If we split the metadata cache entry into two: one containing static metadata, the other dynamic metadata; we can reduce the size of the data that needs to be replicated every request.  Additionally, #2 can be represented as a duration of time since #1, and thus can be expressed as a short or integer instead of a long.  Thus, for requests that do not modify the session, we only need to replicate 4 bytes or less instead of 20.



> Optimize marshalled size of web sessions
> ----------------------------------------
>
>                 Key: WFLY-5233
>                 URL: https://issues.jboss.org/browse/WFLY-5233
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Clustering
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.CR1
>
>
> There are a couple of marshalling optimizations that we can make in the current web session clustering code:
> * We currently marshal session identifiers as UTF-8 strings.  For the default session id length, this result in 42 bytes for each cache key.  Since session ids use a limited alphabet (modified base64) we can easily reduce this to 30 bytes (31 to support variable length).
> * We currently store the metadata of a session in a single cache entry.  The metadata is composed of:
> *# Creation timestamp (long)
> *# Last access timestamp (long)
> *# Max inactive interval (int)
> #1 is static.  #2 updates every request. #3 is "effectively" static.  If we split the metadata cache entry into two: one containing static metadata, the other dynamic metadata; we can reduce the size of the data that needs to be replicated every request.  Additionally, #2 can be represented as a duration of time since #1, and thus can be expressed as a short or integer instead of a long.  Thus, for requests that do not modify the session, we only need to replicate 4 bytes or less instead of 20.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


More information about the jboss-jira mailing list