Tips for ISA Firewall Performance Assessment

If you’ve been working with the ISA firewall for any length of time, you’ve probably noticed that when you open the ISA firewall group in the Start menu, that you have the option to open either the ISA firewall console or the ISA firewall Performance monitor. It’s likely that most ISA admins haven’t looked at the ISA performance monitor, other than perhaps clicking on the link by mistake and seeing a console with counters that either they didn’t understand or didn’t know how to interpret.

Performance monitoring of any kind can be a daunting task. You have to learn what counters are “interesting”, and then you have to figure out what “interesting” values are for those counters. What makes things even more difficult is that counter values are “interesting” based on a number of other factors. This concatenation of difficulties leaves most ISA firewall admins with a sense of disempowerment and a “head in the sand” approach to ISA firewall performance monitoring and assessment.

While I can’t make the difficult task of detailed performance monitoring and assessment for the ISA firewall easy, I can help you with some tips and tricks and general guidelines. These general guidelines, provided by Jim Harrison, can at least get you up and running and enable you to start asking yourself meaningful questions about your ISA firewall’s performance at any given point in term and over an extended period of time.

From Jim Harrison:

========================================

\ISA Server Firewall Packet Engine\

Active connections (comparative baseline)

– Backlogged Packets (lower == good)

– Dropped Packets/sec (lower == good)

Packets/sec ((comparative baseline)

TCP Established Connections comparative baseline)

Backlogged packets can impact dropped packets:

1. An increase in dropped packets without a corresponding rise in backlogged packets increase may indicate an attack

2. if they rise together or if a rise in backlogged packet precedes an immediate rise in dropped packets, ISA is processing too much traffic

3. If this always happens after active connections plateaus, it’s time to scale out or resolve other issues upstream (DNS, connectivity, authentication)

\ISA Server Firewall Service\

– Available Worker Threads (lower == bad)

– Pending DNS Resolutions (lower == good)

– Pending TCP connections (lower == good; 0 == ideal)

Available worker threads should never remain near 0 for any length of time; if ISA keeps this at or near 0, it’s time to scale out.

Pending DNS resolutions can impact pending TCP connections; make sure Windows can perform resolutions quickly & reliably – ESPECIALLY for domain-based DNS

\ISA Server Web proxy\

– Failing requests/Total Requests(%) (lower == good)

– Memory pool for HTTP requests (%) (lower == bad; <30% for an extended period is a trigger for problems or possible scale-out)

– Memory pool for SSL requests (%) (lower == bad)

Outgoing connections/sec (comparative baseline)

Requests/sec (comparative baseline)

– Total Pending Connects (lower == good)

If the “comparative baseline” values plateau and the “failing” or “pending” counters are rising or the memory pool counters are falling, it’s time to scale out.

Note that Failing requests/Total requests % is expected to cycle with the requests/sec for RPC/HTTP, since ISA almost never gets a “heads-up” that the server or client are about to close the connection.  http://blogs.technet.com/isablog/archive/2007/06/25/rpc-over-http-logging-wildness.aspx

(only if MSDE logging is used)

\MSSQL$MSFW:Databases\

– Active Transactions (lower == good)

– Transactions/sec (lower == good)

If the DB transactions are large, this may cause ISA to backlog connections or requests (can’t log it; can’t pass it). 

General counters used for ISA performance triggers

\Memory\

– Pool Nonpaged Bytes\ (baseline; > 200MB on all servers is a trigger for possible scale-out)

\Process(wspsrv)\

– Handle count; this is a baseline value; extended periods of higher than baseline indicate a heavily-loaded server

– Pool Nonpaged Bytes\ (baseline; > 175MB on all servers is a trigger for possible scale-out)

– Private Bytes; this should not remain above 1.8GB for any extended period.  If it does, this is a potential scale trigger.  If all other ISA performance aspects are within normal or heavy use ranges, then this may be normal

Note that if you use Windows auth, you want to add the NetLogon perf counter update and add those counters to the watch list.

========================================

HTH,

Tom

Thomas W Shinder, M.D., MCSE
Sr. Consultant / Technical Writer
Prowess Consulting www.prowessconsulting.com

PROWESS CONSULTING documentation | integration | virtualization
Email: [email protected]
MVP — Forefront Edge Security (ISA/TMG/IAG)

About The Author

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