Understanding ISA Web Proxy service Performance counters.

By /

In this tutorial I will cover a theoretical overview of the importance of why you need to monitor your ISA servers. I will highlight the Web Proxy service counters available and mention some political strategy on dealing with users that abuse the system. Further down I will also outline what counters that I will cover in the following tutorials. I will cover how best to read these counters in the next tutorial. I will describe what use the counters have to you as the IT professional tasked with the responsibly of the upkeep of your organizations ISA server.

The importance of ISA server performance monitoring.

ISA server performance monitoring is not a complex operation, but requires your dedication and understanding of the counters and the product being monitored. It also requires you to know what the baseline is when comparing your everyday results and trends to representation of what a normal ISA server should look like when ISA is humming away unstressed.

There are many products out there that can monitor your server and also inform you if your services are up. In most organizations the Firewall, web proxy and the mail server are of paramount importance and users (the people that pay the IT staffÒs salaries) do not tolerate much down time. Then does it not spring to mind that we should proactively be looking at our ISA servers knowing when if it will fall over due to hardware restraints?

In many organizations, reports are a vital part of the IT professionalÒs daily weekly monthly and quarterly job function. Management need to know if they have to dish out extra cash on upgrading hardware or if you can make do with the current hardware that you already have for the next business year. The only accurate way of measuring this is to use either 3rd party tools that have been built to access and monitor your ISA server, or the built in tools that Microsoft has provided you with when you bought your ISA server software.

When do you upgrade and how to deal with the politics?

As a general rule I always look at the logs rather sparingly and only upgrade if I feel that the server is being excessively hammered, and only if there is nothing I can do about it. What I mean by this is that if there are people using the proxy server and I look at the logs and see that the users are abusing the service visiting sites that have nothing to do with the general business, going to unsolicited sites or reading personal HTML mail regularly with large attachments, downloading MP3Òs, games, movies, large zip files even virus pattern files. Then I normally approach management and inform them. In about 3 weeks time management usually has forgotten what the IT guy told them, and then they ask you the same question again. At this point I do a cost analysis of what it will cost the company in terms of upgrading the server or servers or just telling the users that abusing the service is unacceptable and that they should be working instead of downloading massive amounts of data daily. This approach normally works and the problem is sorted out with great ease.

Within large organizations this method will prove to be harder to implement as is it will be quite difficult to monitor which users are abusing the service. It is good practice to just take the top ten internet users and let management know who they are. You normally find them reoccurring and management will sort them out if they see it fit.

As a general rule I look at the counters and look if they keep peaking at about 80% if there is a constant rate of 80% of more utilization of the specific counter, then I do something bout it or begin to plan an upgrade immediately. Before I plan an upgrade I approach management and let them know that an upgrade for the 5000 users will cost them their right arm and their left leg. They quickly ask who is using the Internet and what their users doing on the Internet?

I then prepare the logs in a more readable and corporate friendly format and email it to them. Management then normally write a Corporate memo stating that the Internet usage is a corporate privilege and that any abuse will result in revocation of this privilege. This scare normally lasts 6 months until the policy is released and then all is well.

Navigating to the performance counters

To open the ISA performance monitor follow the diagram below.

Please note: the default counters are loaded when opening the ISA Server performance monitor, other counters can be added by clicking on add like in the diagram.

The main types of performance counters categories are listed below the others are pretty general.

1. Web Proxy service performance counters

2. Bandwidth control performance counters

3. Cache performance counters

4. Firewall service performance counters

5. H.323 filter performance counters

6. Packet filter performance counters

7. Default counters

Web Proxy Service (W3PROXY.EXE)

1. This service allows any CERN client the ability to access internet resources using the HTTP, HTTPS, Gopher and FTP protocols on behalf of the client.

2. It is an application level service that uses CERN-compliant applications and is configured to use the Web proxy service. It functions irrelevant of the OS.

3. Web proxy service runs as a Win2k process (W3proxy.exe).

4. ISA uses Secure Web publishing and reverse hosting to send requests to Web-publishing servers connected behind the ISA proxy computer, without compromising the internal LAN security.

5. The Web proxy service supports SSL and Web (ISAPI) filters.

6. The Web proxy service includes the ISA cache.

To see how the Web Proxy service interacts with other ISA services checkout my Understanding ISA services tutorial. Click on the link below. http://www.isaserver.org/authors/magalhaes/tutorials/Understanding ISA services.htm

Here is a summary of the web proxy service performance counters for easy reading and quick perusal. I have also added relevant information pertaining to everyday usefulness of these counters. This is a summarized version of the counters descriptions found in the ISA help files, I have gone through them and taken out only the relevant information.

Web Proxy service performance counters

Performance counter

Description

Array Bytes Received/Sec (Occurs only in Enterprise)

The rate at which bytes are received from ISA Servers within the same array. Useful in branch environments

Array Bytes Sent/Sec (Occurs only in Enterprise)

The rate at which bytes are sent to other ISA Servers within the same array. Useful in branch environments

Array Bytes Total/Sec (Occurs only in Enterprise)

The sum of Array Bytes Sent and received/Sec between the ISA Server and other members of the same array. Useful in branch environments

Cache Hit Ratio %

Displays % of Web Proxy client requests that have been served using cached data. This value is an indication of the effectiveness of the cache. A high counter will indicate faster response times. A zero counter indicates that caching is not enabled, or may indicate a configuration problem. The cache size may be too small, or requests may not be cacheable.

Cache Running Hit Ratio (%)

Measures total requests served from the cache as a percentage of total successful requests serviced.

Client Bytes Received/sec

Displays bytes received and directly related to the amount of requests from Web Proxy clients. A consistent slow rate may indicate a delay in servicing requests.

Client Bytes Sent/Sec

Displays bytes sent to Web Proxy clients.

Client Bytes Total/Sec

The sum of all bytes sent and received between the ISA Server and Web Proxy clients.

Current Array Fetches Average (Milliseconds/Request)

Displays average number of milliseconds taken to service a Web Proxy client request through other array members. Excludes SSL requests.

Current Average Milliseconds/Request

Average number of milliseconds to service a Web Proxy client request, excludes SSL. This counter is useful to check a peak times to measure if ISA can handle the request strain.

Current Cache Fetches Average(Milliseconds/Request)

Average number of milliseconds to service a Web Proxy client request from cache. Excludes SSL.

Current Direct Fetches Average (Milliseconds/Request)

Average number of milliseconds to service a Web Proxy client request directly from a Web server or upstream proxy. Excludes SSL.

Current Users

Current clients using the Web Proxy service. Peak hours can be deduced from this counter. Note: ISA lets you specify maximum concurrent connections.

DNS Cache Entries

Current number of DNS entries cached by the Web Proxy service. A high count increases performance, because no DNS lookup is necessary.

DNS Cache Flushes

Number of times DNS cache has been flushed or cleared by the Web Proxy service.

DNS Cache Hits

Number of times a DNS name was found in the DNS cache by the Web Proxy service. Avoid DNS lookups, use DNS cache to improve overall performance.

DNS Cache Hits%

Displays DNS entries resolved using cached data. If this value is high there is low DNS resource overhead and the cache is being used properly.

DNS Retrievals

Displays all DNS names retrieved by the Web Proxy service.

Failing Requests/Sec

Displays a per second fail rate that Web Proxy client requests that have completed with some type of error. If this counter has high values check that Connection settings for incoming Web requests are correctly configured also check if bandwidth is lacking.

FTP Requests

Displays FTP requests made to the Web Proxy service. If this counter is mostly low adjust your FTP caching.

Gopher Requests

Displays Gopher requests made to the Web Proxy service.

HTTP Requests

Displays HTTP requests made to the Web Proxy service.

HTTPS Sessions

Displays HTTPS sessions serviced by the SSL tunnel.

Maximum Users

Displays maximum number of users that connected to the Web Proxy service simultaneously. This tool is useful for determining load usage, license requirements and how you should set ISA for maximum connections.

Requests/Sec

Displays incoming requests for the Web Proxy service. The higher the values the more ISA resources used.

Reverse Bytes Received/sec

Displays bytes are received by the Web Proxy service from Web publishing servers in response to incoming requests. This counter displays how ISA is handling inbound web requests.

Reverse Bytes Sent/sec

Displays rate that the Web Proxy service sends bytes to Web publishing servers in response to incoming requests. This counter displays if ISA can cope with external requests requested from it.

Reverse Bytes Total/sec

Displays all Reverse Bytes Sent and received /Sec between the Web Proxy service and Web publishing servers in response to incoming requests.

Site Access Denied

Displays number of Internet sites the Web Proxy service has denied access. If this counter is high an access policy might be too restrictive.

Site Access Granted

Displays number of Internet sites that Web Proxy service has granted access to.

SNEWS Sessions

Displays all SNEWS sessions serviced by the SSL tunnel.

SSL Client Bytes Received/Sec

Displays SSL bytes received by the Web Proxy service from secured Web Proxy clients.

SSL Client Bytes Sent/Sec

Displays SSL bytes sent by the Web Proxy service to secured Web Proxy clients.

SSL Client Bytes Total/Sec

Displays all SSL Client Bytes Sent and received/Sec between the Web Proxy service and SSL clients.

Thread Pool Active Sessions

Displays sessions being actively serviced by thread pool threads.

Thread Pool Failures

Displays requests rejected because the thread pool was full.

Thread Pool Size

Displays threads in the thread pool representing resources available to service client requests.

Total Array Fetches (Occurs only in Enterprise)

All Web Proxy client requests served by requesting the data from other ISA Server within this array. The (CARP) load factor has high impact on this counter.

Total Cache Fetches

Displays all Web Proxy client requests served using cached data. If this counter is high then cache is being fully utilized.

Total Failed Requests

Displays all requests that failed to be processed by the Web Proxy service. This counter should be far lower than Total successful requests. If this counter is high then check if the URLs requested exist or if the client is allowed to browse the URL. You could have a configuration problem, slow bandwidth or an access policy is too restrictive.

Total Pending Connects

Displays pending connections to the Web Proxy service.

Total Requests

All requests made to the Web Proxy service.

Total Reverse Fetches

All incoming requests that were served by requesting the data from Web publishing servers.

Total SSL Sessions

All SSL sessions serviced by the SSL tunnel.

Total Successful Requests

All requests that were successfully processed by the Web Proxy service.

Total Upstream Fetches

All requests that were served by using data from the Internet or from a chained proxy server.

Total Users

Number of users that have ever connected to the Web Proxy service.

Unknown SSL Sessions

Total number of unknown SSL sessions serviced.

Upstream Bytes Sent/Sec

The rate that bytes are sent by the Web Proxy service to Internet servers or to a chained proxy servers. If this counter remains low a bandwidth upgrade should be considered.

Upstream Bytes Received/Sec

The rate request bytes are received by the Web Proxy service from Internet servers or from a chained proxy server. This counter reflects if bandwidth needs to be upgraded.

Upstream Bytes Total/Sec

The sum of Upstream Bytes Sent and Received/Sec. between the Web Proxy service and Internet servers or chained proxy servers.


Summary:
 This tutorial should help you find problems that have an association to the Web proxy service. I have outlined the counters pertaining to the web proxy service in the tutorial above, the rest of the counters and descriptions with uses will follow in further tutorials released.

About The Author

Ricky Magalhaes is a cyber-security expert and strategist for the past 17 + years working with the world’s leading brands. Ricky is on multiple advisory boards for vendors, customers and cyber security industry bodies and periodically works with leading analyst firms to help device strategy and advise on cyber security. Ricky Magalhaes is a seasoned cyber security strategist, architect and cyber expert, Ricky has trained government agencies and a myriad of governmental agencies on various information security disciplines and has speaks at national and international embassies, conferences on behalf of cyber software vendors.

Read Next

Static vs Dynamic IP Address

Static vs Dynamic IP Address

Most people are familiar with Internet Protocol (IP) Addresses, but many people don’t know you have 2 types. In this article, you’ll learn about static…

Read More »

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top