The following list should be considered as guidelines or rules of thumb based on our collective experience. They should not be considered hard-limits or guarantees, they are what we think would perform well in terms of subscriber experience. The main design goals are to keep a certain balance between subscriber counts, subscriber networks and CPU cores. There is no theoretical maximum subscriber limit but in our experience keeping it below 2500 per network insures smooth operation, preferably even around a thousand subscribers. The number of subscriber networks has a performance relationship with the number of CPU cores available; a subscriber network doesn't 'reserve' a CPU core but we tend to provision between 0.5 and 2 CPU cores per network. Reducing the overbooking of cores/network ratio gives you more headroom in subscriber count per network or allows you to employ subscriber 'heavy' features (ie. non-URL based content-filtering). Subscriber networks with no connected subscribers idle networks consume little performance and shouldn't be accounted for.
On smaller installations we typically see higher core/network ratios due to a single or maybe two subscriber network, this allows them to deviate from the 'guideline' and connect more subscribers on a single/few network(s) since there are more CPU cores working the instances. Larger appliances such as the 5000 and upwards typically deploy between four and sixteen networks because they need to spread high subscriber counts accross multiple subscriber networks accross the physical CPU cores.
During a fail-over the failed machine is tasked with synchronizing it's user-data and bringing it's network interfaces down. This is a sequential process where the total number of subscriber networks largely dominate fail-over converge-time. At the same time the newly active machine brings it's interfaces back on-line and signs in all active subscribers. The second main factor is the number of active subscribers the system has to bring back online. The performance cost of a bringing a single subscriber back online is determined by the presence of a wan-load-balancing, network-policy, content-filter, QoS policy and one-to-one NAT policies. Currently we wouldn't recommend deploying over twenty-four subscriber networks on a clustered machine to make sure a configuration change doesn't trigger a cluster fail-over.
Tools → Download Log. If they are large (multiple GB) download and erase them (or contact us).
System → Task Manager(5.1 and higher)
Important Do not run mixed HSMX versions in cluster.