对ServiceFabric代理的初始调用非常慢

时间:2017-05-09 10:13:19

标签: performance proxy azure-service-fabric

每当我从另一个呼叫一个服务结构服务时,代理上的第一个呼叫非常慢,即比所有后续呼叫慢100倍。我已经将该记录中的时间安排在紧接呼叫之前的时间,然后立即调用服务方法中的时间,这很容易超过60秒!服务结构群集是在12个节点/ VM上运行的独立群集。

有趣的是,第一次呼叫所花费的时间长度似乎与节点数量有关,即如果我停用一半节点,则时间减少(尽管不是一半)。此外,当在我的本地PC上运行的开发集群上运行完全相同的代码时,第一次呼叫所花费的时间通常是大约8秒,随后的呼叫采取<在任一系统上均为10毫秒。此外,在同一客户端进程中为同一服务创建另一个代理仍会导致快速调用时间,似乎代理工厂(我相信每个客户端进程的SF缓存)是在第一次使用代理时创建的,并且很长一段时间。

有趣的是,没有抛出异常,服务实际上有效!

所以我的问题是,为什么在使用ServiceProxy.Create()创建的代理上第一次从一个服务调用另一个服务需要这么长时间?

2 个答案:

答案 0 :(得分:3)

根据The SF remoting docs(见下文,强调我的),ServiceProxy.Create是ServiceProxyFactory的包装器,第一个调用还涉及为后续调用设置工厂。

  

ServiceProxyFactory是一个为不同的远程接口创建代理的工厂。 如果您使用API​​ ServiceProxy.Create创建代理,那么框架将创建单例ServiceProxyFactory。当您需要覆盖IServiceRemotingClientFactory属性时,手动创建一个是很有用的。工厂是一项昂贵的操作。 ServiceProxyFactory维护通信客户端的缓存。最佳做法是尽可能长时间地缓存ServiceProxyFactory。

答案 1 :(得分:2)

我没有经历任何接近你所拥有的缓慢解决方案,但是当我的API服务使用依赖注入启动时,我创建了我的代理。

我的系统设置方式是无状态API服务(asp.net核心)与后端SF服务进行通信。

我实际上可能遇到更长的延迟,但是当我使用应用程序时,解析过程已经开始并完成,而不是在我向应用程序发出第一个请求时开始的解析。

    private void InitializeContainer(IApplicationBuilder app)
    {
        // Add application presentation components:
        Container.RegisterMvcControllers(app);
        Container.RegisterMvcViewComponents(app);

        // Add application services.
        Container.Register(() => ServiceProxy.Create<IContestService>(FabricUrl.ContestService), Lifestyle.Transient);
        Container.Register(() => ServiceProxy.Create<IFriendService>(FabricUrl.FriendService), Lifestyle.Transient);
        Container.Register(() => ServiceProxy.Create<IUserService>(FabricUrl.UserService), Lifestyle.Transient);
        Container.Register(() => ServiceProxy.Create<IBillingService>(FabricUrl.BillingService), Lifestyle.Transient);
        Container.RegisterSingleton(AutoMapperApi.Configure());

        // Cross-wire ASP.NET services (if any). For instance:
        Container.RegisterSingleton(app.ApplicationServices.GetService<ILoggerFactory>());
        // NOTE: Prevent cross-wired instances as much as possible.
        // See: https://simpleinjector.org/blog/2016/07/
    }