Optimizing ISA Server Performance


The word performance has different meanings to different people. To some, computer hardware or software performance refers solely to speed—how fast a computer can complete a specified task or operation, usually measured by some benchmark test.

Even though this is an ISA Server specific chapter, having good performance and benchmarks from any firewall is a good idea. Additionally, it may not strictly be the CPU you're benchmarking—you may also need to test the networking performance as well.

Note

A benchmark is a reference point or set of reference points against which something can be compared. This point or points can be a list of performance criteria a product is expected to meet, a set of conditions by which a product is measured, or a known product to which other products are compared.

A more generic definition of performance includes the total effectiveness of the computer's actions, taking into account such factors as availability, individual response time, cost effectiveness, and throughput.

Note

To understand the difference between speed and throughput, consider the task of downloading a file over a modem connection. The connection speed of 50Kbps refers to the rate at which a signal travels. The throughput refers to the actual amount of data that can be transferred across the link in a given time period. If many data packets are dropped or damaged, the throughput could be less than the speed. However, by using data compression technologies, you can achieve a throughput that is higher than the actual modem speed so that with a 50Kbps connection, you might be able to get a throughput of 100Kbps or more.

Optimizing performance involves finding a way to make all components of a system work together smoothly with the smallest possible amount of delay or downtime. As with any other computing component, the struggle to achieve and maintain optimum performance from your ISA server is a never-ending one.

Hardware specifications and condition, software configuration, and interaction with other networking components combine to determine the speed and efficiency with which your ISA servers do their jobs. In some cases, ISA's performance will be affected not only by the ISA Server software settings but also by other factors unique to your network's topology and configuration.

You should assess performance issues in the context of:

  • The server's hardware resources (especially RAM and processor)

  • Other services and applications running on the server

  • The network's physical limitations (speed supported by NICs, hubs, switches, and cabling)

  • Network protocols and services that could limit performance

  • Actual performance needs of your network

Before you can optimize the performance of an ISA server—or any other system component—you must first be able to do two things:

  • Establish criteria for what constitutes unsatisfactory, acceptable, or excellent performance.

  • Have a way to objectively measure your system's performance to determine whether it meets your established criteria.

The process of defining acceptable criteria is referred to as establishing a baseline. Then, you measure your network's performance by monitoring over a set period of time, and you compare the results to your baseline.

In the next section, we examine how to establish a performance baseline and how to use performance-monitoring tools such as the ISA Server Performance Monitor to gather information about the performance of individual components.

Establishing a Baseline and Monitoring Performance

A key factor in any performance-monitoring program is to establish a baseline. This is done by collecting information at intervals, averaged over a period of time when the network is performing normally. If you gather this information at different times of day over a period of weeks or even months, you will be able to ascertain the characteristics of normal network traffic patterns.

How Baselines Are Used

Baseline measurements are used to perform trend analysis, which is a fancy term for comparing performance measurements to your historical values in order to spot patterns or trends from which you can project future performance expectations or determine future needs.

Baselining is an important element of performance management and performance tuning.

Note

It might seem logical to perform your data collections at a time when the network is experiencing low usage, such as at night or on weekends. However, if you limit your information gathering to these times, you will not be able to get an idea of accurate traffic patterns. You must gather your data at different times—low usage, peak usage, and average usage—in order to establish a true baseline.

The component values to be measured are sometimes referred to as metrics. A metric is a measurement of a specific characteristic or component of a system's or software program's performance or efficiency. A separate baseline will be associated with each metric.

Defining Threshold Values

Creating the baseline gives you a road map of the normal patterns for your network's performance. After you have this guideline, you can set threshold values, which are measured values at which performance becomes unacceptable. Depending on what component is being measured, you may set rising threshold values, falling threshold values, or both. A rising threshold indicates a measurable point that, when exceeded, indicates unsatisfactory performance. A falling threshold is the opposite; it indicates a value that, when measurements fall below it, indicates unsatisfactory performance. Threshold values should be set based on the baseline data.

ISA Server's performance alerts can be set to recognize when a threshold value is passed and do one or more of the following:

  • Log an entry to the application event log

  • Send a network message

  • Start a performance data log

  • Run a specified program

Threshold values might have to be adjusted on a periodic basis as you continue to collect and analyze data. It is important to set threshold values appropriately. If the values are set too high (for rising values) or low (for falling values), you will not be notified of performance events in time to prevent an impact on your network's productivity. If values are set too low (for rising values) or high (for falling values), there will be too many notifications; administrators could be overwhelmed with messages and, like the boy who cried "wolf" in the old fairy tale, the notifications could soon come to be ignored.

The first decision to make in creating a performance-monitoring and tuning program is how you plan to collect the necessary data. Although third-party monitoring tools are available, Microsoft has provided a built-in solution that will meet many of your needs in monitoring the performance of your system as a whole and your ISA Server installation in particular. In the next section, we look at the Windows 2000 Performance console, which includes the System Monitor tool and the Performance Logs and Alerts. Then we look at the special implementation of Performance that is installed with ISA Server.

Using the Performance Monitor Tools

Windows 2000 provides the Performance MMC with all versions of the operating system. Performance has two components:

  • System Monitor This component is used to gather measurements of performance and activity in real time and view the data in graph, histogram, or report format.

  • Performance Logs and Alerts This component is used to record collected data to be viewed later and to set alerts to notify you or perform a specified task when a particular performance counter falls above or below the threshold you have set.

The Windows 2000 Performance MMC is accessed via the Start | Programs | Administrative Tools menu or by typing perfmon.exe at the command line. When you install ISA Server, a new icon is placed in the Start | Programs | Microsoft ISA Server menu. This icon opens the ISA Server Performance Monitor, shown in Figure 25.1, which is an implementation of the Windows 2000 System Monitor that includes a set of ISA performance counters as default objects.

click to expand
Figure 25.1: The ISA Server Performance Monitor Includes a Set of ISA Server-Specific Default Counters

The ISA Server Performance Monitor also allows you to add monitoring of other Windows 2000 components included in System Monitor (such as processor, memory, server service, TCP, the browser service, and many more) along with the ISA object counters.

Note

When you install ISA Server on a Windows 2000 machine, the ISA Server object counters are also added to the Windows 2000 System Monitor's list of counters that can be monitored. The advantage of the ISA Performance Monitor is that ISA objects do not have to be individually added for monitoring but are monitored by default.

If you are familiar with the Windows 2000 System Monitor (which replaced the Performance Monitor tool in Windows NT 4.0), you will find the ISA Server Performance Monitor very easy to navigate. By default, measurements are shown in graph view (which can be changed, as we discuss in the next section), with the line graph for each counter shown in a different color.

Customizing the View and Appearance of the System Monitor

Data collected by the System Monitor can be presented in one of three ways:

  • Graph (also called a chart) Data is shown as one or more line graphs, as shown in Figure 25.1.

  • Histogram Data is presented as one or more bar charts.

  • Report Data is summarized and presented as text information.

The line graph works best when you need to see immediate fluctuations in measurements in real time, because it traces the "peaks" and "valleys" over a period of time. The histogram is good for comparing the values of one counter to those of another at a given point in time. The report view gives you the exact numbers to work with in a form that is easy to understand at a glance. The histogram view is shown in Figure 25.2.

click to expand
Figure 25.2: In a Histogram View, Data Is Presented as a Set of Bar Charts

The report view is often the most useful for precise analysis of performance data, although perhaps less visually compelling. An example of the report view is shown in Figure 25.3.

click to expand
Figure 25.3: Report View Summarizes Data and Presents It in Text Format

Note

When you right-click System Monitor in the left console pane, you will see a selection called Properties; however, this choice will not open the System Monitor Properties sheet referenced here, nor will selecting Properties on the Action menu. Use the Properties icon in the toolbar to open the Properties sheet that allows you to configure these settings.

You can change the view in one of two ways:

  • Click the appropriate icon from the toolbar.

  • Select the view in the General tab of the System Monitor Properties sheet. The General tab of the Properties sheet is shown in Figure 25.4.

    click to expand
    Figure 25.4: The System Monitor Tool's Appearance Can Be Customized Using the Properties Sheet

In addition to changing the view for display of data, the General tab allows you to:

  • Select the display elements that will be shown. (By default, the legend, value bar, and toolbar are all displayed. To hide one or more, uncheck its box.)

  • Select the way data will be displayed in Report or Histogram view. (The Default value is the current value for activity being measured at that time, or the average for logged activity.) In Graph view, all these values are shown in the value bar beneath the chart.

  • A 3D or flat appearance. (3D is the default.)

  • Whether to show a fixed single border or no border. (None is the default.)

  • Whether to update the display automatically, and if so, how often. (In seconds; default is one second.)

  • Whether to allow duplicate counter instances to run simultaneously. (By default, this is allowed.)

Additional tabs on the Properties sheet allow you to do the following:

  • Source tab Specify whether the source of the data displayed on the System Monitor is to be current (real-time) activity or data from a log file (for which you can enter the path or browse). If you select a log file, you can also specify a time range within the file if you don't want to display the data for the entire time over which the log was recorded.

  • Data tab Allows you to add or remove counters from the display, specify the color assigned to each counter in the graph, and set the width and style of the graph line that represents each counter.

  • Graph tab Allows you to create a customized graph with an identifying title, select which elements to show (vertical grid, horizontal grid, vertical scale numbers), and set maximum and minimum values for the vertical scale.

  • Colors tab Allows you to customize the colors used for the grid, time bar, background, and foreground, as well as the system colors (menu bar, title bars, borders, scrollbars, and other system elements).

  • Fonts tab Allows you to specify font style and size for the display. The selected font will be applied to all text in the System Monitor display and will be used for the text in the Report view.

System Monitor Components

The Windows 2000 System Monitor and the ISA Server Performance Monitor work in an identical manner, using the following components:

  • Performance object This is a resource or service that can be monitored (for example, ISA Server Packet Filter and ISA Server Cache are two performance objects that can be monitored).

  • Performance counter This is a collection of data items associated with a performance object, for which the monitor can measure a value that corresponds to a particular aspect of the object's performance (for example, Total Dropped Packets and Total Logging Packets Lost are two performance counters associated with the ISA Server Packet Filter performance object).

    Note

    It is possible for an object counter to have more than one instance. For example, if you are monitoring processor performance and the machine has multiple processors, you can have an instance of each processor object counter for each of the processors.

The Default Performance Counters

The ISA Server Performance Monitor console differs from the Windows 2000 System Monitor in that it already has a set of default performance counters configured. Monitoring of these counters starts when you open the Performance Monitor. Let's take a look at each of these default counters (descriptions of these counters are also found in the ISA Server Help files, which often provide more detailed information than is available using the Explain button).

The following are Firewall Service counters:

  • Active Sessions This counter counts the number of active sessions for the Firewall Service. By comparing this counter at both peak and off-peak times, you can determine ISA Server usage patterns.

  • Active TCP Connections This counts the total number of active TCP connections.

  • Active UDP Connections This counts the total number of active UDP connections.

  • SecureNAT Mappings This Firewall Service counter tracks the number of mappings created by secure network address translation (SecureNAT).

The following are Web Proxy Service counters:

  • Cache Hit Ratio (%) This counter measures the relationship between two other Web proxy counters—Total Cache Fetches as a percentage of Total Successful Requests. This counter value, together with the value of Cache Running Hit Ratio, indicates how effectively the cache is performing. A high percentage for these counters indicates that a high level of requests is being serviced from the cache, meaning faster response times. A zero counter means caching is not enabled. A low counter can signal a configuration problem.

  • Cache Running Hit Ratio (%) This counter measures the number of requests served from the cache as a percentage of total successful requests serviced. This is the same as the ratio measured by Cache Hit Ratio (%). The difference between the two is that Cache Running Hit Ratio (%) measures the ratio for the last 10,000 requests serviced, and Cache Hit Ratio (%) measures the ratio since the last time that the Web proxy service was started.

  • Client Bytes Total/Sec This counter presents the sum of two other counters, Client Bytes Sent/Sec and Client Bytes Received/Sec, for a total rate for all bytes transferred between the ISA Server computer and Web proxy clients.

  • Current Average Milliseconds/Request This counter displays the average amount of time that it takes ISA Server to process a request. A low number indicates a faster response. A high number that remains high over a period of time indicates that ISA Server is working at maximum capacity, and you might need to add another server to the configuration.

  • Current Users This counter shows how many clients are currently running the Web proxy service. You can monitor this counter at peak and off-peak times to determine server usage.

  • Requests/Sec This counter indicates the rate of incoming requests made to the Web proxy service. A high value means that more ISA Server resources are required to service incoming requests.

The following are cache performance counters:

  • Disk Cache Allocated Space (KB) This counter measures how much space is being used by the disk cache. (This will be equal to or less than the amount of space you have configured for the disk cache.)

  • Max URLs Cached This counter presents the maximum number of URLs that have been stored in the cache.

  • Memory Cache Allocated Space (KB) This counter measures how much space is being used by the memory cache.

  • Memory Usage Ratio Percent (%) This counter calculates the ratio between the number of cache fetches from the memory cache and the total number of cache fetches. A high percentage could mean that you need to allocate more available memory resources to the cache. A low number could mean that some of the memory resources allocated to cache could be better used for other purposes.

  • URL Commit Rate (URL/Sec) This counter measures the speed at which URLs are written to the cache. Note that if this rate is comparable to the value of another ISA Server cache counter, Disk Failure Rate (Fail/Sec), a high proportion of attempts to write to the cache are failing, which might be due to a problem with cache configuration.

  • URLs in Cache This counter measures the current number of URLs that are in the cache.

The following is a packet filter counter:

  • Total Dropped Packets Displays the total number of packets that were dropped or filtered, for whatever reason.

Other ISA Performance Counters

The following performance objects are added to System Monitor when you install ISA Server:

  • Bandwidth Control Performance Counters

  • Cache Performance Counters

  • Firewall Service Performance Counters

  • Web Proxy Service Performance Counters

  • Packet Filter Performance Counters

  • H.323 Performance Counters

Let's take a look at the counters associated with each.

  • Bandwidth control performance counters Five performance counters are associated with the bandwidth control object:

    • Actual inbound bandwidth Measures the actual inbound bandwidth in bytes per second.

    • Actual outbound bandwidth Measures the actual outbound bandwidth in bytes per second.

    • Assigned connections Counts the number of connections with an assigned bandwidth priority.

    • Assigned inbound bandwidth Measures the assigned inbound bandwidth in bytes per second.

    • Assigned outbound bandwidth Measures the assigned outbound bandwidth in bytes per second.

  • Cache performance counters Twenty-two performance counters are associated with the ISA Cache performance object:

    • Active Refresh Bytes Rate (KB/Sec) Measures the rate at which bytes of data are retrieved from the Internet to actively refresh popular URLs in the cache. This will relate to the configuration set for active caching.

    • Active URL Refresh Rate (URL/Sec) Measures the rate at which popular cached URLs are actively refreshed from the Internet. This will relate to the configuration set for active caching.

    • Disk Bytes Retrieve Rate (KB/Sec) Measures the rate at which "bytes of data" are retrieved from the disk cache.

    • Disk Cache Allocated Space (KB) See the description under default counters.

    • Disk Content Write Rate (Writes/Sec) Measures the number of writes per second to the disk cache for the purpose of writing URL content to the cache disk.

    • Disk Failure Rate (Fail/Sec) Measures the number of input/output (I/O) failures per second. (An I/O failure occurs when ISA Server fails to read from or write to the disk cache.) A large number of I/O failures can indicate problems with disk cache.

    • Disk URL Retrieve Rate (URL/Sec) Measures how many URLs are sent to clients from the disk cache in one second and can be used to evaluate the performance of the disk cache.

    • Max URLs Cached See the description under default counters.

    • Memory Bytes Retrieved Rate (KB/Sec) Measures the rate at which bytes of data are retrieved from the memory cache.

    • Memory Cache Allocated Space (KB) ee the description under default counters.

    • Memory URL Retrieve Rate (URL/Sec) Measures how many URLs are sent to clients from the memory cache in one second.

    • Memory Usage Ratio Percent (%) See the description under default counters.

    • Total Actively Refreshed URLs Shows the cumulative number of popular URLs in the cache that have been actively refreshed from the Internet.

    • Total Bytes Actively Refreshed (KB) Displays the total number of bytes that have been retrieved from the Internet to actively refresh popular URLs in the cache.

    • Total Disk Bytes Retrieved (KB) Measures the cumulative number of disk bytes that have been retrieved from the disk cache. If you add the value of this counter to that of Total Memory Bytes Retrieved (KB), you will have the total number of bytes retrieved from the cache.

    • Total Disk Failures Measures the number of times that the Web proxy service failed to read from or write to the disk cache due to an I/O failure.

    • Total Disk URLs Retrieved Measures the cumulative number of URLs that have been retrieved from the disk cache. You can calculate the total number of URLs retrieved from cache by adding the value of this counter to that of Total Memory URLs Retrieved.

    • Total Memory Bytes Retrieved Measures the cumulative number of memory bytes that have been retrieved from the memory cache in response to client requests to the cache. A low value here could mean that memory resources allocated to the cache are not being used efficiently. A high number could mean that additional memory resources need to be allocated to the cache.

    • Total Memory URLs Retrieved Measures the cumulative number of URLs that have been retrieved from the memory cache in response to client requests to the cache.

    • Total URLs Cached Measures the cumulative number of URLs that have been stored in the cache. A low number might mean the cache size is too small.

    • URL Commit Rate (URL/Sec) See the description under default counters.

    • URLs in Cache See the description under default counters.

  • Firewall Service performance counters Twenty-five performance counters are associated with the Firewall Service object:

    • Accepting TCP Connections Shows the number of connection objects that wait for a TCP connection from firewall clients.

    • Active Sessions See the description under default counters.

    • Active TCP Connections See the description under default counters.

    • Active UDP Connections See the description under default counters.

    • Available Worker Threads Shows the number of firewall work threads that are available or waiting in the completion port queue.

    • Back-connecting TCP Connections Shows the total number of TCP connections awaiting an inbound connect call to complete. These connections are placed by the Firewall Service to a client after accepting a connection from the Internet on a listening socket.

    • Bytes Read/Sec Shows the number of bytes per second read by the data pump.

    • Bytes Written/Sec Shows the number of bytes per second written to the data pump.

    • Connecting TCP Connections Shows the total number of TCP connections that are awaiting completion between the Firewall Service and remote computers.

    • DNS Cache Entries Displays the current number of DNS domain name entries that are cached because of Firewall Service activity.

    • DNS Cache Flushes Shows the total number of times the DNS cache has been cleared by the Firewall Service.

    • DNS Cache Hits Shows the total number of times a DNS domain name was located in the DNS cache by the Firewall Service.

    • DNS Cache Hits % Calculates the percentage of DNS names serviced by the DNS cache from the total number of DNS entries retrieved by the Firewall Service.

    • DNS Retrievals Shows the total number of DNS names that the Firewall Service has retrieved.

    • Failed DNS Resolutions Shows the number of failed gethostbyname and gethostbyaddr API calls from the Firewall Service.

    • Kernel Mode Data Pumps Displays the number of kernel mode data pumps that have been created by the Firewall Service.

    • Listening TCP Connections Shows the number of connection objects that are waiting for TCP connections from remote Internet computers.

    • Memory Allocation Failures Shows the number of memory allocation errors.

    • Non-connected UDP Mappings Displays the number of mappings that are available for UDP connections.

    • Pending DNS Resolutions Displays the number of gethostbyname and gethostbyaddr API calls that have been made by the Firewall Service and are awaiting resolution.

    • SecureNAT Mappings See the description under default counters.

    • Successful DNS Resolutions Displays the number of gethostbyname and gethostbyaddr API calls that have been successfully resolved.

    • TCP Bytes Transferred/Sec by Kernel Mode Data Pump Shows the number of TCP bytes that have been transferred by the kernel mode data pump each second.

    • UDP Bytes Transferred/Sec by Kernel Mode Data Pump Shows the number of UDP bytes that have been transferred by the kernel mode data pump each second.

    • Worker Threads Displays the number of firewall worker threads that are currently active.

  • Web Proxy Service performance counters Fifty-one performance counters are associated with the Web Proxy Service performance object:

    • Array Bytes Received/Sec (Enterprise) Monitors the rate at which bytes of data are received from other ISA servers within an array.

    • Array Bytes Sent/Sec (Enterprise) Monitors the rate at which bytes of data are sent to other ISA servers within an array.

    • Array Bytes Total/Sec (Enterprise) Displays the sum reached by adding the Array Bytes Sent/Sec and Array Bytes Received/Sec, to give you the total rate for all bytes of data that are transferred between this ISA server and other array members.

    • Cache Hit Ratio (%) See the description under default counters.

    • Cache Running Hit Ratio (%) See the description under default counters.

    • Client Bytes Received/Sec Calculates the rate at which bytes of data are received from Web proxy clients. If this rate is consistently slow, a delay could be occurring in the servicing of requests.

    • Client Bytes Sent/Sec Calculates the rate at which bytes of data are set to Web proxy clients. As previously stated, a consistently slow rate could signal a delay in request servicing.

    • Client Bytes Total/Sec See the description under default counters.

    • Current Array Fetches Average (Milliseconds/Request) Displays the mean number of milliseconds required for servicing a Web proxy client request that has to be fetched through another member of the array (not including SSL tunnel requests).

    • Current Average Milliseconds/Request: See the description under default counters.

    • Current Cache Fetches Average (Milliseconds/Request) Displays the time, in mean number of milliseconds, that it takes to service a Web proxy client request from the cache (not including SSL tunnel requests).

    • Current Direct Fetches Average (Milliseconds/Request) Displays the time, in mean number of milliseconds, that it takes to service a Web proxy client request directly to the Web server or upstream proxy server (not including SSL tunnel requests).

    • Current Users See the description under default counters.

    • DNS Cache Entries Displays the number of DNS name entries cached by the Web Proxy Service (a high count usually means good performance, because the more entries in the cache, the fewer that require a DNS lookup, which takes additional time and resources).

    • DNS Cache Flushes Displays the number of times the name cache has been cleared by the Web Proxy Service.

    • DNS Cache Hits Displays the number of times a DNS name was found in the DNS cache by the Web Proxy Service. A low number of hits means that names must be looked up, which slows performance.

    • DNS Cache Hits (%) Displays the percentage of DNS entries that have been resolved using cached data. A high value indicates better performance.

    • DNS Retrievals Displays the number of DNS names that have been retrieved by the Web Proxy Service.

    • Failing Requests/Sec Calculates the rate per second for Web proxy requests that result in an error. A high failure rate could mean that the connection settings for incoming Web requests are not configured properly or that there is not enough connection bandwidth to handle all the requests.

    • FTP Requests Displays the number of FTP requests made to the Web Proxy Service.

    • Gopher Requests Displays the number of Gopher requests made to the Web Proxy Service.

    • HTTP Requests Displays the number of HTTP requests made to the Web Proxy Service.

    • HTTPS Sessions Displays the number of Secure HTTP (HTTPS) sessions that have been serviced by the SSL tunnel.

    • Maximum Users Displays the maximum number of users connected to the Web Proxy Service at the same time.

    • Requests/Sec Calculates the rate of incoming requests to the Web Proxy Service. A high number could mean that you need to allocate additional ISA Server resources.

    • Reverse Bytes Received/Sec Calculates the rate at which bytes of data are received by the Web Proxy Services from Web publishing servers in response to incoming requests.

    • Reverse Bytes Sent/Sec Calculates the rate at which bytes of data are sent by the Web Proxy Services to Web publishing servers in response to incoming requests.

    • Reverse Bytes Total/Sec Displays the sum resulting from the addition of the two preceding counters to provide a total rate of bytes transferred between the Web Proxy Service and the Web publishing servers in response to incoming requests.

    • Site Access Denied Displays the number of Web sites to which the Web Proxy Service has denied access. If this number is high, you might want to re-evaluate your Web access policy.

    • Site Access Granted Displays the number of Web sites to which the Web Proxy Service has granted access.

    • SNEWS Sessions Displays the number of SNEWS sessions serviced by the SSL tunnel.

    • SSL Client Bytes Received/Sec Displays the rate at which SSL data is received by the Web Proxy Service from secure Web proxy clients.

    • SSL Client Bytes Sent/Sec Displays the rate at which SSL data is sent by the Web Proxy Service to secure Web proxy clients.

    • SSL Client Bytes Total/Sec Calculates the sum resulting from adding the two preceding counters to provide a total rate for all SSL bytes transferred.

    • Thread Pool Active Sessions Displays the number of sessions that are being actively serviced by thread pool threads.

    • Thread Pool Failures Displays the number of requests that have been rejected because of a full thread pool.

    • Thread Pool Size Displays the number of threads in the pool, representing the resources that are available for servicing client requests.

    • Total Array Fetches (Enterprise) Displays the number of Web proxy client requests served by requesting data from another ISA server that is a member of the array, as a result of the CARP algorithm.

    • Total Cache Fetches Displays the number of Web proxy client requests served from cached data.

    • Total Failed Requests Displays the number of requests that the Web Proxy Service has failed to process because of errors. A high value could indicate configuration problems or that the connection is too slow.

    • Total Pending Connects Displays the number of waiting Web Proxy Service connections.

    • Total Requests Displays the number of requests made to the Web Proxy Service, the result of adding the Total Successful Requests and Total Failed Requests counters.

    • Total Reverse Fetches Displays the number of incoming request that have been served by requesting data from Web publishing servers.

    • Total SSL Sessions Displays the number of SSL sessions serviced by the SSL tunnel.

    • Total Successful Requests Displays the number of requests made to the Web Proxy Service that have been successfully processed.

    • Total Upstream Fetches Displays the number of requests serviced by getting the data from the Internet or from an upstream chained proxy server.

    • Total Users Displays the total number of users that have connected to the Web Proxy Service over the history of the service.

    • Unknown SSL Sessions Displays the number of unknown SSL sessions that have been serviced by the SSL tunnel.

    • Upstream Bytes Received/Sec Calculates the rate at which bytes of data are received by the Web Proxy Service from servers across the Internet or upstream chained proxy servers.

    • Upstream Bytes Sent/Sec Calculates the rate at which bytes of data are sent by the Web Proxy Service to servers across the Internet or upstream chained proxy servers.

    • Upstream Bytes Total/Sec Displays the result of adding the two preceding counters to provide a total rate for bytes transferred between the Web Proxy Service and Internet or chained proxy servers.

  • Packet filter performance counters Four performance counters are associated with the packet filter performance object:

    • Packets Dropped Due to Filter Denial Displays the number of packets that are dropped because the data was rejected due to dynamic packet filtering when the default "deny all" policy is set in the ISA Server configuration.

    • Packets Dropped Due to Protocol Violations Displays the number of packets that are dropped for reasons other than the default filtering rules (such as those rejected because of intrusion detection).

    • Total Dropped Packets Displays the total number of packets dropped, for whatever reasons.

    • Total Lost Logging Packets Displays the number of packets that cannot be logged.

  • H.323 performance counters Only two performance counters are associated with the H.323 filter performance object:

    • Active H.323 Calls Shows the number of H.323 calls that are currently active.

    • Total H.323 Calls Displays the total number of H.323 calls that have been handled by the H.323 filter from the time the ISA server was started.

Understanding ISA Performance Logs

In addition to viewing the performance data in real time using the System Monitor component of the ISA Performance Monitor, you can record this data for later viewing using the Performance Logs functionality. Logs provide administrators with a permanent record and are useful for establishing and storing baseline data. You can create logs to record the data that is collected over time and analyze it to come up with your baseline values against which subsequent performance measurements will be compared.

Note

You can view the performance data in real time at the same time the data is being written to a log.

Logging runs as a service, so it is not necessary for a user to be logged on to the computer for the log to be written. Logged data can be saved as comma-delimited or tab-delimited text files, which can be imported into a spreadsheet program such as Excel or a database program such as Access. Logs can also be saved in binary format, which is used for circular logging. Circular logging is the action of writing the log continuously to a single file, overwriting the older data when the file reaches its maximum size.

You can configure two types of logs with the ISA Server Performance Monitor. In this section, we look at how to create and configure counter logs, which log data using the ISA performance counters discussed in the previous section.

The second type of log that the ISA Server Performance Monitor allows you to configure is called a trace log. Trace logs are triggered by specific system events. A trace log records data when the specified event occurs, rather than logging at specified intervals, as counter logs do. The trace log records data that is collected by the operating system or a program or service (called the provider), such as Kerberos, NetLogon, or the Active Directory Service. Trace logs are often used in troubleshooting situations.

Trace logs are configured similarly to counter logs. You will be asked to specify enabled providers and configure a filename, location, and maximum file size, as with counter logs. Trace logs can be saved as two types: sequential or circular. Sequential logging starts a new log when the maximum file size is reached (numbering the logs to distinguish them from one another). Circular logging overwrites the older data in the single log file when the maximum size is reached.

In trace logging, data is temporarily saved to memory buffers before being written to the log file. You can set a buffer size and minimum and maximum number of buffers, and you can specify that data be transferred from the buffers to the log file at specific intervals. (The default setting is to transfer the data to the file only when the buffers are full.)

Trace log output is interpreted by a parsing tool, which can be created by developers using the APIs available on the Microsoft Web site.

To create a counter log, follow these steps:

  1. In the left console pane of the ISA Performance Monitor MMC, expand Performance Logs and Alerts and right-click Counter Logs, and then select New Log Settings.

  2. You will be asked to provide a name for the new log. Type in your log name.

  3. On the General tab of the New Log Properties sheet, you must add at least one counter to be logged. You can then set the interval at which the data should be sampled, as shown in Figure 25.5. (The default interval is every 15 seconds, but you can set intervals in seconds, minutes, hours, or days.)

    click to expand
    Figure 25.5: Add at Least One Counter to Be Logged to the File

  4. On the Log Files tab, you can set the location and filename for the log file, and if you want, you can specify that the log filename end with the date, selecting the date format (month/day/hour, month/day/hour/minute, year/day, year/month, year/month/day, or year/month/day/hour). You can also specify the use of a numeric sequence (default) and where to start numbering the log files (the default is 1). This is used to distinguish between multiple logs with the same name logged at different times or days.

  5. Also on the Log Files tab, select the file type in which the file will be saved. Your choices are:

    • Text File CSV (comma-delimited text)

    • Text File TSV (tab-delimited text)

    • Binary File

    • Binary Circular File

    Binary files are saved with the .BLG extension.

  6. Finally, at the bottom of the Log Files sheet, you can allow log files to grow to the maximum limit, or you can set a maximum size for the file in kilobytes (if you choose to set a specific limit, the default is 1,000KB), as shown in Figure 25.6.

    click to expand
    Figure 25.6: Use the Log Files Tab to Set Filename, Location, and Other File Properties

    Note

    It is a good idea to specify a limit for the log file size; otherwise, the log file can grow until you run out of disk space, interfering with other operations.

  7. The last tab, labeled Schedule, is used to set the start and stop times for logging if you choose not to start and stop the logging manually (which is the default setting). If you set times, you can also specify what happens when a log file is closed—whether to start a new log file and whether to run a program (which you specify), as shown in Figure 25.7.

    click to expand
    Figure 25.7: Use the Schedule Tab to Define Start and Stop Times for Logging

  8. Click OK when you finish configuring the log file properties, and the new file will appear in the right detail pane when you select Counter Logs in the left console. You can change the configuration by right-clicking it and selecting Properties, or you can stop the logging activity by selecting Stop in the right context menu. To view the log, access it in the location you specified for it to be saved. (Use a text editor such as Notepad to view the raw data in the .CSV or .TSV files, or import the file into a spreadsheet or database for viewing.)

To create and use logging, you must have the appropriate permissions. In order to create a new log or make changes to an existing log configuration, you need to have Full Control permission to the Registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SysmonLog\Log\Queries. Members of the Administrators group have Full Control Permission for this key by default, but if you need to give a user permission to create or change log files and you do not want to grant other administrative privileges, you can use the Security menu in the Registry editing tool Regedt32.exe to do so. As always, exercise caution when editing the Registry.

You also need to have the right to start or configure services on the Windows 2000 or later release computer in order to run the service that runs in the background when you configure a log file. Again, members of the Administrators group already have this right by default. You can give users this right via Windows Group Policy.

Setting ISA Performance Alerts

Although you can monitor whether and when your performance thresholds are reached by enabling logging and reviewing the performance logs, in many instances it is important for an administrator to be made immediately aware when the threshold value has been reached. This is the case, for example, if a critical service fails or if free disk space reaches a low level that could threaten normal operations of the server. You can use alerts to notify administrators so that the problem can be addressed immediately and unpleasant consequences prevented.

Performance alerts can be set to perform a selected action when a performance counter reaches the defined threshold value.

Warning

Don't confuse the performance alerts, which are configured on performance counters via the ISA Performance Monitor MMC, with the ISA Server alerts that are triggered by designated ISA events and conditions and are configured via the ISA Server Management Console.

To configure a performance alert, right-click Alerts under Performance Logs and Alerts in the left console pane of the ISA Server Performance Monitor MMC. The first step in creating a new alert is to assign it a name. You'll note that there is no wizard to walk you through the process, as there was when you configured ISA Server alerts. Instead, you will configure the performance alert via a three-page Properties sheet.

On the General tab, shown in Figure 25.8, you can optionally enter a comment to further identify the alert. You then must add one or more counters that will be monitored for triggering of the alert.

click to expand
Figure 25.8: Counters to Be Monitored for Triggering of a Performance Alert Are Added Via the General Tab of the Alert Properties Sheet

To add a counter, click the Add button, and select:

  • Whether to use local computer counters or those on another computer (in which case, you must specify the UNC path for the computer to be monitored)

  • The performance object to be monitored

  • The counter(s) to be monitored (or you can select to monitor all counters for that object)

Once you have selected an object and counter(s) to be monitored, you need to configure the threshold value as well as how often data should be sampled, as shown in Figure 25.9.

click to expand
Figure 25.9: After Adding Counters, You Must Define the Threshold and Data Sample Interval

As you can see in Figure 25.9, you can set the alert to be triggered when the value is either over or under a specified limit. In our example, we have elected to monitor the Active Sessions counter for the ISA Server Firewall Service performance object. We have set the alert to be triggered when the threshold value (the number of active sessions) is over the limit of 100.

The data sample interval has been left at the default setting: sample data every 5 seconds. This value can be set in seconds, minutes, hours, or days.

Next, you must specify on the Action tab of the Properties sheet the action that should take place when the alert is triggered. As shown in Figure 25.10, you can select one or more of the following:

click to expand
Figure 25.10: You Can Select One or More Actions to Be Taken When the Alert Is Triggered

  • Log an entry to the Application event log (accessed via Event Viewer).

  • Send a network message to a specified computer or user account (you must enter the name of the account).

  • Start a performance data log.

  • Run a program, such as a script or batch file (you can enter the path or browse for the program file).

If you choose to run a program, you can specify one or more of the following command-line arguments:

  • Single argument string

  • Date/time

  • Measured value

  • Alert name

  • Counter name

  • Limit value

  • Text message

On the Schedule tab, you can set a time to start and stop the scan, or you can choose to start and stop it manually using the shortcut menu. By checking the check box shown in Figure 25.11, you can also specify that when a scan finishes, a new scan should be started.

click to expand
Figure 25.11: You Can Use the Schedule Tab to Schedule the Scan to Start and Stop at a Specified Time and Elect to Start a New Scan When One Finishes

After you have finished configuring the alert, it will appear in the right detail pane in the ISA Server Performance Monitor MMC when you select Alerts in the left console pane. If you elect to send a message to your user account or computer account when the alert is triggered, you will receive a message, as shown in Figure 25.12.

click to expand
Figure 25.12: A Network Message Is Sent to the Specified Account When the Alert Is Triggered

Note that the Windows Messenger Service is used for sending notifications. In order for alert notifications to be received, the Messenger Service must be running on the recipient's computer as well as the ISA server.

Addressing Common Performance Issues

In this section, we look at a few of the common performance issues related to ISA Server and what you can do to prevent them and/or to address them if they do occur on your network. Specifically, we discuss:

  • Network bandwidth issues

  • Load-balancing issues

  • Cache configuration issues

We also show you how you can edit the Windows 2000 Registry to tune your ISA Server performance settings.

Addressing Network Bandwidth Issues

Network bandwidth usage is dependent on several factors: available bandwidth, number of users, type of usage, and timing of usage.

Performance Tuning for User Capacity

You can set the array properties to automatically optimize performance based on the number of users per day. To do so, right-click the name of the array in the left console pane of the ISA Management MMC, and select Properties. Select the Performance tab on the Properties sheet, as shown in Figure 25.13.

click to expand
Figure 25.13: ISA Automatically Optimizes Performance Based on Number of Users Per Day

Set the slider to one of the following settings, as appropriate for your organization:

  • Fewer than 100

  • Fewer than 1000

  • More than 1000

Performance will be tuned for all the servers in the array in accordance with the setting.

Determining Effective Bandwidth

The effective bandwidth is defined by Microsoft as the actual bandwidth for a specific connectivity device such as a modem or ISDN terminal adapter, or the total effective network bandwidth.

To determine the effective bandwidth, you should find out the maximum effective bandwidth for all the connections on the ISA server or array. For a dial-up device, the effective bandwidth will vary depending on several factors:

  • Maximum rated speed of the device (for example, a 56K analog modem or a 128K ISDN terminal adapter).

  • Maximum speed of the port to which the device is connected, for external modems and TAs; this speed is based on the UART chip and the limitations on port speed set in Windows (see the sidebar).

  • Line condition; analog phone lines that are "dirty" (in other words, lines that have a high degree of noise or interference) will not support the top speeds attainable by your modem and port.

  • Data compression allows actual throughput to exceed the top supported speed.

The universal asynchronous receiver-transmitter (UART) chip built into the motherboard or serial port card handles serial communications between the computer and an external modem or other serial device. Internal devices have their own UART chips built into their circuit boards. The UART chip limits the amount of data that can be transferred through the port. A high-speed UART (16650bps) will enable faster communications. Some manufacturers make super high-speed or enhanced serial ports (ESPs) that have a large buffer to increase data flow.

However, the speed of the hardware device doesn't matter if the software caps the speed at which the serial port can communicate. Windows 2000 and Windows Server 2003 allows you to set the port speed, using the General tab on the modem's Properties sheet. You can select a maximum port speed from 300bps to 115,200bps. In order to change this setting, you must be logged on with administrative privileges.

Setting Effective Bandwidth Limits

You can specify an effective bandwidth for a dial-up device by following these steps:

  1. Under the server or array name in the left console pane of the ISA Management MMC, expand Policy Elements and click Dial-up Entries.

  2. In the right detail pane, right-click the dial-up entry pane for which you want to specify an effective bandwidth.

  3. Click Enable bandwidth control on the Bandwidth tab.

  4. Enter the desired effective bandwidth in kilobits per second (for all devices in the array) in the Effective Bandwidth field, as shown in Figure 25.14.

    click to expand
    Figure 25.14: Enable Bandwidth Control and Set Effective Bandwidth for a Dial-Up Entry

You can also set effective bandwidth for a network card in a similar way. To do so, right-click Bandwidth rules in the left console pane, select Properties, and choose Enable bandwidth control on the General tab. You can then enter the desired bandwidth in kilobits per second in the Effective bandwidth field.

The purpose of the bandwidth control feature in ISA Server can be confusing. The name might seem to imply that it allows you to allocate a specific amount of bandwidth to a specific user, group, or application. In fact, ISA bandwidth control does not limit how much bandwidth can be used; rather, it uses the Windows 2000 QoS packet-scheduling service to set priorities on network connections. Connections that have associated bandwidth rules will be scheduled ahead of those without associated rules (default priority connections).

In order to set bandwidth rules, bandwidth control must be enabled. Effective bandwidth is the actual bandwidth for the specified device. ISA uses your specifications in the effective bandwidth field on the Bandwidth tab of the Properties sheet to determine the actual bandwidth that will be assigned, taking into account the bandwidth priority that is specified for the rule.

When determining effective bandwidth for a modem, you must consider several factors:

  • Speed of the modem

  • Compression

  • Phone-line condition

For Frame Relay connections, the ISP will determine the maximum effective bandwidth. Bandwidth is set in the same way as for a network card.

The steps in setting effective bandwidth are:

  1. Determine the maximum bandwidth of all the connections on the ISA server.

  2. Monitor performance for peak-hour activity and generate reports.

  3. Analyze, based on the reports, how much bandwidth is actually allocated for all requests (on both the internal and external cards).

When ISA Server returns cached content to a computer on the internal LAN, bandwidth rules will not be applied.

Note

Configure the effective bandwidth, specifying the minimum bandwidth (the lowest maximum) available for all devices on the ISA server. For example, if the effective bandwidth for the modem is 56Kbps, that is the value that should be configured for the effective bandwidth, even though another device (such as the internal network card) has a higher effective bandwidth.

Addressing Load-Balancing Issues

Load balancing refers to a method of spreading the processing workload across multiple machines, for better performance and fault tolerance. ISA Server allows you to configure the load factor by dividing the ISA tasks among members of an array. Windows 2000 Advanced Server, Datacenter Server, and Windows Server 2003 include a feature called Network Load Balancing, or NLB, to enhance availability and performance for mission-critical servers. NLB is a means of clustering multiple computers running TCP/IP, allowing the group of computers to be addressed by the same cluster IP addresses. The NLB service distributes incoming client requests across the cluster of computers. You can configure the load weight of each server or distribute the load equally among all servers in the cluster.

In this section, we discuss:

  • How to configure the load factor in an ISA Server using CARP

  • Interaction between ISA Server and Windows NLB

Note

Prior to the release of Windows 2000, Microsoft called the Network Load Balancing service Windows Load Balancing, or WLB.

Configuring the Load Factor in an ISA Server Using CARP

When the Cache Array Routing Protocol (CARP) is enabled on an ISA Server computer, you can configure the servers in the array so that they have different loads by setting the load factor. Why would you want to do this? All servers are not created equal, and if some of your servers have larger hard disks, for example, you might want those servers to handle a larger amount of the cache load. Changing the load factor increases or decreases the proportion of the load for a specific ISA server.

To configure the load factor, select the Computers container object in the left console pane of the ISA Management MMC. In the right detail pane, you will see a list of the servers that belong to the array. Right-click the name of the server for which you want to configure the load factor, and select Properties. Select the Array Membership tab, as shown in Figure 25.15.

click to expand
Figure 25.15: The Load Factor Is Configured on the Array Membership Tab of the Computer's Properties Sheet

Note

By default, CARP is enabled for outgoing Web requests and is disabled for incoming requests. The load factor configuration is a global setting; that is, it cannot be set separately for incoming and outgoing requests but is applied to the requests for which CARP is enabled.

In the Load Factor field, specify a value relative to the other array members. The value should be between 0 and 100. A load factor of 0 would prevent this computer from handling any of the load.

ISA Server and Windows 2000 Network Load Balancing

If you are using Windows 2000 NLB on your network, you should not enable CARP on incoming Web requests. The reason for this is that the load-balancing driver will determine to which server the requests should be directed and route each request to one of the servers in the array.

External clients will not have the autoconfiguration script, so they can't perform resolution themselves. Thus, it is more efficient, from a performance standpoint, to have CARP disabled for external (incoming) requests, because it will result in the eventual caching of the Web objects on each of the servers.

Note that, for internal clients, the autoconfiguration script performs basically the same task as NLB; the Web proxy client has a list of all members of the array, and if the first doesn't respond, it tries another. This system provides fault tolerance. The firewall client, however, doesn't have the array information, so NLB is useful for fault tolerance.

ISA Server's load-balancing support enhances its scalability, making it especially suitable for use with large, high-traffic Web sites.

Cache Configuration Issues

Performance—specifically, Web performance—is the purpose of ISA Server's caching functionality. Performance can be improved by properly configuring the cache settings. In this section, we look at how you can improve performance by configuring RAM caching and how access to frequently used objects can be improved by configuring active caching. We also discuss how performance is impacted by the hard disk on which the cache is stored.

Improving Performance by Configuring RAM Caching

Because RAM is faster than hard disk speeds, objects that are cached in RAM can be retrieved faster than those that are cached on the disk. ISA Server caches objects in both locations; by default, objects that are less than 12,800 bytes in size are cached in RAM as well as being cached on the hard disk. If an object is larger than this, it is only cached to the disk.

If your ISA server has a large amount of RAM, you can improve performance by increasing the maximum size for objects that can be cached in RAM. To do so, right-click Cache Configuration in the ISA Management MMC left console pane, and select Properties.

Select the Advanced tab on the Properties sheet. In the field labeled Maximum size of URL cached in memory, enter a new size in bytes (see Figure 25.16). You can also change the percentage of free memory that can be used for caching.

click to expand
Figure 25.16: You Can Increase Performance by Increasing the Size of Objects That Can Be Cached in RAM

Improving Performance by Configuring Active Caching

Active caching is a means of speeding up access to files that are accessed frequently, by automatically refreshing the content of such objects when they are soon to expire. ISA automatically goes out onto the Internet and retrieves these objects based on the active caching settings. Active caching improves clients' Web performance, and because it works at off-peak hours when network activity is low, when properly configured it should not cause a hit on overall network performance. Microsoft allows you to configure settings in accordance with these factors that are most important in your situation.

One issue to consider is freshness of objects in cache. If an object is in cache and its TTL hasn't expired, the client will get the cached object and not the page on the Web site, which might have changed. The need for the most current content must be balanced against the desire for higher performance.

To enable active caching, select the Active Caching tab on the Cache Configuration Properties sheet and check the check box (by default, active caching is disabled), as shown in Figure 25.17.

click to expand
Figure 25.17: Active Caching Balances Client Web Performance Against Network Traffic

You can choose one of three settings:

  • Frequently All the most popular objects will be downloaded to the cache regularly, so they are not allowed to expire. This makes it more likely that a client request will be in the cache.

  • Normally Objects will be updated frequently, but network performance is also considered.

  • Less Frequently Some popular objects will be cached automatically; however, network load/performance will be given top priority.

If client Web performance is most important, choose the first setting. The second (Normally) is the default setting.

Performance Issues Associated with Passive Caching Settings

The settings on the HTTP tab control passive caching behavior. These settings allow you to control the expiration of objects in cache. You can select from three standard settings:

  • Frequently (objects expire immediately)

  • Normally

  • Less frequently

A fourth option is to set a specific TTL for objects in cache. The settings you select here can adversely impact performance in conjunction with the settings you have configured for active caching. For example, the worst possible combination of settings for cache performance would be to select Less frequently on the Active caching page and Frequently on the HTTP page. In this case, the TTL for objects in the cache will expire immediately, but the automatic update of objects by active caching will occur on a less frequent basis. Thus, ISA Server will have to go out on the Internet to retrieve objects requested by clients rather than being able to return them from cache.

Improving Performance by Cache Drive Configuration

You are prompted, during the installation of ISA Server in cache or integrated mode, to select the disk partition(s) on the local computer on which the cache will be stored. This partition must be formatted in NTFS.

For best performance, the cache should be stored on a physical disk that is fast and a different disk from those on which the Windows 2000 operating system and the ISA Server software are installed.

Note

Disk speed is indicated by seek time in milliseconds (for example, 9ms; a lower number indicates a faster disk) and rpm (for example, 7200rpm; a higher number indicates a faster disk). SCSI disks are generally faster than IDE disks.

By default, the installation program sets a default cache size of 100MB on the largest NTFS partition on the computer. You can cache the cache drive(s) by expanding the Cache Configuration object in the left console pane of the ISA Server Management MMC, selecting Drives, and double-clicking the server name in the right detail pane. This sequence displays the server's drives Properties sheet, shown in Figure 25.18.

click to expand
Figure 25.18: You Can Change the Cache Drive Settings for Better Performance

You need to know which drive letter represents a partition on which of your physical disks in order to choose the best location for the cache. You also need to know where your <systemroot> directory is located and to which disk ISA Server was installed.

Note

The ISA Server cache can only be assigned to partitions that have designated drive letters, although Windows 2000 allows you to format a partition without a drive letter and mount it to an NTFS folder.

Editing the Windows 2000 Registry to Tune ISA Performance Settings

Several settings can be used to fine-tune performance that cannot be configured via the ISA interface. Changing these settings requires that you edit the Windows 2000 Registry.

Warning

It is always imperative that you exercise caution when making any changes to the Registry. Incorrectly editing the Registry can create serious problems or even render your system unbootable. It is wise to back up valuable data prior to modifying the Registry.

To make these changes, you can use either of two Registry editing tools provided with Windows 2000: Regedit or Regedt32. You can start either one by typing its name at the Run prompt.

The Registry keys that you can edit to tune the performance of your ISA server are located in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services path, shown in Figure 25.19.

click to expand
Figure 25.19: The Registry Keys Used to Tune ISA Performance Are Found Under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services

The following keys can be configured for ISA performance optimization:

  • \W3Proxy\Parameters\OutstandAccept The value set for this key controls the number of accepted pending connections before new connection requests are rejected. A high value minimizes the number of rejected connection requests.

  • \Tcpip\Parameters\MaxUserPort The value set in this key controls the number of TCP/IP ports that can be allocated by a client making a connection request. Setting the value to 0000ffff in hexadecimal (65,535 in decimal) sets the range for client port numbers to the maximum.

The following keys can be added (Edit | New | Key in the Registry Editor menu) and configured for optimum performance:

  • \W3PCache\Parameters\TZPersistIntervalThreshold This key can be used to set a maximum time interval in minutes that will be lost when cache is recovered after the W3Proxy service is stopped unexpectedly.

  • \W3Cache\Parameters\RecoveryMruSizeThreshold You can use this key to set a time interval in minutes in which the content cached will be recovered first from the time the W3Proxy service is stopped unexpectedly.

  • \W3Proxy\Parameters\MaxClientSession You can use this key to control the size of the pool for the client session object. A client session object will be freed and its memory returned to system memory management only if the pool has a number of objects that exceeds this value. Freeing objects is time consuming, so you can cause objects to be freed less frequently by setting this key to a high value.

  • \Tcpip\Parameters\TcpTimedWaitDelay This value sets a time interval in seconds that will pass before a socket is reused for a new connection.

    Note

    In most cases, after you make a change to Registry settings, you must restart the computer in order for the changes to be applied.

For general information on the TCP/IP Registry keys and what they do, see the Microsoft white paper entitled MS Windows 2000 TCP/IP Implementation Details on the Microsoft Web site at www.microsoft.com/technet/ itsolutions/network/deploy/depovg/tcpip2k..asp. Information for Windows Server 2003 is available at www.microsoft.com/technet/prodtechnol/ windowsserver2003/plan/TPCIP03.asp.

There are also a number of Web sites that provide information on how to tweak Registry settings to provide for higher performance with cable modems and DSL connections.

Some vendors provide optimization software that can be used to change these settings using a friendly interface. For example, Accelerate 2000 (www.webroot.com) helps you optimize MTU and other TCP/IP settings for maximum connection speed.




The Best Damn Firewall Book Period
The Best Damn Firewall Book Period
ISBN: 1931836906
EAN: 2147483647
Year: 2003
Pages: 240

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net