Session Approach / Autoscaling

Post any questions you have about using the Verj.io Studio, including client and server-side programming with Javascript or FPL, and integration with databases, web services etc.

Moderators: Jon, Steve, Ian, Dave

Jon Moore
Ebase User
Posts: 9
Joined: Thu Dec 29, 2011 9:43 pm

Session Approach / Autoscaling

#1

Postby Jon Moore » Mon Sep 14, 2020 1:43 pm

I've been reading the help content for autoscaling, and I want to understand the approach to handling sessions and the trade-offs between design options - for example, whether to store cacheable content in the session, regenerate it on each request, or store it in the database.

The comments I have found about sessions refer to their in-memory footprint, which suggests that sessions are restricted to the container where they are created, and implies that sticky sessions are in use. That would mean that the main consideration is session memory, but also that sessions will be lost if a container is lost. It also introduces questions about auto-scaling downwards - it could take a long time to scale down if each container has to wait until all its user sessions have drained, unless there were some mechanism to migrate sessions from a closing container.

The alternative would be some form of distributed session. This would be resilient against the loss of a container, but at the cost of more network traffic, and introducing questions about synchronisation of session updates across requests with the same session being handled concurrently by different containers.

I know there will be a lot of detail to session handling - there always is - but should I be treating it basically as a sticky session or a distributed session? (I will have some supplementary questions, either way.)
0 x

Jon
Moderator
Moderator
Posts: 1342
Joined: Wed Sep 12, 2007 12:49 pm

Re: Session Approach / Autoscaling

#2

Postby Jon » Tue Sep 15, 2020 9:39 am

This management of sessions in the Verj.io cloud platform is an area that is currently being reviewed and is likely to change in the short/medium term. At the moment each container acts as a separate unit and session data is not shared. This is using sticky sessions. Your comment about scaling down the number of containers is accurate - it can take a long time.

This is likely to change so that session data is distributed between all containers forming part of the cluster. The data propagation between containers is likely to be via a database. Even with this "fully clustered" model, we will probably still use sticky sessions and an individual session will only move between containers if a container fails or is shutdown. With this model scaling down the number of containers is near instantaneous.

The situation with on-premise servers (as opposed to the cloud platform) is basically the same, except that you have the option at the moment of configuring full clustering with session propagation - as this is just Tomcat configuration.

Ignoring these developments, I think there is still a valid discussion to be had as to whether data should be cached (in session memory) or reloaded whenever necessary. This includes the question of whether cached data might be stale but also includes the memory cost of maintaining cached session data for large numbers of users, cost of increased database load etc. This is mostly a performance discussion and I'm sure you're aware of the pros and cons.
0 x

Jon Moore
Ebase User
Posts: 9
Joined: Thu Dec 29, 2011 9:43 pm

Re: Session Approach / Autoscaling

#3

Postby Jon Moore » Tue Sep 15, 2020 11:30 am

Thanks, Jon.

Where you're heading is usually my preferred pattern for session management - I think of it as 'soft' session affinity. It can be usefully combined with an in-memory LRU cache (without something of the sort, an application where sessions can grow signficantly can end up exhausting memory - performance drops as the total session memory grows, but the application doesn't fall over completely).

Whether to cache data in the session or reload / regenerate it is dependent on the nature of the data and the application - once the underlying session mechanism and costs is understood.
0 x


Who is online

Users browsing this forum: No registered users and 14 guests