[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