This is an evaluation of the results.
The test has been primarily done to confirm or rule out a presence of handle leak.

PerfMon image, annotated (click to enlarge) follows.



Test outcome: Passed. No Handle Count, Private Bytes, or # Bytes in all Heaps leak found. Also, % Processor Time stays reasonable during the test run.

It is important to note the necessity of performing and evaluating leak tests over long periods of time. Specifically, periods like 36 hours may not be enough to obtain understanding of the trends.

The thick rectangles in the image mark "suspicious" periods which would be interpreted as a leak if observed separately or over a period not significantly longer than the occurrence itself - but they represent no real leak. For example, there is:

• A "# Bytes in all Heaps" (yellow line, cyan rectangle) growth lasting over 12 hours, with no immediate compensation afterwards. But it slowly compensates itself over the next 4 days.
• Two "Handle Counts" growths (blue line, orange rectangles), in duration cca 12 hours and 24 hours (!), with no apparent compensation. But an overall look at the chart over the 9 days shows that there is no leak.
• A small "Private Bytes" growth (red line, pink rectangle) over the period of cca 4.5 days (!), which then stabilizes itself for the remainder of the test.

There are many factors that contribute to such behavior, but specifically the fact that .NET memory is *managed* and the garbage collector *non-deterministic* must be interpreted for what they truly mean.

This is an internal topic.
Attached is a result of 9-day test with Connectivity Explorer (5.50.405.1), 2600 rows of live data.

Note 1: The network disruptions were triggered by a script - 120 seconds on, 120 seconds off.

Note 2: The period at the end where the CPU usage goes down is after we manually stopped the script that caused periodic network disruptions (and we let the network be functional).

Evaluation will follow in a separate post.