我有一个非常简单的WCF的Web服务队，在IIS中承载防爆preSS使用.net 3.5（最终是完整的IIS）。该服务方法是相当无趣。

I have a fairly simple WCF web sevice, hosted in IIS Express (eventually to be full IIS) using .Net 3.5. The service method is fairly uninteresting.

[ServiceContract]
public class MySvc
{
    [OperationContract]
    public Stuff MyMethod(string input)
    {
        Stuff result = DoSomething();
        return result;
    }
}

该服务的配置也相当通用的：

The service configuration is also fairly generic:

<system.serviceModel>
    <services>
        <service behaviorConfiguration="MySvcBehavior" name="MySvc">
            <endpoint address="" binding="wsHttpBinding" contract="MySvc">
                <identity>
                    <dns value="localhost"/>
                </identity>
            </endpoint>
            <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
        </service>
    </services>
    <behaviors>
        <serviceBehaviors>
            <behavior name="MySvcBehavior">
                <serviceMetadata httpGetEnabled="true"/>
                <serviceDebug includeExceptionDetailInFaults="false"/>
            </behavior>
        </serviceBehaviors>
    </behaviors>
</system.serviceModel>

该服务由C-后面的$ C $在一个ASPX应用程序使用。有一个服务引用，导致一些索然无味地code。

The service is consumed by a code-behind in an ASPX application. There's a service reference, leading to some equally uninteresting code.

MySvcClient svc = new MySvcClient();
Stuff result = svc.MyMethod("foo");

只要它是在一个时间一个请求，一切都工作得很好，并在客户端code得到预期的结果。耶。

As long as it's one request at a time, everything works just fine and the client code gets the expected result. Yay.

的问题是当我做一些很原始的压力测试。我加载客户端ASPX页面在浏览器中，然后按下F5键。看着IIS防爆preSS窗口，在第一次的结果回来的状态200，但几分钟我开始看到状态500。在这点之后，该服务将只与状态500作出回应，直到我重新启动IIS前preSS。 （基于等待大约10分钟。）

The problem comes when I do some very primitive stress testing. I load the client ASPX page in a browser, and then hold down the F5 key. Watching the IIS Express window, at first the results come back as status 200, but after a few minutes I start seeing status 500. At this point, the service will only respond with status 500 until I restart IIS Express. (Based on waiting about 10 minutes.)

设置在客户端code断点，我看到完整的返回消息是有太多悬而未决的服务器上的安全对话，请稍后再试。

Setting a breakpoint in the client code, I see the full return message is "There are too many pending secure conversations on the server. Please retry later."

设置在服务器code断点，我发现我的code甚至没有被调用。所以它的地方呼叫，我的code实际开始的失败。

Setting a breakpoint in the server code, I find that my code isn't even being invoked. So it's failing somewhere between the call and the actual start of my code.

我在网上搜索还没有非常有前途的，主要是导致相同的suggestion编写自定义绑定以覆盖maxPendingSessions财产并开始一个线程有人告诉我，有一个[未命名]配置文件设置，然后导致损坏的链接，声称微软已经承认这是一个错误。

My online searches haven't been very promising, mostly leading to the same suggestion of writing a custom binding in order to override the maxPendingSessions property and a thread starting with "Someone told me there's a [unnamed] config file setting" which then leads to a broken link claiming Microsoft has acknowledged this as a bug.

有关maxPendingSessions属性的链接确实提到了有两分钟的超时128连接的限制，我肯定能看到我的测试方法是将中断一些连接。这是一个公认的坏测试方法预期的结果？或者，可以将东西在配置做了改进呢？

The link about the maxPendingSessions property does mention a limit of 128 connections with a timeout of two minutes, and I can certainly see where my method of testing is going to interrupt some connections. Is this the expected result of an admittedly bad testing methodology? Or can something be done in the configuration to improve this?

推荐答案

听起来像是你在服务器上是数不胜数打开的连接 - 客户端不使用因'使用'的连接

Sounds like you have a zillion open connections on the server - due to the client side not using a 'using' for the connection.