WCF服务路由,瓶颈?

发布于 2024-12-24 21:40:56 字数 2292 浏览 0 评论 0原文

我们的应用程序服务器体系结构经过设置,以便每个服务调用都经过自定义构建的 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)
                {
                    // ...
                }
            }
        }
    }

Our application server architecture is setup so that every service call goes through a custom built WCF service router - a single service that distributes the incoming requests to an appropriate service using information embedded in the message header of requests.

We are experiencing performance problems using this WCF service router (timeouts when load-testing with concurrent users). We wonder if this is because of a bug in the router, that we configured the services/IIS wrong or if it is to be expected - every call going through a single service sounds like a potential bottle-neck.

Without routing we can handle about 120 concurrent users before getting timeout errors and although we get timeouts the IIS keeps handling requests. With the router the IIS stops handling requests with about 20 concurrent users and never resumes handling any requests throughout the rest of the load-testing.

Our main question is if this is to be expected when using a service router or should the IIS be able to handle this load the way we have it setup?


The routing service looks like this:

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

The implementation:

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

The ProcessMessage operation:

    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)
                {
                    // ...
                }
            }
        }
    }

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

£冰雨忧蓝° 2024-12-31 21:40:56

不,不应期望 WCF 服务会给您带来如此大的瓶颈,但是当我们不确切知道您的 WCF 服务的用途或配置方式时,很难给出确切的答案,但正如您所说:

如果没有路由,我们之前可以处理大约 120 个并发用户
收到超时错误,尽管我们收到超时,但 IIS 仍保留
处理请求。使用路由器,IIS 停止处理请求
大约有 20 个并发用户,并且永远不会恢复处理任何请求
整个负载测试的其余部分。

我认为您已经回答了有关 WCF 服务导致问题的问题。显然,您需要检查它的配置、运行方式以及它对“路由”的作用。

编辑

看看此处解决了一些可能影响 WCF 性能的问题。

No a WCF service shouldn't be expected to cause you such a major bottle neck, but it's difficult to give an exact answer when we don't know exactly what your WCF service does, nor how it is configured, but as you said:

Without routing we can handle about 120 concurrent users before
getting timeout errors and although we get timeouts the IIS keeps
handling requests. With the router the IIS stops handling requests
with about 20 concurrent users and never resumes handling any requests
throughout the rest of the load-testing.

I think that you've answered your own question with regard to the WCF service causing problems. You'll obviously need to check how it is configured, run and what it does with the "routing".

edit

Have a look here at some issues that can affect WCF performance.

活雷疯 2024-12-31 21:40:56

看起来我们的问题是 IIS 上的应用程序池,因为路由服务和它路由到的服务使用相同的应用程序池,发生了以下情况:IIS 为发送到路由器服务的请求创建了线程。服务向路由到 IIS 创建新线程的服务发出请求 - 工作正常,直到没有更多可用线程并且路由服务请求的所有线程都在等待 IIS 处理其请求,即 IIS 陷入死锁。

Looks like our problem was with application pools on the IIS, since the routing service and the services it routed to was using the same application pool the following happened: the IIS created threads for the requests going to the router-service.. the routing-service made requests to the services routed to that the IIS created new threads for - worked fine until there where no more threads available and all the threads where routing-service requests waiting for the IIS to handle their request, i.e. the IIS got deadlocked.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文