Ошибка службы слишком занята в WCF - PullRequest
Новая
       8

Ошибка службы слишком занята в WCF

29 голосов
/ 23 мая 2009

Я периодически получаю следующее исключение в моей службе .Net WCF. «Служба HTTP, расположенная по адресу http://MyServer/TestWCF/MyService.svc, слишком занята.»

Я что-то здесь упускаю?

Я использую базовую привязку http и включил регулирование WCF. 

<basicHttpBinding>
        <binding name="BasicHttpBinding_MyService" maxReceivedMessageSize="2147483647"
                 messageEncoding="Text" textEncoding="utf-16" sendTimeout="00:01:00" >
          <readerQuotas maxStringContentLength="2147483647" maxArrayLength="163840000"
                        maxDepth="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="16384" />
        </binding>

. , , . 

<behavior name="MyWCFServices.MyServiceBehavior">
          <serviceMetadata httpGetEnabled="true" />
          <serviceDebug includeExceptionDetailInFaults="true" />
          <serviceThrottling
                    maxConcurrentCalls="16"
                    maxConcurrentInstances="2147483647"
                    maxConcurrentSessions="10"/>
        </behavior>

Поможет ли регулирование решить проблему? Кроме того, могу ли я знать рекомендуемые значения параметров для регулирования для веб-сайта с высоким трафиком?

Ответы [ 8 ]

10 голосов
/ 23 мая 2009

Вы можете определенно попытаться увеличить maxConcurrentSessions и maxConcurrentCalls в своем поведении регулирования службы до стандартных значений 30 или около того и посмотреть, устранит ли это ошибку. Слишком занятый сервер может указывать на то, что поступило больше запросов, чем в области, разрешенной вашим режимом регулирования службы, и они были отброшены, поскольку ни один экземпляр службы не стал доступен для их обслуживания в течение заданного периода времени ожидания.

9 голосов
/ 17 октября 2011

Мой ответ: проверить, исправен ли пул приложений?

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

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

4 голосов
/ 01 мая 2012

Если ваша служба работает под вашей учетной записью (удостоверение), вполне возможно, что вы недавно изменили свой пароль - вам нужно будет сбросить его для пула приложений IIS в Дополнительные настройки | Диалоговое окно удостоверения.

2 голосов
/ 25 июня 2014

Убедитесь, что вы также проверили внутреннее исключение; во время наших развертываний мы отключаем пул приложений веб-службы WCF, и клиенты начинают получать эту ошибку в течение этого времени:

System.ServiceModel.ServerTooBusyException: служба HTTP, расположенная по адресу https://ourserver.x.com/path/service.svc, слишком занята. ---> System.Net.WebException: удаленный сервер возвратил ошибку: (503) сервер недоступен.

Таким образом, в этом случае ошибка HTTP 503 (неправильно?) Интерпретируется как «сервер слишком занят».

2 голосов
/ 23 июня 2009

Это не просто maxConcurrentSessions, это также продолжительность сеанса.

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

1 голос
/ 18 мая 2012

Я только что столкнулся с этой ошибкой, и она сводилась к простой проблеме конфигурации. У меня был сервис на тот же порт и тот же интерфейс (фиктивная служба). Я запустил сервис с соответствующим переключателем командной строки, чтобы запустить «оригинальный» сервис, который я намеревался. Ошибка ушла.

1 голос
/ 17 апреля 2011

Единственный источник этого исключения, о котором я знаю, - это если вы используете сеансы, и вам удается нажать дроссель MaxPendingChannels ,. По умолчанию его значение довольно низкое, например 4. Вы можете попробовать установить его выше (например, 128), или, если вы просто хотите воспроизвести, установите его на 1, и вы увидите его при нагрузочном тестировании.

Смотрите здесь для получения дополнительной информации о сессиях: http://msdn.microsoft.com/en-us/library/ms733795.aspx

0 голосов
/ 01 февраля 2014

Мое решение было бы, проверить файл App.Config, есть ли метка службы для этой конкретной службы.

например: 

<service name="MyServices.ServiceName">
        <endpoint address="" binding="wsHttpBinding" bindingConfiguration="TestBinding"   contract="MyServices.ServiceName">
          <identity>
            <dns value="localhost" />
          </identity>
        </endpoint>
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
        <host>
          <baseAddresses>
            <add baseAddress="http://localhost:8732/Design_Time_Addresses/MyServices/ServiceName/" />
          </baseAddresses>
        </host>
</service>
...