If you missed the first part in this article series please read Optimizing ISA 2004 caching (Part 1).
This article will focus on ISA 2004, compression within ISA 2004 and modifications to features of ISA 2004 brought about by the introduction of ISA service pack 2.
There are two modes of caching; Active and passive caching. Active caching pre fetches content from the web server and caches it. Passive caching fetches content from the web server only when the user requests the content and then caches the content.
Passive caching is used to improve Internet access performance and to decrease the use of Internet bandwidth. The best way to understand the traffic needs to be pre fetched, one will need to setup logging, this in turn will help build a baseline, and it will help identify which traffic should be logged (the traffic that one would monitor is HTTP, HTTPS and FTP).
Performance impact on ISA
Most ISA scenarios only make use of one caching server but scenarios change and larger organizations have more scalable requirements. ISA is capable of handling more than 30,000 cached requests. It is recommended that performance monitoring be performed before going live. A stress test is an excellent way of ensuring that your hardware is able to perform.
To setup performance monitoring follow the below instructions:
- Open the Performance console from the Administrative Tools folder.
- Ensure that the Pages/sec counter is selected and press DELETE. Press DELETE two more times, deleting all the performance counters.
- Click the Add (+) button on the Performance console tool bar.
- In the Add Counters dialog box, in the Performance Object list, click ISA Server Cache.
- Click All counters, and then click Add.
- Click Close to close the Add counters dialog box.
- Press Ctrl-R to switch the performance view to a report view.
ISA Server Cache and Compression
ISA Server cache and compression work together to provide a more efficient serving of compression requests. The content is cached in one of three formats:
- Compressed: The content is requested and cached in compressed format.
- Uncompressed: The content is requested and cached in uncompressed format.
- Uncompressed and Uncompressible: If a request for compressed content is received, and it arrives at the cache uncompressed, it is stored in the cache as uncompressible. Subsequent requests received for the same compressed content enables ISA Server to recognize that the content is uncompressible, and ISA thus serves it from the cache uncompressed rather than from the Internet.
ISA 2004 sp2 support for BITS Caching
The Background Intelligent Transfer Service (BITS) aids in transferring large quantities of data without degrading network performance, thus maintaining efficiency of communication between networks. This is achieved through transferring data in small groups. By doing this, unused bandwidth is utilized as it becomes available. The groups of data are reassembled once their destination is reached in typical TCP fashion. This service is designed for Windows update and software update service, other content does not benefit from this feature.
HTTP Compression
HTTP compression decreases file size by using algorithms to do away with unnecessary data. These algorithms compress static files, and are able to perform on-demand compression of dynamically generated responses before sending them over the network. These same algorithms which are used to compress the files are also used to decompress the static files and dynamic responses. HTTP compression applies to all HTTP traffic passing through the ISA server.
Three Web filters are responsible for HTTP compression, they are listed below:
- Compression Filter
The compression filter is responsible for the compression and decompression of HTTP requests and responses. It is a high priority filter because it is responsible for decompression; and decompression is essential before an alternative web filter can be utilized. - Caching Compressed Content Filter
The Caching Compressed Content Filter does just what it says. It is responsible for caching of compressed content and serving a request from the compressed content in the cache. It is the filter with the lowest priority, because caching can take place after all other filters have handled the content. -
Range compression filter
Range compression is the compression of a specific portion of Web content. ISA Server supports range compression, thus it is a good practice to enable it between two ISA Server computers. It must be noted that range responses are not stored in the ISA sever cache.
Understanding the cache rules
ISA is made more adaptable through the addition of specific caching rules, if these rules are understood; ISA caching can be adapted to meet many requirements. Each caching rule allows for specific types of content to be processed in various ways. If the caching rules are not configured, default caching is enabled based on the defaults set in place by the ISA professional.
Each rule configured allows for the following customizations:
- Source and destination networks
- What types of items are retrieved and stored in the cache
- HTTP caching settings, such as the Time to Live (TTL) of objects retrieved
- File Transfer Protocol (FTP) caching settings
- Secure Sockets Layer (SSL)–specific settings
- Object size limitations
Deleting Cache Contents
ISA server stores cached content in a cache content file which resides in the URL cache folder on each drive that is configured for caching. With each start up of the Microsoft Firewall service, the cache content file on each drive is verified to ensure that it is present on the drives that are configured for caching. If it is found to be deleted new cache content file is automatically created.
The cached content stored in these files can be deleted manually by deleting all the cache content files and restarting the Firewall service.
Cache Array Routing Protocol (CARP)
In ISA Server 2004 Enterprise Edition, the Cache Array Routing Protocol (CARP) mechanism used hash-based routing that depended on the URL to determine which array member would handle the request. CARP exceptions were the sites that you wanted to be handled by a single array member. The array member that was assigned to handle the request was selected based on the host name as it appeared in the host header. This has changed in Service Pack 2, to better complement Internet Explorer functionality and provide better control over the distribution of requests that produce heavy Web traffic.
In Service Pack 2, the CARP hash-based routing uses the host name to determine which array member handles the request. CARP therefore assigns all of the requests for a particular host. This also maintains the context of the session, as the requests and responses are handled by a single array member. CARP exceptions are the sites that you want to be distributed to all array members, because they generate too much traffic to be handled by a single array member. For example, you may want all Microsoft update requests to be distributed, and not assigned to a single array member. You would therefore add the Microsoft Update site to the list of CARP exceptions.
Summary
In the second part of this series we covered performance improvements that can be implemented when using ISA 2004. We also saw modes of caching within ISA 2004 and improvements that were added to ISA 2004 in service pack 2. We looked at CARP and the enhancements it has over simpler strategies like ISA chaining. ISA caching performance needs to be closely monitored in order to achieve optimal performance.
If you missed the first part in this article series please read Optimizing ISA 2004 caching (Part 1).
){kind=link}