自托管的netTcp服务-不必要的限制 [英] self-hosted netTcp service - unwanted throttling

查看:79
本文介绍了自托管的netTcp服务-不必要的限制的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我似乎在WCF服务器上遇到节流-我的自托管服务应该能够处理1000个并发会话,所有内容都是使用异步模式编写的,但是请查看如果运行负载测试应用程序会发生什么情况反对这 服务器(一次打开200个并发会话),我可以看到处理上一个操作(或者说是开始处理)要花一分钟多的时间,所以我怀疑我确实还有一些不必要的限制.

I seem to be experiencing throttling on my WCF server - my self-hosted service should be able to handle over a 1000 concurrent sessions, everything is written using asynch patterns, but looking at what happens if I have my load test app running against the server (which opens up 200 concurrent sessions at once), I can see that it takes over a minute for the last operation to be processed (or rather - begin processing) so I suspect I do have some unwanted throttling still.

我的服务装饰有以下标签

My service is adorned with the following tags

[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Multiple)]

和配置

<netTcpBinding>
            <binding name="SmartAppServerBinding" closeTimeout="00:01:00" openTimeout="00:01:00" hostNameComparisonMode="WeakWildcard" 
                      maxConnections="5000" receiveTimeout="01:00:00" maxBufferSize="20971520" maxBufferPoolSize="20971520" maxReceivedMessageSize="20971520" 
                     listenBacklog="1000" transactionFlow="false" portSharingEnabled="false" >
              <readerQuotas maxDepth="128" maxStringContentLength="1048576" maxArrayLength="3145728" maxBytesPerRead="49152" maxNameTableCharCount="374784" />
              <security mode="None">
                <transport clientCredentialType="None" protectionLevel="None"/>
              </security>
            </binding>
          </netTcpBinding>

...

<behavior name="IncludeExceptionDetails">
            <serviceDebug includeExceptionDetailInFaults="true"/>
            <dataContractSerializer maxItemsInObjectGraph="2147483647"/>
            <serviceThrottling maxConcurrentCalls="500" maxConcurrentInstances="2147483647" maxConcurrentSessions="5000"/>
          </behavior>

...

<service behaviorConfiguration="IncludeExceptionDetails" name="SmartAppServer.SmartAppServer">
              <endpoint address="net.tcp://localhost:8088/SmartAppServer" binding="netTcpBinding"
                  bindingConfiguration="SmartAppServerBinding" contract="ClientInterface.IPhoneClient">
                  <identity>
                      <servicePrincipalName value="SmartAppServer" />
                  </identity>
              </endpoint>
              <endpoint address ="http://localhost:8090" binding="webHttpBinding" 
                        contract="SmartAppMobileClientInterface.ISmartAppMobile" behaviorConfiguration="webHttpWithHelpAndAutoFormatSelection" >
                  <identity>
                    <servicePrincipalName value="SmartAppServer" />
                  </identity>
              </endpoint>
          </service>

如您所见,我大幅提高了限制值-500次并发调用(在服务行为中)比我的负载测试器要高得多,并且我设置了大量的侦听积压(1000)和最大连接数( 5000).

As you can see, I massively increased the throttling values - 500 concurrent calls (in the service behavior) is way higher than what my load tester does, and I set a massive listen backlog (1000) and maximum number of conections (5000) as well.

我正在测试的操作(顺便说一句,这是空的外壳,以便您可以看到我正在采用的异步方法

While the operations I'm testing against (btw, here's the empty shell so that you can see the asynch approach I'm taking

public ClientInterface.LoginResult Login(string login, string domain, string machineName, string clientVersion)
        {
            ClientLoginParameters parameters = new ClientLoginParameters
            {
                Login = login,
                Domain = domain,
                MachineName = machineName,
                ClientType =
                    (string.IsNullOrEmpty(clientVersion) || !clientVersion.StartsWith("2")) ? ClientType.PC : ClientType.PCNew,
                ClientVersion = clientVersion,
                SessionId = OperationContext.Current.SessionId, 
                SendEvents = true
            };
            LoginResult myRes = new LoginResult();
            return commonLogin(myRes, parameters);
        }

        public IAsyncResult BeginLogin(string login, string domain, string machineName, string clientVersion, AsyncCallback callback, object asyncState)
        {
            return new CompletedAsyncResult<ClientInterface.LoginResult>(new ClientInterface.LoginResult());
        }

        public ClientInterface.LoginResult EndLogin(IAsyncResult result)
        {
            CompletedAsyncResult<ClientInterface.LoginResult> res = result as CompletedAsyncResult<ClientInterface.LoginResult>;
            return res.Data;
        }


如果然后我再次终止200个会话(我有一个相应的Logout方法),则会看到相同的行为..我的代码要花很长时间才能到达Login/Logout方法的第一行-前几个命令瞬间到达 但后来它们似乎以不超过5的批量到达,这让我想我没有设法禁用所有的节流功能.

那么,我还有什么想念的吗?


If I then terminate my 200 sessions again (I have a corresponding Logout method), I see the same behavior.. it takes a significant amount of time for my code to hit the first line of the Login / Logout method - the first few commands arrive instantaneously, but then they seem to arrive in batches of no more than 5 which has me thinking I haven't managed to disable all throttling there is.

So, is there anything I'm still missing?

哦,这似乎不是CPU的限制,尤其是在注销情况下,处理器负载仍然远远低于仅使第一个内核达到最大负荷.

Oh, it doesn't seem to be a CPU constraint, especially in the logout scenario, the processor load remains well below maxing out just the first core.

致谢

斯蒂芬

推荐答案

斯蒂芬,你好

感谢您的发布.

我正在尝试让熟悉此主题的人进一步研究此问题.

I am trying to involve someone familiar with this topic to further look at this issue.


这篇关于自托管的netTcp服务-不必要的限制的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆