Tracking Thread usage in .NET/IIS program

Question

We have software that is multi-threaded. A source thread kicks off a bunch of parallel tasks (each task involving some processing and some talking to 3rd part APIs) and waits for some or all of them to complete.

Each thread takes 3-30 seconds to complete its work.

We've found that (in prod) there can be delays of up to 10 seconds between the invocation of ThreadPool.QueueUserWorkItem and the thread actually starting, so we believe that we're saturating the supply of threads available in the threadpool. See here for comments on that limit: Default values for System.Threading.ThreadPool.SetMaxThreads

We want to be able to track these various numbers of threads so that once we've made our various changes we have something we can point at and say "look, we've solved the issue with using up all the threads".

This MSDN page: https://msdn.microsoft.com/en-us/library/ff650682.aspx implies that there are no counters to track this sort of thing and merely provides suggested implementations of DIY counters.

This page, on the other hand: http://blogs.iis.net/mailant/new-worker-process-performance-counters-in-iis7 says that the counters DO exist? It seems to say that "Maximum Threads", "Total Threads" and "Active Threads" should be relevant. I would have assumed that these meant:

• "Maximum": how many threads the TP can create before it has to start waiting for old threads to die before it can create new ones.
• "Active": how many threads are actually running our programs code at any given time.
• "Total": ?? I'd guess this was "Active" + "the count of threads that are started but are sitting waiting for an external resource"? In our case the 3rd party APIs, but in general it might be disk IOs, or DB accesses, etc.

I've tried to look at these by opening Perf Monitor, "add a new Counter" > "W3SVC_W3WP" > selecting those 3 specific counters > selecting our particular process > "Add" > "OK".

Then the Perf Monitor graph tells us that: Max = 256 Total = 16 Active = 0 !?

That seems ... unlikely? I'm assuming that I've either misunderstood the counters, or mis-configured Perf Monitor?

Our next attempt was to look at the "Threads" column in Task Manager for the process (Identifying the correct w3wp process via PID from IIS Manager). That generally shows there being 100-150 Threads, but if I really thrash the process (spam our API end point that it is running) then I can get the number up past 256 (I saw it at 264, at one point).

Can anyone shed any light on this?

Fundamentally my question is, what do all those various numbers/statistics specifically mean in the context of ThreadPool.QueueUserWorkItem and what's the best way to track the thread-availability-state of the ThreadPool.