WCF中服务太忙的错误

I intermittently get the following exception in my .Net WCF Service. "The HTTP service located at http://MyServer/TestWCF/MyService.svc is too busy."

我在.Net WCF服务中间歇性地获得以下异常。 “位于http：//MyServer/TestWCF/MyService.svc的HTTP服务太忙了。”

Am I missing something here?

我在这里错过了什么吗？

Am using basic http binding and have enabled WCF throttling.

我使用基本的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>

Will throttling help resolving the issue? Also,may i know the recommended parameter values for throttling for a high traffic web site?

限制有助于解决问题吗？另外，我可以知道高流量网站的限制推荐参数值吗？

8 个解决方案

#1

You could definitely try to increase the maxConcurrentSessions and maxConcurrentCalls in your service throttling behavior to the standard values of 30 or so and see if that makes the error go away. Server too busy would seem to indicate that more requests have come in than area allowed by your service throttling behavior, and they've been discarded since no service instance became available to service them within the given timeout period.

您肯定可以尝试将服务限制行为中的maxConcurrentSessions和maxConcurrentCalls增加到标准值30左右，看看是否会使错误消失。服务器太忙似乎表明更多的请求已经进入，而不是服务限制行为允许的区域，并且它们已被丢弃，因为在给定的超时期限内没有服务实例可用于服务它们。

#2

My answer would be, check if the app pool is up and well?

我的答案是，检查应用程序池是否正常运行？

I've seen this error occurring when the app pool has died due to exceptions being thrown that aren't caught.

我已经看到当应用程序池由于未被捕获的异常而死亡时发生此错误。

Consider for example, custom config sections - having an error in there, will cause your app to fail before it's even started. Too many of these in a short space of time will kill the app pool.

例如，考虑自定义配置部分 - 在那里出现错误，将导致您的应用在启动之前失败。在很短的时间内，太多这些会杀死应用程序池。

#3

If you're service is running under your account (Identity), it's quite possible that you've recently changed your password--you'll need to reset it for its IIS application pool in Advanced Settings | Identity dialog box.

如果您的服务正在您的帐户（身份）下运行，您很可能最近更改了密码 - 您需要在高级设置中为其IIS应用程序池重置密码。标识对话框。

#4

It is not just the maxConcurrentSessions, it is also how long the session lasts.

它不仅仅是maxConcurrentSessions，也是会话持续多长时间。

If the client does not close the connection, it will remain open until it timesout. You could then hit the maxConcurrentSessions limit with very little activity on the server.

如果客户端没有关闭连接，它将保持打开状态，直到超时。然后，您可以在服务器上执行非常少的活动时达到maxConcurrentSessions限制。

#5

Make sure you check the inner exception, too; during our deployments, we disable the application pool of a WCF web service, and clients start getting this error during that time:

确保你也检查内部异常;在我们的部署期间，我们禁用了WCF Web服务的应用程序池，并且客户端在此期间开始收到此错误：

System.ServiceModel.ServerTooBusyException: The HTTP service located at https://ourserver.x.com/path/service.svc is too busy. ---> System.Net.WebException: The remote server returned an error: (503) Server Unavailable.

System.ServiceModel.ServerTooBusyException：位于https://ourserver.x.com/path/service.svc的HTTP服务太忙了。 ---> System.Net.WebException：远程服务器返回错误：（503）服务器不可用。

So in this case an HTTP error 503 is being (mis?)interpreted as "server too busy".

因此，在这种情况下，HTTP错误503（错误？）被解释为“服务器太忙”。

#6

The only source of this exception that I am aware of is if you are using sessions, and you manage to hit the MaxPendingChannels throttle,. Its default is something pretty low like 4. You could try setting it higher (128 for example), or if you just want to repro, set it to 1 and you should see it under load testing.

我所知道的这个异常的唯一来源是你正在使用会话，并设法达到MaxPendingChannels限制。它的默认值非常低，如4.您可以尝试将其设置得更高（例如128），或者如果您只想重新设置，请将其设置为1，您应该在负载测试下看到它。

See here for more information about sessions: http://msdn.microsoft.com/en-us/library/ms733795.aspx

有关会话的详细信息，请参阅此处：http：//msdn.microsoft.com/en-us/library/ms733795.aspx

#7

I just ran into this error, and it boiled down to a simple configuration problem. I had a service up on the exact same port and same interface (mock service). I ran the service with the appropriate command line switch to run the "original" service I intended. The error went away.

我刚遇到这个错误，它归结为一个简单的配置问题。我在完全相同的端口和相同的接口（模拟服务）上有一个服务。我使用适当的命令行开关运行该服务以运行我想要的“原始”服务。错误消失了。

#8

My Solution would be, Check the App.Config file, whether the service tag is there for this particular service.

我的解决方案是，检查App.Config文件，该特定服务是否有服务标签。

eg:

例如：

<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>

#1

#2