Interesting bits from ISA documentation

Pulled some items worth review from the ISA documentation. Here are some sizing parameters and other random pieces that jumped out today:

 

Using the /3GB Boot.ini Switch

For large systems with over 2 GB of memory, Windows Server 2003 and Windows 2000 Advanced Server offer the 4GT RAM tuning feature. This feature divides a process memory space into 3 GB for application memory and 1 GB for system memory. This feature enables processes to benefit from more than 2-GB RAM in user space, and is enabled by adding the switch /3GB to the Boot.ini file. (For details, see article Q171793, "Information on Application Use of 4GT RAM Tuning," in the Microsoft Knowledge Base.)

This feature may be beneficial for ISA Server, especially for reverse caching hosting a large Web site. However, using this feature reduces the maximum size of the nonpaged pool (to 128 MB instead of 256 MB), hence the maximum number of concurrent TCP connections.

 

MSDE logging vs. File logging

In comparing the two methods, MSDE has more features, but it uses more system resources. Specifically, you can expect an overall 10 to 20 percent improvement in processor utilization when switching to file logging from MSDE.

 

Connections and some virtual stats

Measurements of a remote procedure call (RPC) over Secure HTTP (HTTPS) publishing scenario on a dual-core, dual-processor 2.2 GHz server with 8 GB of RAM showed the following:

•		A single installation of ISA Server on a host computer handled 40000 concurrent connections with approximately 2 GB of virtual memory.
•		Three ISA Server computers installed on three virtual operating systems handled 60000 concurrent connections with only 1.3 GB used by each virtual computer. This model could be scaled out to more virtual computers (for example, four, eight, and so on) depending on the amount of RAM and the processing power of the hosting server. The tests were run on three computers.
•		CPU utilization in both cases was almost the same.

 

Scaling Out ISA Server - Using Windows Network Load Balancing

NLB is implemented at the operating system level. It provides evenly distributed load balancing and supports fault tolerance. (Other servers in the cluster can detect a failing server and distribute its load between them.) However, it requires CPU processing overhead (approximately 10 to 15 percent for common ISA Server scenarios), and has a limit to the number of members in the cluster (approximately 8 computers as the recommended maximum).

 

NLB requires 15 percent performance overhead when enabled. An NLB array with a single member will perform 15 percent less than the same array with NLB disabled. Therefore, when estimating capacity with NLB scale-out, it is necessary first to factor down the throughput values for a single computer by 15 percent, and then apply the scale factors.