[ https://issues.jboss.org/browse/WFLY-5233?page=com.atlassian.jira.plugin.... ] 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 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 2: 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 2: one containing static metadata, the other dynamic metadata; we can reduce the size of the data that needs to be replicated every request. Additionally, #3 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)