服务结构:服务之间的通话是否延迟? [英] Service Fabric: Calls between services are delayed?

问题描述

我们正在研究由几种不同的服务组成的服务结构应用程序，我们的应用程序工作方式的关键部分是这些服务需要大量调用.

We are working on a service fabric application made up of several different services, and a key part of the way our application works is that these services need to call each other in high volumes.

直到最近，当我们增加了应用程序的负载并发现它的运行速度大大降低时，我们才出现问题.经过大量的调查和安排了各种事情的时间后，我们发现问题似乎在于，当我们对一种类型的服务(其中有多个实例)进行大量调用时，这些调用之间似乎有些延迟，并且该服务实际上开始处理该请求.

We have had no problems until recently when we increased the load on our application and found it massively slowed down. After much investigation and timing various things we found that the issue seems to be that when we are making a lot of calls to one type of service (of which we have several instances), the calls seemed to be some delay between us calling the service, and the service actually beginning to process the request.

我们正在按照Microsoft 此处

We are calling between services as described by Microsoft here

更清楚一点:ServiceA获取对ServiceB的引用，然后调用ServiceB.GetResult()，我们在ServiceA中记录该方法被调用的时间，而我们在GetResult()中所做的第一件事是记录该方法被调用的时间.处理开始.当没有负载时，只有几毫秒，一旦我们增加负载，我们发现这些时间之间会有 4-5秒延迟.

To be clearer: ServiceA gets a reference to ServiceB, then calls ServiceB.GetResult(), we log the time that this method is called in ServiceA, and the first thing we do in GetResult() is log the time that the processing begins. When there is no load there is only a few ms, once we increased the load we found there to be a 4-5 second delay between these times.

服务结构是否受到某种限制?我们有多个ServiceB实例，群集上的资源使用情况基本没有，CPU徘徊在10％左右，所有节点上的内存使用率大约为1/4，但是该服务的吞吐量非常低，因为它在这里等待.

Is this some kind of limit in service fabric? We have multiple instances of ServiceB and the resource usage on the cluster is essentially nothing, CPU hovers around 10% and memory use is about 1/4 on all nodes, but the throughput of the service is very low becuase it is waiting here.

为什么要等待?服务一次可以处理不同呼叫的方式是否存在某种已定义的限制?我们的交流做错了什么吗?

Why does it wait? Is there some kind of defined limit on how different calls a service can handle at a time? Have we done something wrong with our communication?

谢谢.

推荐答案

MaxConcurrentCalls设置似乎正是我所需要的.

The MaxConcurrentCalls setting seemed to be what I needed.

连接到服务时:

            FabricTransportSettings transportSettings = new FabricTransportSettings
            {
                MaxConcurrentCalls = 32
            };

            ServiceProxyFactory serviceProxyFactory = new ServiceProxyFactory(
                (c) => new FabricTransportServiceRemotingClientFactory(transportSettings));

            service = serviceProxyFactory.CreateServiceProxy<T>(serviceUri);

创建服务侦听器:

protected override IEnumerable<ServiceInstanceListener> CreateServiceInstanceListeners()
    {
        FabricTransportListenerSettings listenerSettings = new FabricTransportListenerSettings
        {
            MaxConcurrentCalls = 32
        };
        return new[]
        {
            new ServiceInstanceListener(
            (context) => new FabricTransportServiceRemotingListener(context,this,listenerSettings))
        };
    }

这篇关于服务结构:服务之间的通话是否延迟?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！