Like most server applications serving numerous client requests, ISA Server performance also benefits from higher CPU speed, larger processor cache, and improved system architecture:

• CPU speed. As in most applications, ISA Server benefits from faster CPUs. However, increasing CPU speed does not ensure a linear increase in performance. Due to the large and frequent memory access effect, increasing CPU speed may cause more wasted idle CPU cycles when waiting for memory.
  
• L2/L3 cache size. Dealing with large amounts of data requires frequent memory access. An L2/L3 cache improves the performance on large memory fetches.
  
• System architecture. Because ISA Server transfers large data loads between network devices, memory, and the CPU, the system elements around the CPU also have an effect on ISA Server performance. A faster memory front side bus and faster I/O buses improve overall capacity.
  

CPU bottlenecks are characterized by situations in which\Processor\% Processor Time performance counter numbers are high while the network adapter and disk I/O remain well below capacity. In this case, (which is the ideal CPU-maximized system), reaching 100 percent means that the CPU power must be increased, either by upgrading to a faster CPU, or by adding more processors. For information about CPU scaling options, see Scaling Out ISA Server in this document. If ISA Server continues to have high response times, but low CPU percentages, the bottleneck is elsewhere.

Hyper-threading capabilities can also aid in lowering CPU utilization levels when consuming no more than 60 percent of the CPU. At higher CPU utilization levels, enabled hyper-threading will consume the same processing power as with disabled hyper-threading.

ISA Server memory is used for:

• Storing network sockets (mostly from a nonpaged pool)
  
• Internal data structures
  
• Pending request objects
  

In Web proxy caching scenarios, memory is also used for:

• Disk cache directory structure
  
• Memory caching
  

Because ISA Server handles numerous simultaneous connections requiring system nonpaged memory, the limiting memory factor is the size of the nonpaged pool, which is implied by the total memory size. For Microsoft Windows Server® 2003 and Windows® 2000 Server operating systems, minimum and maximum values of nonpaged pool size are shown in the following table.

When Web caching is not enabled, 512 MB should be enough for single processor computers, 1,024 MB is sufficient for dual processor computers, and 2,048 MB is sufficient for a dual processor dual core computer. These amounts can also store the full memory working set capacity.

The most critical evidence that memory is not tuned correctly, is when \Memory\Pages/sec (measuring hard page faults per second) is large (above 10) during peak loads. If this happens, the first action depends on whether Web caching is enabled:

1. If Web caching is disabled, you must determine if more physical memory is needed by monitoring the memory used by all processes in the system. The following performance counters will assist you:
   
   \Memory\Pages/sec\Memory\Pool Nonpaged Bytes\Memory\Pool Paged Bytes\Process(*)\Working Set

2. If Web caching is enabled, first try to lower memory cache size to 10 percent of physical memory. If hard page faults still occur, proceed with step 1.
   

Virtual Server Deployment

Note:

The installation of ISA Server 2006 on Microsoft Virtual Server 2005 R2 is supported. Because the Windows operating system that hosts Virtual Server cannot be protected by ISA Server on a virtual server, ISA Server in a Virtual Server environment should not be used in an edge firewall scenario, and this configuration is not supported. You can use this configuration securely in other scenarios, such as:

• A production deployment in which ISA Server on Virtual Server provides Web proxy services such as forward proxy, publishing, and caching, and is protected by an edge firewall, such as an additional ISA Server computer or array.
  
• A laboratory deployment
  

If you encounter high \Process\wspsrv\Virtual Bytes performance counter values (values of 1,800,000,000 (1.8 GB) indicate that there may be a problem), you may consider using ISA Server on Virtual Server 2005 R2, as an alternative to buying another ISA server computer:

• Define the number of guest operating systems hosted by the virtual server. After virtual bytes exceed 1.8 GB, you should consider adding a virtual operating system to the computer after adding 2 GB of random access memory (RAM).
  
• Add RAM to the host computer (2 GB for each guest operating system).
  
• Install Microsoft Virtual Server 2005 R2 on your server. For details, see the Microsoft Virtual Server Web site. Follow the performance recommendations at Microsoft Help and Support.
  
• Install guest operating systems.
  
• Install and configure ISA Server on each guest operating system.
  
• Use an external load balancer, for example, Domain Name System (DNS) round-robin hardware based or Windows Network Load Balancing (NLB), to spread traffic among the ISA Server computers.
  

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.
  

Every network device that exists on a connection has its capacity limit. These include the client and server network adapters, routers, switches, and hubs that interconnect them. Adequate network capacity means that none of these network devices are saturated. Monitoring network activity is essential for assuring that actual loads on all network devices are below their maximum capacity.

There are two general cases where network capacity impacts ISA Server performance:

• ISA Server is connected to the Internet using a WAN link. In most situations, the Internet connection bandwidth sets the limit for the amount of traffic. It is probable that the cause for weak performance during peak traffic hours is over-utilization of the Internet link. This also applies to a branch office scenario, where branch office ISA Server computers are connected to the ISA Server computer at headquarters over a slow link.
  
• ISA Server is connected only to LANs. In this case, it is important to have an infrastructure to support maximum traffic requirements. However, in most situations, this is not a concern due to the low price of 100-Mbps and 1-Gbps LANs.
  

To monitor network activity, use the performance counter:\Network Interface(*)\Bytes Total/secIf its value is more than 75 percent of the maximum bandwidth of any network interface, consider increasing the bandwidth of the network infrastructure that is not adequate. Or, consider using the ISA Server 2006 advanced features as detailed in BITS Caching and HTTP Compression in this document.

ISA Server uses disk storage for:

• Logging firewall activity
  
• Web caching
  

If both are disabled or if there is no traffic, ISA Server will not perform any disk I/O activity. In a typical setup of ISA Server, logging is enabled and configured to use Microsoft SQL Server™ 2005 Desktop Engine (MSDE 2005) logging. For most deployments, a single disk is enough to serve the maximum logging rate. If Web caching is enabled, disk storage capacity must be planned carefully as explained in Web Caching in this document.

The limiting factor of any disk storage system is the number of physical disk accesses per second. This number varies according to how random these accesses are, and how fast the physical disk spins. Usually, the limit is between 100 to 200 accesses per second. The performance counter to use for monitoring the disk access rate is:\PhysicalDisk(*)\Disk Transfers/secIf this limit is reached on a disk for a sustained period of time, you can expect the system to slow, which you will notice by an increase in system response time. To remove this bottleneck, the immediate solution is to lower disk accesses by adding more physical disks.

Another cause for a high disk access rate is hard page faults. For troubleshooting this situation, see Web Caching in this document.

Organizations with enterprise-scale capacity requirements may consider deploying an ISA Server computer as a dedicated Internet edge firewall acting as the secure gateway to the Internet for all corporate clients. To maintain high throughput levels of hundreds of Mbps between the internal networks and the Internet, ISA Server can be configured to provide packet level and stateful transport layer filtering only.

The more advanced application level filtering that ISA Server provides will be enabled on the second layer of defense, which is comprised of back-end firewall ISA Server computers.

The next line of defense for enterprise-scale organizations includes several ISA Server computers that are deployed as departmental or back-end network firewalls that provide secure inbound and outbound access control into and out of protected LANs. Organizations with existing firewall infrastructures may keep their current high-performance firewalls at the Internet edge and offload sophisticated application layer filtering to ISA Server computers at the LAN edges. This would allow an organization to utilize current high-speed Internet connections while benefiting from the unique level of protection provided by ISA Server 2006 application layer filtering capabilities.

From a performance perspective, a departmental firewall is required to sustain only a portion of the total traffic going through the edge firewall, allowing for more resource-consuming security features to be running, such as application filters.

ISA Server can be used to securely connect branch office networks to a main office using site-to-site virtual private network (VPN) connections. In this deployment, ISA Server is placed at a branch office where it acts both as a firewall protecting the branch office network and as a VPN gateway connecting the branch office network to the main office network.

In general, a transport level filtered site-to-site VPN consumes only 25 percent of the processing power per unit of traffic that is required for application level filtered Internet access.

Note:
In a transport level filtered site-to-site VPN, the traffic going through the tunnel is not inspected by application level filters. Application level filtering for site-to-site VPN traffic, like any other traffic, is enabled on a per-protocol basis.

This section provides scenarios for forward proxy, transparent proxy, and reverse proxy.

Forward Proxy

Transparent Proxy

Reverse Proxy

Web caching is a feature for improving the performance of ISA Server in all Web proxy scenarios. But the performance improvement impact is different when enabling the cache for the outbound scenarios (forward and transparent proxy) and the inbound reverse proxy scenario.

The main difference between forward (transparent) and reverse caching is the purpose of the cache. Forward (and transparent) caching is intended to save Internet bandwidth costs and to reduce response time by placing popular cacheable content near users. Reverse caching is used for offloading the back-end Web servers. Reverse caching has no effect on response time, and will even increase latency for objects that are not cached.

In terms of savings, forward caching saves access attempts to Web servers on the Internet by serving those attempts from the cache, thus saving on required Internet link bandwidth. For example, if the cache byte hit ratio is 20 percent and peak throughput on the internal links is 10 Mbps, the peak throughput on the Internet link would be only 8 Mbps.

Note:
Cache object hit ratio is the proportion of objects that are served from the cache out of the total objects that are served by the proxy. Likewise, cache byte hit ratio is the proportion of bytes that are served from the cache out of the total bytes that the proxy serves. Common average values are approximately 35 percent object hit ratio and approximately 20 percent byte hit ratio.

Reverse caching helps in consolidation of Web servers, reducing both hardware and management costs. For example, if 80 percent of a Web site’s data is static and cacheable, and a dynamic object requires four times more CPU cycles as compared to a static object, utilizing a reverse proxy will reduce the number of Web servers by 50 percent.

Note:
Suppose a static object requires X CPU cycles, and a dynamic object requires 4X cycles. If 80 out of 100 requests are static, the total number of cycles required for 100 requests is 80X + (100-80)4X = 160X, and 50 percent of those utilized for static content will be served by an ISA Server cache.

Another difference between forward cache and reverse cache is the magnitude of the cached working set. In reverse cache, the size of the client working set is unlimited, but the server working set contains only several Web sites and a relatively small number of objects. In most cases, ISA Server can be designed with reasonable memory and disk space to store all the hosted cacheable content in its cache, so that only dynamic uncacheable content is directed to the hosted Web servers. Preferably, all cache can be kept and served in memory.

In forward cache, the server space contains a limitless number of Web sites and Web objects, so the cache working set is limitless. To hold such a large working set, you must define large disk caches. The next sections describe how to plan and tune Web cache capacity for forward and reverse caching.

Tuning Forward Cache Memory and Disks

In forward caching, object hit ratio and peak HTTP request rate are used to determine the number of necessary disks according to the following formula:

Number_of_Disks = (Peak_request_rate X Object_hit_ratio) / 100

For example, if peak request rate is 900 requests per second and object hit ratio is 35 percent, four disks are required.

Note:
The number 100 in the preceding formula is empirical and means that the average performing physical disk (spinning up to 10,000 revolutions per minute) can serve 100 I/O operations per second. A faster disk spinning at 15,000 revolutions per minute can do 130—140 I/O operations per second.

We recommend using dedicated disks of the same type and of equal capacity. If a RAID storage subsystem is used, it should be configured as RAID 0 (no fault tolerance). Small disks, preferably no more than 40 GB, are recommended.

Tuning cache memory is more complicated. In cache scenarios, memory is used for:

• Pending request objects. The number of pending request objects is proportional to the number of client connections to the ISA Server computer. In most cases, it will be less than 50 percent of client connections. Each pending request requires approximately 15 KB. For 10,000 simultaneous connections, the Web proxy memory working set has no more than 50% × 10,000 × 15 KB = 75 MB allocated for pending request objects.However in an RPC over HTTP or HTTPS publishing scenario, all connections have a pending request object. Following the previous example, a total of 100% × 10,000 × 15 KB = 150 MB is allocated for pending request objects.
  
• Cache directory. The directory containing a 48-bytes entry for each cached object. The size of the cache directory is directly determined by the size of the cache and the average response size. For example, a 50-GB cache holding 7,000,000 objects (approximately 7 KB each on average) requires 48 × 7,000,000 = 336 MB.
  
• Memory caching. The purpose of memory caching is to serve requests for popular cached objects directly from memory lowering disk cache fetches. But because cacheable content is unlimited in forward caching, the memory cache size has a limited effect on performance.
  

By default, the memory cache is 10 percent of total physical memory, and is configurable. In general, we recommend using the default setting unless hard page faults occur. Hard page faults cause severe performance degradation. The easiest way to fix this situation when using caching is to lower the size of the memory cache.

Considering this information, use the following process for tuning cache memory size:

1. Tune disk cache size, as explained in the preceding section.
   
2. Estimate required memory as the total of:
   
   1. Pending request objects (50% × 15 KB × peak-established-connections).
      
   2. Cache directory size (48 × URLs-in-cache).
      
   3. Memory cache size (by default, 10 percent of total memory).
      
   4. System memory requires approximately 50 MB plus 2 KB per connection (50 MB + 2 KB × peak-established-connections).
      
   5. At least 100 MB for other processes running in the system.
      
3. Monitor memory usage and change memory cache size accordingly. The informative performance counters are:
   
   \ISA Server Cache\Memory Cache Allocated Space (KB)\ISA Server Cache\Memory URL Retrieve Rate (URL/sec)\ISA Server Cache\Memory Usage Ratio Percent (%)\ISA Server Cache\URLs in Cache\Memory\Pages/sec\Memory\Pool Nonpaged Bytes\Memory\Pool Paged Bytes\Process(WSPSRV)\Working Set\TCP\Established Connections

Tuning Reverse Cache Memory and Disks

Background Intelligent Transfer Service (BITS), introduced in ISA Server 2004 Service Pack 2 (SP2) and included in ISA Server 2006, enables the caching of HTTP range requests for Windows Update. BITS provides a significant savings in bandwidth consumption and shortens the delay for downloading updates in low-bandwidth deployments, which is important due to the growing demand for updates through the Web.

Measuring BITS caching performance showed the following:

• BITS caching doubles the overall hit ratio during the monthly update process from 10 percent to 20 percent. During the monthly update, there was a savings of 18 percent of total traffic.
  
• Traffic handled with BITS caching performs much better than other Web traffic, due to the extremely high average throughput per connection and hit ratio. For example, on the same hardware, BITS caching can serve three or four times more bits at the same processor utilization as compared to Web traffic handled without BITS. Enabling BITS caching for Windows Update has no negative impact on the performance characteristics of traffic that is not associated with Windows Update.
  

ISA Server 2006 provides a Hypertext Transfer Protocol (HTTP) compression feature. When HTTP compression is configured, ISA Server can compress content, to preserve limited bandwidth. This is useful, for example, in scenarios where a main office proxy routes Internet requests directly to the Internet, and branch offices route their requests through the main office, over a bandwidth-limited network. The feature uses a well known compression algorithm (GZip) to compress HTTP data, while compression ratio varies according to target data type. (As a default, only text-based data is compressed.)

Note:
When ISA Server Web filters inspect the incoming compressed content, the compressed content will be decompressed. When decompressed, the content is stored in the cache as decompressed text. If ISA Server receives a request for the cached content, it recompresses it before sending, which increases response time.

Measuring HTTP compression over a 56-Kbps line with 50-millisecond (msec) latency, connecting an ISA Server computer at headquarters to multiple ISA Server computers at branch offices, and passing a total of 96 Mbps (uncompressed) data showed:

• HTTP compression has the most impact on a slow network. It improves the network utilization by 28 percent, and thus improves the total system throughput.
  
• Latency between the headquarters and branches improved by a factor of 15.
  
• CPU impact added by enabling HTTP compression on the tested system (dual Xeon 2.4 GHz) was 15 percent.
  

There are many methods for performing Web authentication, and each has its own performance impact. The following table summarizes the advantages and disadvantages of each method.

From a performance perspective, an authentication scheme performs best with no per request overhead, and a low per batch overhead. Deciding which authentication scheme to use depends on strength and infrastructure.

Also, Web proxy authentication can be configured on the Web proxy listener level or on a rule level. Choose the listener level only if authentication is required for all Web access. Otherwise, choose the rule level, which means that authentication will be performed only when necessary according to rules.

Like application filters, Web filters may also have an impact on performance, depending on what they do. ISA Server incorporates several Web filters that perform specified tasks. Of these, the most CPU consuming are the HTTP filter and the Link Translation filter.

An HTTP filter inspects every Web request and response, checking that they comply with normal HTTP protocol usage. It is enabled by default, and its default configuration provides size limits to HTTP headers and the URL. Other available features include blocking by methods, extensions, headers, and HTTP payload signatures. These functions have no performance impact when selected, except for signature blocking, which requires 10 percent more CPU cycles. An HTTP filter is recommended for protecting Web traffic.

Link translation is used specifically in Web publishing scenarios. It looks in HTML response bodies, searching for absolute hyperlinks, and changes them to point to the ISA Server computer instead. By default, link translation scans HTTP headers and response bodies, so there is noticeable performance impact. When body scanning is enabled, it scans by default only HTML content, causing an overall 15 percent increase in CPU utilization.

When you deploy ISA Server with secure Web publishing, secure Web clients on the External network can connect to the SSL port. SSL bridging is a feature of ISA Server, which enables you to specify how ISA Server communicates with the back-end Web server that is published. This feature lets you choose between the following two types of bridging:

• SSL-to-SSL bridging. In this type of bridging, ISA Server accesses the back-end server with SSL. ISA Server performs separate SSL handshakes with the back-end server and must use encryption for every packet that it receives from or sends to the back-end server.
  
• SSL-to-HTTP bridging. In this type of bridging, ISA Server accesses the back-end server in clear, unencrypted HTTP.
  

SSL-to-SSL bridging strengthens the security on the Internal network, but adds the processing cost of double encryption to every packet that is transferred between ISA Server and the back-end server. SSL-to-SSL bridging costs approximately 10 percent more than SSL-to-HTTP bridging.

To determine what size ISA Server computer you must have to support peak network traffic loads, you must first measure the typical kilobits per connection of your network traffic and then measure the total aggregate traffic. Use the following procedure to make these determinations:

1. Use the system performance monitor tool to monitor the network traffic of each application server for the peak two hours of server activity. Collect the following counters:
   \Network Interface\Bytes Total/sec. This is the counter of the interface that is published by ISA Server. Use the average value as the average throughput with the duration. This value is also used to calculate the total aggregate traffic.\TCPv4\Connections Active. The value of this counter is the total number of connections created during the monitoring session. To determine the average connections per second within this duration, you divide the difference between maximal and minimal values by the total duration. Calculate the number of kilobits per connection as: kilobits per connection = (bytes total per second × 8 per 1000) per (connections per second).
   
2. Determine the total average kilobits per connection as the weighed average of the kilobits per connection of each application server. The weight for each server is the throughput of that server divided by the total throughput of all servers.
   
3. Determine the total aggregate traffic by adding the traffic measured on each server.
   
4. Use the following table to determine the number of megacycles that are required for every megabit of SSL traffic that ISA Server processes, according to the kilobits per connection measured in Step 2.
   

   Kilobits per connection	100 (Outlook Web Access)	200(Web)	500(RPC over HTTP)
   1 processor, SSL to HTTP	91	77	69
   1 processor, SSL to SSL	120	96	83
   2 processors, SSL to HTTP	128	104	91
   2 processors, SSL to SSL	142	120	104

5. To determine the processor speed that is required to support the total aggregate traffic, multiply the megacycles per megabit, from the table in Step 4, by the total throughput, as measured in Step 3.
   

   Note:
   Because of the variety of ISA Server configurations, usage scenarios, and hardware platforms, the numbers previously cited are for estimation purposes only. For deployments with Internet link bandwidth larger than 10 megabits per second, we recommend pilot testing to verify these estimates.

For example, suppose that the kilobits per connection calculated in Step 2 is 200, the total aggregate throughput is 15 megabits, and you require ISA Server to perform SSL-to-SSL bridging. From the preceding table, a single processor requires 96 megacycles per megabit or 96 × 15 = 1440 megacycles for 15 megabits per second. A single Intel Pentium 4 processor running at 2.4 GHz is sufficient for this load and is used at 1440 / 2400 = 60% at peak throughput. A dual processor computer with two Intel 2.4-GHz Pentium 4 processors requires 120 megacycles per megabit or 120 × 15 = 1800 megacycles for 15 megabits per second and is used at 1800 / (2 × 2400) = 38% at peak throughput.

The following table shows the amount of traffic in megabits that a 2.4-GHz processor can process at maximum recommended usage (80 percent).

This table is specifically for deployments in which ISA Server is used only for SSL traffic. If you plan to deploy ISA Server for both SSL and unencrypted HTTP traffic, you can estimate the processing power you require by calculating a weighted average of megacycles according to the amount of traffic for each scenario multiplied by the megacycles per megabit, shown in the following table.

For example, suppose that you want to deploy ISA Server in an edge firewall scenario in which 40 percent of the 20 megabit per second peak traffic is transparent proxy, 35 percent is forward proxy, and 25 percent is SSL to SSL with 200 kilobits per connection. The total amount of megacycles required for ISA Server to process this traffic on a single processor computer is:

megacycles = 20 megabits per second × (74 × 40% + 37 × 35% + 96 × 25%) = 1331

A 2.4-GHz Intel Pentium 4 processor is sufficient to process this load and is used at 1331 / 2400 = 55% at peak throughput. A dual processor computer requires 20 × (86 × 40% + 43 × 35% + 120 × 25%) = 1589 megacycles, which uses 1589 / (2400 × 2) = 33% of two 2.4-GHz Intel Pentium 4 processors at peak throughput.

Remote clients dialing in from the Internet use VPN remote access to access their corporate networks. Protocols that are used in remote access are Point-to-Point Tunneling Protocol (PPTP) and Layer Two Tunneling Protocol (L2TP) over Internet Protocol security (IPsec). Both of these protocols support compression, which is recommended because it saves bandwidth and processing power required for encryption.

To determine adequate capacity for an ISA Server VPN server, you first need to evaluate the maximum number of concurrent remote connections that your ISA Server computer needs to support. For example, if you expect to have no more than 5 percent of your organization’s employees establishing remote connections simultaneously, and your organization has 5,000 employees, 250 concurrent VPN remote access connections is the capacity you need.

The following table indicates the maximal number of concurrent VPN remote access connections supported by each hardware platform. These figures assume out-of-the-box ISA Server setup incorporating Web proxy filtering, MSDE logging, and compression for both PPTP and L2TP over IPsec protocols.

The following applies to the preceding table:

• Bandwidth figures are the required Internet link bandwidth. The actual bandwidth is twice the amount shown in the preceding table, due to compression.
  
• Bandwidth figures assume an average throughput of 30 Kbps per connection, approximately equivalent to a 56-KB dial-up connection.
  

In deployments where VPN clients can be trusted to a higher degree, application level filtering may be disabled, improving total capacity and loosening the security level. The next table shows the figures when Web Proxy Filter is disabled.

The following applies to the preceding table:

• The single Pentium 4 3-GHz processor is capable of reaching the maximum number of concurrent connections (1,000) in ISA Server 2006 Standard Edition. ISA Server 2006 Enterprise Edition has no such limit. ISA Server Enterprise Edition should run on Windows Server 2003, Enterprise Edition, because Windows Server 2003, Standard Edition has a limit of 1,000 connections.
  
• IPsec offloading hardware, available in many network interface adapters, may increase throughput values by 20 percent to 25 percent. Notice, however, that for Windows Server 2003, it is available for 100-Mbps network adapters only.
  
• The preceding table shows that for dual core architecture, the maximal connections number and throughput is lower than for dual processor architecture. This is related to processor affinity: When one core is at 85 percent utilization, and the other three cores are at 15 percent, a CPU bottleneck occurs. This problem can be resolved by applying interrupt affinity (using the Intfiltr.exe tool available at Windows Server 2003 Resource Kit Tools).
  

In a site-to-site VPN, there are two main choices from a performance and capacity perspective. One choice is using either PPTP or L2TP over IPsec. These protocols provide compression of the application traffic, which doubles the throughput that can be transferred through the site-to-site link. For example, sending a 2-MB file through a PPTP or L2TP tunnel will actually pass only 1 MB. The other choice is using IPsec tunneling, which does not incorporate compression. So in effect, PPTP and L2TP over IPsec save site-to-site throughput by 50 percent, as compared to IPsec tunneling.

With Web Proxy Filter disabled, L2TP over IPsec requires a single Pentium III 750-MHz processor for 15-Mbps application traffic. Passing this traffic in one direction requires only 7.5-Mbps link capacity due to compression. A single Pentium 4 3-GHz processor can handle up to 90-Mbps application traffic requiring T3 link capacity (45 Mbps). When Web Proxy Filter is enabled, a Pentium III 750-MHz processor can sustain 7-Mbps application traffic requiring 3.5-Mbps Internet link bandwidth, while a single Pentium 4 3-GHz processor handles 34-Mbps application traffic corresponding to 17-Mbps Internet bandwidth. Dual Xeon 3-GHz processors can handle 53-Mbps application traffic requiring 26.5-Mbps Internet link bandwidth. PPTP can handle approximately 15 to 20 percent more throughput for the same CPU consumption.

The second choice is using IPsec tunneling, which does not support compression, meaning that Internet link traffic is the same as application traffic. When working in conjunction with stateful filtering (Web Proxy Filter is disabled), IPsec tunneling can handle 10 Mbps on a single Pentium III 550-MHz processor and 52 Mbps on a single Pentium 4 3-GHz processor. With Web Proxy Filter enabled, the throughput figures are 4 Mbps, 18 Mbps, and 30 Mbps for the single Pentium III, single Pentium 4, and dual Xeon platforms respectively.

The following table summarizes these results—the supported actual megabits per second at 75 percent CPU utilization. (The numbers in parenthesis represent the uncompressed traffic volumes.)

IPsec offloading hardware, available in many network interface adapters, may increase throughput values by 20 percent to 25 percent.

Multiple Branches Site-to-Site VPN