Влияние записи журналов диагностики Azure в хранилище BLOB-объектов на производительность

Наше веб-приложение C #, работающее в Azure, использует System.Diagnostics.Trace для написания операторов трассировки для отладки / устранения неполадок. После включения хранилища BLOB-объектов для этих журналов (с помощью параметра «Ведение журнала приложений (blob)» на портале Azure) время отклика для нашего приложения значительно замедляется. Если я отключу эту опцию, веб-приложение снова ускорится (хотя, очевидно, мы больше не получаем журналы в хранилище BLOB-объектов).

Кто-нибудь знает, ожидается ли это? Конечно, мы пишем много операторов трассировки на каждый запрос (около 100 на запрос), но я не думаю, что это было необычно для веб-приложения. Есть ли способ диагностировать, почему включение хранилища BLOB-объектов для журналов резко замедляет выполнение этих операторов трассировки? Синхронизируется ли запись оператора трассировки с журналами, обновляемыми, например, в хранилище больших двоичных объектов?


azure azure-storage-blobs azure-diagnostics
person Auth Infant    schedule 06.11.2017    source источник
comment
Размещается ли ваше веб-приложение с помощью виртуальной машины или службы приложений, в любом случае веб-приложение и учетная запись хранения являются частью одной группы ресурсов и одного расположения?   -  person Baskar Rao    schedule 07.11.2017
comment
Группы ресурсов @Baskar не имеют ничего общего с производительностью или местоположением службы.   -  person David Makogon    schedule 07.11.2017
comment
Это служба приложений. И служба приложений, и учетная запись хранения находятся на западе США 2. Насколько важна геолокация? Думаю, я мог бы подумать, что отправка журналов в хранилище BLOB-объектов будет асинхронной по сравнению с фактическим вызовом Trace (вы бы не хотели, чтобы каждый вызов для трассировки выполнял сетевой вызов? Хотя это может объяснить, почему это происходит так медленно? Я не посмотреть, как регистрация может работать с такой моделью, хотя)   -  person Auth Infant    schedule 07.11.2017
comment
@DavidMakogon Я хотел убедиться, что сетевая задержка учитывается в соответствии с приведенными ниже документами. Раздел «Возможности клиентской сети». docs.microsoft.com/en-us/azure/ хранилище / обычное /   -  person Baskar Rao    schedule 07.11.2017
comment
@Baskar, я понял. И спросить, размещены ли ресурсы в одном регионе, - отличный вопрос. Но группы ресурсов не имеют ничего общего с расположением ресурсов и не играют никакой роли в производительности или задержке.   -  person David Makogon    schedule 07.11.2017
comment
@BouillabaisseCurdlesnoot, это все еще фактор для вас, или вы нашли решение? У меня та же проблема, и я начинаю задаваться вопросом, стоит ли вообще хранилище BLOB-объектов для журналов ...   -  person akaioi    schedule 18.11.2017
comment
@akaioi Мне удалось найти обходной путь / решение, и я просто разместил его как ответ на свой вопрос здесь. Сообщите мне, если это поможет.   -  person Auth Infant    schedule 05.12.2017

Ответы (1)


arrow_upward
3
arrow_downward

Мне не удалось найти никакой информации о том, как было реализовано ведение журнала в хранилище BLOB-объектов в Azure. Однако вот что я смог сделать:

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

Я также подтвердил, что если я поверну Автозапуск выключен, проблем с производительностью не возникло.

Из дальнейших перекрестных ссылок исходный код для API трассировки .NET, я пришел к выводу, что при включении хранилища BLOB-объектов для журналов внедряет в ваше приложение какой-то прослушиватель трассировки (точно так же, как вы можете добавить прослушиватель в web.config) и синхронно записывает каждый полученный оператор трассировки в хранилище больших двоичных объектов.

Таким образом, похоже, что есть несколько способов обойти это поведение:

  1. Don't turn on AutoFlush, but manually flush periodically. This will prevent the synchronous blob writes from interrupting every log statement.
  2. Write your own daemon that will periodically copy local log files to blob storage or something like this
  3. Don't use this blob storage feature at all but instead leverage the tracing functionality in Application Insights.

Я закончил тем, что сделал №3, потому что, как оказалось, у нас уже был настроен и включен Application Insights, мы просто не понимали, что он может обрабатывать ведение журнала трассировки и запросы. После отключения выборки для отслеживания событий мы теперь есть способ легко запрашивать любой оператор журнала удаленно и получать полный набор трассировок с учетом любых критериев (соответствие ключевого слова, все трассировки для определенного запроса, все трассировки за определенный период времени и т. д.). заметные синхронные накладные расходы на запись операторов журнала с помощью прослушивателя трассировки Application Insights, поэтому в нашем приложении не нужно ничего менять (мы можем продолжать использовать класс трассировки .NET). В качестве бонуса, поскольку трассировка Application Insights является довольно гибкой с источником трассировки, мы даже можем переключиться на другой API регистрации с более высокой производительностью (например, ETW или log4net), если это необходимо, и Application Insights по-прежнему работает.

В конечном итоге вам следует рассмотреть возможность использования Application Insights для хранения и запроса ваших трассировок. В зависимости от того, зачем вам вообще нужны журналы в хранилище BLOB-объектов, это может или не может соответствовать вашим потребностям, но у нас это сработало.

person Auth Infant    schedule 05.12.2017