Continuously degrading performance in repeated one-way calls (S.SM 4.8, netcore3.1)

Describe the bug When calling a one way service with reliable sessions repeatedly, the time to make the call continually increases on the client side.

To Reproduce Steps to reproduce the behavior: https://github.com/ssa3512/wcf-reliable-sessions/tree/perf-repro

1. Run the wcfasynctestservice project
2. From wcfasynctestclient directory run dotnet run -f netcoreapp3.1 Observe the call time gradually increase (starts at ~5ms and after a few minutes it is over 500ms)
3. From wcfasynctestclient directory run dotnet run -f net472 Observe the call time is consistently <10ms over any time frame

Expected behavior Subsequent calls to a service are as performant as the first call

Screenshots

Additional context I set up an azure function that is calling a legacy one way WCF service on a timer (every three minutes). This is designed to replace a windows service that is calling the service on a timer. I noticed over the span of 24 hours that the function execution time increased from ~10ms to about 2.5 seconds. Stopping and starting the app service immediately reset the execution time back to the expected 10ms.

Some notes from console app repro tests:

• Using a ClientBase implementation or ChannelFactory does not seem to make a difference
• Async vs sync does not seem to make a difference
• Using separate binding/contract/endpoint address objects does not seem to make a difference
• Reusing the proxy/leaving the channel open seems to alleviate the issue, but that isn’t an option in my scenario as the function execution does not allow reuse of the channel from one execution to the next.
• Edit: This occurs with both NetTcpBinding and WSHttpBinding

[ssa3512]

@ssa3512, when you build at the command line, if you add the -sign parameter, it will delay sign the assembly. So something like this:

build  -build -c Release -sign

Let me know if that works for you.

This has since been rolled out to our production environments and is working very well. We aren’t seeing any of the odd cpu behavior from prior to the update.

[ssa3512]

@mconnew I pulled your branch down and was able to build the nuget packages from it. I will work on integrating them tomorrow and will report back.