Блог

У меня есть серверное приложение Blazor, размещенное в службе приложений Azure, которое кажется довольно «болтливым», поскольку оно обрабатывает некоторые события пользовательского интерфейса в браузере, такие как события перетаскивания. Я добавил журналы трассировки, чтобы иметь какую-то оценку количества используемых сообщений SignalR и их размера.

У меня в программе есть следующее.cs

 public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .ConfigureLogging(logging =>
            {
                logging.ClearProviders();
                logging.AddConsole();
                // Logs to trace Blazor SignalR traffic.
                logging.AddFilter("Microsoft.AspNetCore.SignalR", LogLevel.Trace);
                logging.AddFilter("Microsoft.AspNetCore.Http.Connections", LogLevel.Trace);
            })

            .ConfigureWebHostDefaults(webBuilder =>
            {
                webBuilder.UseStartup<Startup>();
            });
}
 

Это дает мне довольно обширный вывод журнала, который выглядит примерно так:

 trce: Microsoft.AspNetCore.Http.Connections.Internal.Transports.WebSocketsTransport[9]
     Message received. Type: Binary, size: 319, EndOfMessage: True.
dbug: Microsoft.AspNetCore.SignalR.Internal.DefaultHubDispatcher[1]
     Received hub invocation: InvocationMessage { InvocationId: "", Target: "DispatchBrowserEvent", Arguments: [ {"browserRendererId":0,"eventHandlerId":366,"eventArgsType":"mouse","eventFieldInfo":null}, {"type":"click","detail":1,"screenX":386,"screenY":-443,"clientX":700,"clientY":514,"offsetX":70,"offsetY":21,"button":0,"buttons":0,"ctrlKey":false,"shiftKey":false,"altKey":false,"metaKey":false} ], StreamIds: [  ] }.
trce: Microsoft.AspNetCore.Http.Connections.Internal.Transports.WebSocketsTransport[11]
     Sending payload: 1078 bytes.
trce: Microsoft.AspNetCore.SignalR.Internal.DefaultHubDispatcher[7]
     InvocationId (null): Sending result of type 'System.Void'.
trce: Microsoft.AspNetCore.Http.Connections.Internal.Transports.WebSocketsTransport[9]
     Message received. Type: Binary, size: 28, EndOfMessage: True.
dbug: Microsoft.AspNetCore.SignalR.Internal.DefaultHubDispatcher[1]
     Received hub invocation: InvocationMessage { InvocationId: "", Target: "OnRenderCompleted", Arguments: [ 1237,  ], StreamIds: [  ] }.
trce: Microsoft.AspNetCore.SignalR.Internal.DefaultHubDispatcher[7]
     InvocationId (null): Sending result of type 'System.Void'.
trce: Microsoft.AspNetCore.Http.Connections.Internal.Transports.WebSocketsTransport[11]
     Sending payload: 13216 bytes.
 

Я вижу, что туда отправляются большие сообщения, которые, как я предполагаю, вызваны загрузкой исходных данных на размер сервера (из базы данных) и передачей компонентам для отображения информации. Меньшие события пользовательского интерфейса создают тонны меньших 75-байтовых сообщений (по-видимому).

Я применяю некоторые регулярные выражения, чтобы получить необходимую мне информацию из этих журналов, не будучи уверенным в точности собранной информации.

Каков наилучший/правильный способ получения и подсчета сообщений SignalR (как по количеству сообщений, так и по размеру на сообщение)?

Я хочу оценить, будет ли использование службы Azure SignalR приемлемым решением для масштабирования моего приложения.

Как сообщения Azure SignalR учитываются для выставления счетов, описано здесь.

Мои тесты до сих пор с бесплатным уровнем SignalR позволяют мне получать более 20 тысяч бесплатных сообщений в день в считанные минуты. При тестировании стандартного уровня с 1 миллионом бесплатных сообщений в день я вижу, как сотни тысяч сообщений уже были использованы в течение часа.

Я выслеживал вещи, которые создают нежелательные (или очень большие) сообщения в моем приложении, но что-то кажется неконтролируемым; мне нужно правильно это измерить.

Спасибо SnehaAgrawal-MSFT, опубликовавшему ваше предложение в качестве ответа, чтобы помочь другим членам сообщества .

«Вы можете обратиться к этому документу о журналах ресурсов для службы Azure SignalR, а также о том, как их настроить и как с ними устранять неполадки.

Чтобы добавить к этому ресурс SignalR в экземпляре бесплатного уровня, ограничение на количество сообщений составляет 20000 в день.

Пожалуйста, ознакомьтесь с этим документом корпорации Майкрософт о том, как подсчитываются сообщения в службе SignalR.

Если большие сообщения разделяются на более мелкие и учитываются как несколько сообщений, в этом случае соединения блокируются.

Если ожидается количество сообщений, то единственным решением является масштабирование экземпляра до стандартного уровня, который не имеет жесткого ограничения на количество сообщений».

Пожалуйста, обратитесь к этому документу корпорации Майкрософт для получения дополнительной информации: . Оценка сложных вариантов использования службы Azure SignalR