What is persistence?

Short answer

Persistence (session affinity, sticky session) ensures that consecutive requests from the same client are always sent to the same Backend Service. It is required in applications that keep session information (cart, login status…) in the server's own memory; otherwise, the user's session is lost when the user lands on another server. It is not needed in applications that keep the session in a central place (Redis, database). In TR7, it is selected from the Persistence field in the vService form: New cookie, Current cookie, Hash and Session Affinity Manager (SAM) in HTTP, Hash in L7 TCP, L4 Persistence and SIP Persistence in Network.

How Does It Work?

1. First request: A client with no persistence record is sent to a Backend Service according to the vService's algorithm.
2. The mapping is established: TR7 maps the client to that Backend Service: by adding a cookie, by reading the application's own cookie or by generating a hash from a key such as the source IP.
3. Subsequent requests: The requests of the same client go to the Backend Service it is mapped to, without consulting the algorithm.
4. If the server goes down: If the mapped Backend Service goes down in the health check or is put into Maintenance mode, the client is directed to another Backend Service according to the algorithm; the session is lost only if it is in the server's memory.

Persistence off

1st request → Server 1
2nd request → Server 2
3rd request → Server 1

Each request is evaluated separately.

Persistence on

1st request → Server 1
2nd request → Server 1
3rd request → Server 1

The client stays on the same server.

When Is It Needed?

Application	Persistence
Web applications that keep the session in the server's memory (stateful)	Required
Applications that keep the session in a central store (Redis, database)	Not required
Stateless APIs and microservices	Not required; if enabled, it can disrupt load distribution
Remote desktop (RDP) sessions	Required; the RDP Cookie algorithm in L7 TCP provides this on its own

Persistence in TR7

The methods vary by vService type:

vService type	Methods
HTTP	New Cookie (TR7 adds its own cookie), Current Cookie (reads the application's cookie, e.g. JSESSIONID), Hash (a key defined with Smart Variables), Session Affinity Manager (SAM) (a method that tracks sessions and can rebalance them)
L7 TCP	Hash (Smart Variable keys such as source IP, SNI, destination IP/port)
Network	L4 Persistence (source IP), SIP Persistence (Call-ID)

The Persistence setting is in the vService form. When algorithms that provide persistence by themselves (self-persistent), such as Source, URI, URL Param, HDR and RDP Cookie, are selected, the Persistence field is hidden; these algorithms already send the same key to the same server.

Common Misconceptions

• "Persistence should be on in every application." It is unnecessary in applications that keep the session centrally or that are stateless; if enabled, traffic can be distributed unevenly across the servers.
• "With persistence on, the user keeps the session even if the server goes down." When the mapped server goes down, the client goes to another server; if the session is in the server's memory, it is lost.
• "Source IP based persistence is always reliable." Many users behind a corporate NAT or proxy come from a single IP, and all of them land on the same server. In HTTP, cookie-based methods (New cookie, Current cookie, SAM) identify each client separately.

How it is done in the documentation

• HTTP vService · Session Persistence
• HTTP vService · Session Affinity Manager (SAM)
• vService · Feature / Capability Comparison

Related questions

• How do I know whether my application needs persistence?
• Which persistence methods are available?
• What is Session Affinity Manager (SAM); how is it different from classic cookie persistence?
• All users coming from behind a corporate NAT go to a single server; why?