1 ACCEPTED SOLUTION
Accepted Solutions
Very good question... it does depend on what you mean by a 'persistent session' though!
Concurrent Connections
There's no built-in limit to the number of concurrent connections that Stingray can handle. A fully-established L7 connection requires two file descriptors (one for the client-side connection and one for the server-side connection), although an idle HTTP connection just requires one (because Stingray recycles the server-side connections as efficiently as possible).
The limiting factors are the memory available in the system, and the number of TCP ports. Each connection consumes a minimum of 5Kb memory; an HTTP connection typically consumes 10Kb, and additional features such as TrafficScript rules, SSL processing and the like will increase this to 20Kb or more. Each server-side connection requires a unique 4-tuple (source IP address and port, destination IP address and port), so Stingray is typically limited to about 60,000 concurrent TCP connections to each back-end node. HTTP keepalive processing reuses connections to minimize the effect of this limitation, and you can use the Connection Limiting capability to limit the number of concurrent transactions against each node, queuing pending transactions in the traffic manager.
Notwithstanding these caveats, we've run Stingray with about 1 million fully-established L7 connections in the lab, and there's no theoretical upper limit.
Persistence Records
Persistence records are used by Stingray's Session Persistence feature (Feature Brief: Session Persistence in Stingray Traffic Manager). Stingray has a fixed-size session persistence cache that is created at start-up - you will need to restart the Stingray software if you want to change the size of this cache:
Configure the cache sizes in the Global Settings configuration page in the Stingray Admin Interface
The Feature Brief: Session Persistence in Stingray Traffic Manager document describes the behavior of the session persistence cache in detail, and considers what happens when it fills up and the least-recently-used entries are discarded. You can instrument the number of entries in the cache and the age of the oldest one using the SNMP or Activity Monitor counters:
In the first 4 minutes, traffic is steady at 300 new sessions per minute and the session cache fills. Initially, the max age grows steadily but when the cache fills (after 2 minutes) the max age remains fairly stable as older entries are dropped. In the last minute, no new entries were added, so the cache remains full and the max-age increases steadily.
Very good question... it does depend on what you mean by a 'persistent session' though!
Concurrent Connections
There's no built-in limit to the number of concurrent connections that Stingray can handle. A fully-established L7 connection requires two file descriptors (one for the client-side connection and one for the server-side connection), although an idle HTTP connection just requires one (because Stingray recycles the server-side connections as efficiently as possible).
The limiting factors are the memory available in the system, and the number of TCP ports. Each connection consumes a minimum of 5Kb memory; an HTTP connection typically consumes 10Kb, and additional features such as TrafficScript rules, SSL processing and the like will increase this to 20Kb or more. Each server-side connection requires a unique 4-tuple (source IP address and port, destination IP address and port), so Stingray is typically limited to about 60,000 concurrent TCP connections to each back-end node. HTTP keepalive processing reuses connections to minimize the effect of this limitation, and you can use the Connection Limiting capability to limit the number of concurrent transactions against each node, queuing pending transactions in the traffic manager.
Notwithstanding these caveats, we've run Stingray with about 1 million fully-established L7 connections in the lab, and there's no theoretical upper limit.
Persistence Records
Persistence records are used by Stingray's Session Persistence feature (Feature Brief: Session Persistence in Stingray Traffic Manager). Stingray has a fixed-size session persistence cache that is created at start-up - you will need to restart the Stingray software if you want to change the size of this cache:
Configure the cache sizes in the Global Settings configuration page in the Stingray Admin Interface
The Feature Brief: Session Persistence in Stingray Traffic Manager document describes the behavior of the session persistence cache in detail, and considers what happens when it fills up and the least-recently-used entries are discarded. You can instrument the number of entries in the cache and the age of the oldest one using the SNMP or Activity Monitor counters:
In the first 4 minutes, traffic is steady at 300 new sessions per minute and the session cache fills. Initially, the max age grows steadily but when the cache fills (after 2 minutes) the max age remains fairly stable as older entries are dropped. In the last minute, no new entries were added, so the cache remains full and the max-age increases steadily.
