Azure App service triggers autoheal due long during signalr requests

[elmarmaan]

Issues related to the Asp.NET Core version of SignalR should be filed in the corresponding SignalR repo: https://github.com/aspnet/?utf8=%E2%9C%93&query=Signalr

Expected behavior

I would expect that signalr is not causing our app service instances to recycle with proactive autoheal of azure when using redis as backpane

Actual behavior

Almost every day we have issues with long during signalr requests, which causing our application to recycle.

Steps to reproduce

It is not easy to reproduce, but we are using signalr 2.2.0, with an asp.net web application running 6 instances on azure app service, with redis as backpane.

We think it could have someting to do with serversendevents as mechanism instead of websockets. But we don't know how we can investigate this better. anyone got a clue?

In the attachment you can find an excel of requests taking so long(some several hours!)
Slow_Requests.xlsx

Thanks!

[analogrelay]

WebSockets and Server-Sent Events are long-running requests by design. It's how they work. What is the change you're looking for in SignalR to resolve this? Have you configured auto heal to trigger when a long-running request occurs? If so, I think you should disable that rule, or exempt the WebSocket/SSE requests from it because they are always going to last as long as the entire connection.

[analogrelay]

Closing this as we haven't heard from you. Please feel free to comment if you're able to get the information we're looking for and we can reopen the issue if we're able to identify the problem.