Транспортировка сигналов – влияние на производительность, пропускную способность и т. д
Мы используем signalr (.net 8) для некоторых новых функций в нашем основном API Asp.net, которые используются в основном приложением Flutter.
Я неявно знаю, что в большинстве случаев WebSockets лучше, чем события, отправленные сервером, которые лучше, чем Long-Polling.
Существуют ли какие-либо данные, тесты или технические документы (что-либо), в которых (явно) описывается влияние резервных средств на производительность.
Я хочу, чтобы эта информация подчеркнула важность наличия поддержки WS на наших серверах.
Ответы 1
Вы можете ознакомиться с официальной документацией SignalR https://learn.microsoft.com/en-us/aspnet/signalr/overview/getting-started/introduction-to-signalr#transports-and-fallbacks, в которой четко указано в разделе Транспорты и резервные варианты указано, что WebSocket является оптимальным транспортом для SignalR. Я нашел тестовую статью и случай, вы можете просто сослаться на них.
Согласно результатам тестирования этой диссертации http://www.diva-portal.se/smash/get/diva2:1133465/FULLTEXT01.pdf ，Веб-сокеты и события, отправленные сервером, являются наиболее эффективными в производительности.
И обратитесь к этому случаю WebSockets против событий, отправленных сервером/EventSource ，Соединения Websockets могут как отправлять данные в браузер, так и получать данные из браузера. Соединения SSE могут передавать данные только в браузер. Таким образом, на практике все, что можно сделать с помощью SSE, можно сделать и с помощью веб-сокетов, и гораздо больше браузеров поддерживают веб-сокеты, чем SSE.