Периодическое зависание в службе WCF во время GENERAL_SET_RESPONSE_HEADER

Question 1

У меня периодическое зависание в службе WCF. Вызовы, которые обычно занимают миллисекунды, начинают занимать от 30 секунд и более до восстановления службы. Однако все вызовы завершаются успешно. New Relic сообщает, что все время запросов тратится на ExecuteRequestHandler.

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

136 - GENERAL_SET_RESPONSE_HEADER

HeaderName: Content-Length HeaderValue: 2237 Заменить: false

Информационная

273281 мс

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

Может ли кто-нибудь подсказать, куда мне идти дальше.

Благодарность

wcf freeze

0

David Hyde 4 Янв 2017 в 13:58

Answer

С моей точки зрения, это было довольно неприятно. New Relic сообщал, что служба зависала в ExecuteRequestHandler, и я нырнул в кроличью нору, пытаясь диагностировать зависание.

Оказалось, что разрешили настройку дросселирования для службы WCF:

  <system.serviceModel>
    <behaviors>
      <serviceBehaviors>
        <behavior name="...">
          <serviceThrottling maxConcurrentCalls="512" maxConcurrentSessions="3200" maxConcurrentInstances="3712" />

Оказывается, службы WCF по умолчанию регулируются даже без этой записи, и недавно MS увеличила значения по умолчанию. Моя работа падала примерно на 200 об / мин (что я не считаю чрезмерным). Значения, которые я выбрал, в 8 раз превышают новые значения по умолчанию, и теперь все работает прекрасно.

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

Надеюсь, однажды это поможет кому-то :)

1

David Hyde 11 Янв 2017 в 14:34

Question 2