Add named pipes microbenchmark

[JamesNK]

Follow up to #46259. Previous measurements were done in a unit test. BenchmarkDotNet gives a clearer picture of the improvement.

Results:

|    Method | ListenerQueueCount |     Mean |    Error |   StdDev |     Op/s | Gen 0 | Gen 1 | Gen 2 | Allocated |
|---------- |------------------- |---------:|---------:|---------:|---------:|------:|------:|------:|----------:|
| Plaintext |                  1 | 73.69 us | 1.453 us | 2.765 us | 13,570.0 |     - |     - |     - |     11 KB |
| Plaintext |                  2 | 67.11 us | 1.028 us | 0.962 us | 14,899.9 |     - |     - |     - |     11 KB |
| Plaintext |                  8 | 34.42 us | 0.432 us | 0.361 us | 29,050.4 |     - |     - |     - |     11 KB |
| Plaintext |                 16 | 34.20 us | 0.678 us | 0.857 us | 29,236.3 |     - |     - |     - |     11 KB |

[JamesNK]

@davidfowl

Results:

|    Method | ListenerQueueCount |     Mean |    Error |   StdDev |     Op/s | Gen 0 | Gen 1 | Gen 2 | Allocated |
|---------- |------------------- |---------:|---------:|---------:|---------:|------:|------:|------:|----------:|
| Plaintext |                  1 | 75.40 us | 1.263 us | 1.687 us | 13,262.3 |     - |     - |     - |     11 KB |
| Plaintext |                  2 | 67.21 us | 0.885 us | 0.828 us | 14,878.2 |     - |     - |     - |     11 KB |
| Plaintext |                  8 | 34.52 us | 0.669 us | 0.821 us | 28,966.8 |     - |     - |     - |     11 KB |
| Plaintext |                 16 | 35.37 us | 0.479 us | 0.425 us | 28,275.3 |     - |     - |     - |     11 KB |

Basically the same.

[davidfowl]

Is it because there's no backpressure? I guess the ConnectionDispatcher always queues to the threadpool immediately after the connection is accepted. When we add connection backpressure this will be a bottleneck.

[JamesNK]

One accept loop in ConnectionDispatcher calls NamedPipeConnectionListener.AcceptAsync method. It gets a new connection from NamedPipeConnectionListener.AcceptAsync and immediately puts it on the thread pool. When it calls NamedPipeConnectionListener.AcceptAsync again, another connection is ready for the ConnectionDispatcher to receive immediately.

When we add connection backpressure this will be a bottleneck.

Where is connection backpressure coming from? Who is experiencing the bottleneck? The OS isn't blocking named pipe clients from connecting while this is going on. It has its own accept queue. The purpose of this code is just for the transport to provide connections to the AcceptAsync caller as quickly as possible. Putting things connections on and taking them off the channel isn't a bottleneck.

[davidfowl]

I mean when we add it. This is a long standing work item that we haven’t don’t yet. The idea is to throttle accepts at the dispatcher level m (probably using the rate limiting APIs).