high CPU with server sent events (SSE)

Question

hello, I work with a front end react that connects to a .net core 5 api (1 single instance) to receive the events sent by the server in real time (server sent events (SSE)).
I've been facing cpu spikes of few seconds where it generates dead lock across the api sometimes disconnecting all users from sse.
Besides disconnecting it also blocks the entire api, including sql, redis and others. Would it be the reason to have a single instance of api?
Reading in the documentation, azure informs that operating with a single instance can have peaks of up to 8 seconds of downtime, would that be the cause?
Should the configuration in the azure web sockets portal be enabled? as sse is unidirectional and web sockets bidirectional.

Answer 1

WillianZmorzynski-9153, Adding to ZhiLv-MSFT response, from Azure WebApps stand-point. To isolate the issue further, kindly try these:

If you haven't done this already, you may leverage App Service diagnostics from Azure Portal> Navigate to your App Service app in the Azure Portal. In the left navigation, click on Diagnose and solve problems and “Availability and Performance”. Go over the highlighted (screenshot below) options- to see if it provides additional pointers. And. you could also create a process dump, and then analyse the process dump.

SSE uses long-polling requests, it may hit the 230s limit. Azure Load Balancer has a default idle timeout setting of four minutes (~230 secs). If your web app requires background processing, it is recommended to use Azure WebJobs or Azure Functions. Kindly ensure if Always-On feature is turned ON.

I understand you’re running the WebApp on a single instance, to isolate you may also consider to scale out two multiple instances (as a test). Running your app on only one VM instance is an immediate single point-of-failure. By ensuring that you have multiple instances allocated to your app, if something goes wrong with any particular instance, your app will still be able to respond to requests going to the other instances.

For production apps that are aiming to be robust, it is recommended to set Always on to On and ARR Affinity to Off. However, disabling ARR Affinity assumes that your application is either stateless, or the session state is stored on a remote service such as a cache or database.