Evaluation of Redis-powered session storage for ICM

Historically Enfinity and today’s ICM are using a database backed session store to handle session fail over. This is to keep all application servers in a cluster environment in sync. If server A fails to respond, server B can take over without the user’s notice.

SQL> describe sessioninformation;
Name                                      Null?    Type
----------------------------------------- -------- ----------------------------
SESSIONID                                 NOT NULL VARCHAR2(256 CHAR)
DOMAINID                                  NOT NULL VARCHAR2(28 CHAR)
USERID                                             VARCHAR2(28 CHAR)
AUTHENTICATIONSTATE                                NUMBER(11)
LANGUAGE                                           VARCHAR2(6 CHAR)
CURRENCY                                           VARCHAR2(3 CHAR)
PERSONALIZATIONGROUPID                             VARCHAR2(28 CHAR)
DICTIONARY                                         BLOB
EXPIRES                                            FLOAT(126)

Session dictionary data will be stored as BLOB value in above table. Now, the nature of session data is more transient than persistent. Once the session is timed out any data associated with that session must be removed from the storage. Currently an asynchronous job (named CheckSessions) is taking care of that task.

All of the above can be optimized using an in-memory key value store like Redis. Among over things Redis is made to handle the use case of distributed sessions. It has API to EXPIRE data stored in its memory making above job obsolete. It also comes with an option to persistently store data kept in memory.

How we evaluated

  1. We’ve extracted the session storage code from ICM to run standalone
  2. Building a randomized (yet artificial) session object that contains just strings and numbers
  3. Wrote backend specific code to store session. One for database and one for Redis
  4. Measured run-time of both backends

The test flow was like this

  • prepare session object
  • start time measurement
  • save session object to remote backend
  • end time measurement

And the results for Redis storage are

Executed test flow in 10 parallel threads:
  1. Runtime for ‘2000’ loops: 1608 ms
  2. Runtime for ‘2000’ loops: 1643 ms
  3. Runtime for ‘2000’ loops: 1643 ms
  4. Runtime for ‘2000’ loops: 1644 ms
  5. Runtime for ‘2000’ loops: 1667 ms
  6. Runtime for ‘2000’ loops: 1670 ms
  7. Runtime for ‘2000’ loops: 1675 ms
  8. Runtime for ‘2000’ loops: 1678 ms
  9. Runtime for ‘2000’ loops: 1680 ms
  10. Runtime for ‘2000’ loops: 1682 ms

Runtime for all 10 threads together: 1683 ms


And the results for database storage are
Executed test flow in 10 parallel threads:
  1. Runtime for ‘2000’ loops: 7862 ms
  2. Runtime for ‘2000’ loops: 8205 ms
  3. Runtime for ‘2000’ loops: 8245 ms
  4. Runtime for ‘2000’ loops: 8343 ms
  5. Runtime for ‘2000’ loops: 8364 ms
  6. Runtime for ‘2000’ loops: 8372 ms
  7. Runtime for ‘2000’ loops: 8396 ms
  8. Runtime for ‘2000’ loops: 8506 ms
  9. Runtime for ‘2000’ loops: 8596 ms
  10. Runtime for ‘2000’ loops: 8694 ms

Runtime for all 10 threads together: 8695 ms

Redis / Oracle Session Storage

Conclusion

A Redis-powered backend to store session information is possible to integrate with Intershop technology. What remains open is the question how it behaves in high availability environment. Redis itself supports certain cluster scenarios which must be evaluated too.

Evaluation of Redis-powered session storage for ICM

4 thoughts on “Evaluation of Redis-powered session storage for ICM

  • 2017-01-26 at 4:15 pm
    Permalink

    Wow, these are really great news for performance concerned people. Especially the runtime graphic blows my mind.
    When will we see such a great improvement in Intershop 7?

  • 2017-01-28 at 2:36 pm
    Permalink

    Do you want to open source your Redis benchmark code?

  • 2017-01-29 at 11:26 am
    Permalink

    It would also be interesting to measure how actually the R/W on the session table affects production clusters, maybe collecting DB statistics from different environments.
    In my experience the great majority of sessions are generated by crawlers or one-click session.
    If redis cluster features does not work well, maybe it would make sense to have a two-layer approach: every new session handled with Redis, and then transferred to the DB in case it is a multi-page session.
    So, session persistency and high availability could be granted for the sessions that really need it (multi-click user sessions), and a fastest approach can be used for all other “disposable” sessions.

    • 2017-02-03 at 2:48 pm
      Permalink

      Hello Mauro, thanks for the input on the robot sessions. I don’t know the details yet, but there is some configuration option planed on how to avoid storing them. The session store used doesn’t matter in that case.

Comments are closed.