WCF服务路由，是一个瓶颈吗？

Question

我们的应用服务器体系结构设置了一种方式，即所有服务调用都通过定制的 WCF 服务路由器进行 - 一个单一的服务将请求分配到适当的服务中，使用嵌入在请求消息头中的信息。

我们在使用此 WCF 服务路由器时遇到性能问题（在并发用户负载测试时超时）。我们想知道这是否是路由器中的错误，我们是否错误地配置了服务/IIS或者这是可以预料的 - 每个调用都经过单一的服务听起来像是潜在的瓶颈。

没有路由时，我们可以处理大约120个并发用户，然后出现超时错误，虽然我们会出现超时错误，但 IIS 仍然可以处理请求。而与路由器一起使用时，IIS 在大约20个并发用户处停止处理请求，并且在其余的负载测试期间始终不会恢复处理任何请求。

我们的主要问题是，在使用服务路由器时，这是否是可以预期的，或者根据我们的设置，IIS 是否能够处理此负载？

路由服务看起来是这样的：

/// <summary>
/// Generic service contract which can accept any WCF message.
/// </summary>
[ServiceContract]
public interface IServiceRouter
{
    [OperationContract(Action = "*", ReplyAction = "*", AsyncPattern=false)]
    Message ProcessMessage(Message requestMessage);
}

实现方式如下：

[ServiceBehavior( 
    InstanceContextMode = InstanceContextMode.PerCall,
    ConcurrencyMode = ConcurrencyMode.Multiple,
    AddressFilterMode = AddressFilterMode.Any, 
    ValidateMustUnderstand = false)]
public sealed class ServiceRouter : IServiceRouter

ProcessMessage操作：

    public Message ProcessMessage(Message requestMessage)
    {            
        //Figure out the url of the downstream service             
        string serviceName = requestMessage.Headers.GetHeader<String>(ServiceNameMessageHeader, String.Empty);
        string url = String.Format(_destinationUrlFormat, _destinationAppName, _destinationAppVersion, serviceName);
        EndpointAddress endpointAddress = new EndpointAddress(url);

        using (ChannelFactory<IServiceRouter> factory = new ChannelFactory<IServiceRouter>(_binding, endpointAddress))
        {
            factory.Endpoint.Behaviors.Add(new MustUnderstandBehavior(false));
            IServiceRouter proxy = factory.CreateChannel();

            using (proxy as IDisposable)
            {
                try
                {
                    IClientChannel clientChannel = proxy as IClientChannel;

                    // invoke service
                    Message responseMessage = proxy.ProcessMessage(requestMessage);

                    return responseMessage;
                }
                catch (Exception ex)
                {
                    // ...
                }
            }
        }
    }

- Pking

---

“服务路由器”这个术语并不十分准确。展示其源代码和更详细地解释其工作原理等做法，将会大大提高您获得帮助的可能性。我们无法确定该服务路由器是如何实现的，更不用说为什么会运行缓慢了。 - Darin Dimitrov

我理解，但我们的第一步只是要知道路由服务调用的总体思路是否有问题，还是故障在于我们具体的实现。 - Pking

我已经在上面的帖子中添加了更多有关实现的细节。 - Pking

你是否考虑过在WCF 4.0中使用内置的RoutingService？我在生产环境中使用它时获得了非常好的性能体验。 - Sixto Saez

谢谢，我会查看内置的路由服务。 - Pking

我尝试过在WCF 4中使用内置路由器，但问题仍然存在。不知道为什么当经过路由器时，IIS/服务处理负载会更差。 - Pking

Answer 1

一个WCF服务不应该导致如此严重的瓶颈，但是当我们不知道你的WCF服务确切的功能和配置时，很难给出精确答案。正如你所说：

“没有路由，我们可以处理大约120个并发用户，然后会出现超时错误，尽管我们会遇到超时，但IIS仍然会处理请求。有了路由器，IIS在大约20个并发用户时停止处理请求，并且在负载测试的其余部分中从未恢复处理任何请求。”

我认为你已经回答了自己的问题，关于WCF服务是否存在问题，你显然需要检查它的配置、运行方式以及与“路由”相关的操作。

编辑

在这里here看一下可能影响WCF性能的一些问题。

- ChrisBD

---

是的，路由似乎存在问题。 - Pking

我已经发布了一篇博客的链接，可能会对你有所帮助。 - ChrisBD

Answer 2

看起来我们的问题与IIS上的应用程序池有关，因为路由服务和它路由到的服务都使用了同一个应用程序池，导致以下情况发生：IIS为发送到路由器服务的请求创建了线程..路由服务向被路由到的服务发出请求，导致IIS为其创建新线程——直到没有更多可用的线程且所有线程都等待IIS处理其请求时，即线程全部堵塞。

- Pking