|
|
|
|
|
Basic server cluster settings
Enabled
Indicates whether the server cluster is enabled or not. Clicking the light will toggle on/off. Disabling a server cluster will stop all domains / virtual paths that rely on it.
Name
The name of the server cluster. This name is purely for your convenience, and it's not used by the server. But a good name will make your site easier to maintain - especially if you use several clusters.
Session Timeout
When OctaGate Switch™ uses Load Balancing, it keeps track of sessions so that a user will redirected to the same server for the duration of the session. Once a Load Balancing Session has been inactive for a period of time, the connection will be dropped. Session Timeout determines how long a connection should be inactive before it's dropped. The value is measured in seconds, and 1800 seconds equals 30 minutes. Setting this value to something extremely large (a month perhaps) would make OctaGate Switch™ needlessly use large amounts of RAM to keep track of old sessions. Setting the value to something very small (1 minute) would mean that the user would be hopping from server to server after short periods of inactivity. How long is apropriate for the Session Timout value will depend on your server needs.
Load Averaging Period
To determine which server a new session should be assigned to, OctaGate Switch™ keeps track of the load of each server. The Load Averaging Period determines how long a period load should be averaged over. If you set this value to 60 seconds, it will mean that the load of the last minute will determine which server is considered the lightest loaded. If you set the value to 300 seconds, the load of the last five minutes will be used to determine the load. How long is apropriate for the Load Averaging Period value will depend on your server needs.
Session Method
Use the session method to pick how to identify a session. The options are;
| · | Peer IP Number - the IP number of the peer identifies the session
|
| · | Persistent session cookies - a browser cookie identifies the session. If the user opens a second browser the same cookie will be used - the user can only have one session. If the user closes his browser, the cookie will be stored until he opens his browser - thus the session survives.
|
| · | Transcient session cookies - a browser cookie identifies the session. If the user opens a second browser a new cookie will be created and the user can have any number of sessions against the load balanced cluster. If the user closes his browser the cookie will be destroyed.
|
Which you should chose will depend on your situation. But the basic heuristic is as follows;
| · | If you know that each user will have a unique IP number you should use "Peer IP Number"
|
| · | If you know that a great many users will have the same IP number (because they're behind the same NAT for instance), then you should avoid PeerIPNumber
|
| · | If you can guarantee that all users allow cookies, then you can use either of the cookie methods. If you can't guarantee that users will allow cookies, you should use "PeerIPNumber".
|