The Session Controller is a primary component in Ceptor – it contains the list of sessions that are currently known in the system, along with the information about each individual session, such as the logged-in flag, userid and password, and access rights. It also contains the authentication and authorization plugins that are responsible for authenticating the user or providing information needed for authorization.
| Drawio | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
A Session Controller can operate either alone, or in a cluster of multiple Session Controllers, that synchronize sessions information with each other. If they are deployed in a cluster, as SC mirrors, each change in a session, such as session creation, logon, logoff or session removal are broadcasted to the other SC servers, so they all are instantly synchronized.
A number of Agents communicates communicate with one or more SC servers, and each SC server synchronizes changes with the other SC servers like this:
| Drawio | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
If the Agent 4 asks SC3 ot to create a new session, SC3 will tell SC1 and SC2 about the new session.
If Agent1 later logs a user in, the other SC servers will be informed about the changes in the session and update their internal tables, as ell well as send out commands to the Agents that have a copy of the session to tell them to remove that particular one from their caches.
...
Session Controllers are the most complex part of PortalProtect to cluster. Each individual Session Controller needs to know about all other session controllers, and all session controllers has to have to be connected to all other session controllers within a cluster.
...
It does not matter which session controller is listening, and which one is making the call – once they connection their connection is established, they are equal.
...
It is not recommended to cluster session controllers to obtain better performance, usually having two session controllers for failover fail-over purposes is more than enough – testing . Testing has proved that there is little or no gain in performance by having more than one session controller. It is in very few applications that the The CPU usage of the PP server is only in very few installations above 20%, so . So most likely adding additional machines or session controller instances, often only generates more session replication, and doesn’t does not improve overall performance.
What
...
Works and What Does Not
First of all, keep things simple – there is no reason to setup 10 set up 10 different PP servers in a cluster, if 2 is enough – having too many servers just complicates the configuration needlessly, and increases the risk that something will go wrong.
Since updates to a session has to have to be synchronous (to ensure that consecutive requests will always see the updated session, even if the requests hits other application servers), the more session controllers added to a cluster, the longer time it will take to finish changing the contents of a session.
...