Performance improvement for RedisSessionRepository

[mshabunin77]

Describe the bug First of all, it's not a bug. It's a possibility to improve performance by avoiding unnecessary deserialization in RedisOperations every time session is loaded from redis. In current implementation of RedisSessionRepository it is expected that RedisOperations converts byte arrays to objects which then are stored in MapSession and it's done for all attributes on every session load. Instead, this deserialization can be postponed and MapSession will store Supplier object the same way as it's done in JdbcIndexedSessionRepository. Same improvement can be applied to RedisIndexedSessionRepository.

To Reproduce

1. Use RedisSessionRepository(real application pages or test)
2. Make session attribute serialization/deserialization heavier - for instance, enable encryption - this will help to show the difference.
3. Create 2 application pages(in test it can be just different set of attributes). The first one with bigger number of attributes(and bigger data), the second with, say, single small attribute.
4. Compare latency of second page between original RedisSessionRepository and postponed deserialization in the next scenario:
   • Create a new session
   • Call the first page to populate all session attributes.
   • Call the second page.

Expected behavior Implementation with postponed deserialization should provide better performance.

Sample

A link to a GitHub repository with a minimal, reproducible sample.

Reports that include a sample will take priority over reports that do not. At times, we may require a sample, so it is good to try and include a sample up front.

[marcusdacoregio]

Hi @mshabunin77, thanks for the report.

Are you able to provide a minimal sample where we can see the difference between the two pages? Ideally, it would be great if we have a modified implementation of RedisSessionRepository where it uses the Supplier approach to be able to compare them.