2017-05-09 53 views
4

每當我從另一個呼叫一個服務結構服務時,代理上的第一個呼叫非常慢,即比所有後續呼叫慢100倍。我已經把時間記錄在電話前的那個時間,然後立刻調用服務方法,這很容易超過60秒!服務架構羣集是運行在12個節點/虛擬機上的獨立羣集。ServiceFabric代理的初始呼叫非常慢

有趣的是,第一次調用的時間長度似乎與節點的數量有關,即如果我停用一半節點,則時間減少(儘管不是一半)。另外,當在本地PC上運行的開發集羣上運行完全相同的代碼時,第一次呼叫的時間長度通常約爲8秒,隨後的呼叫在任一系統上都會花費< 10毫秒。此外,在同一客戶端進程中爲同一服務創建另一個代理仍然會導致快速的通話時間,看起來好像代理工廠(我相信SF按每個客戶端進程緩存)是在首次使用代理時創建的,很長時間。

有趣的是,沒有任何例外情況發生,而且服務真正起作用!

所以我的問題是,爲什麼第一次在使用ServiceProxy.Create()創建的代理上從一個服務調用另一個服務需要很長時間?

回答

1

我沒有遇到緩慢的解決方案,無論你有什麼附近,但是當我的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/ 
    } 
3

根據The SF remoting docs(見下文,重點煤礦),ServiceProxy.Create是圍繞ServiceProxyFactory的包裝,並在第一次調用還包括設置在工廠的後續調用。

ServiceProxyFactory是一個爲不同遠程接口創建代理的工廠。 如果您使用API​​ ServiceProxy.Create創建代理,那麼框架將創建單例ServiceProxyFactory。當您需要重寫IServiceRemotingClientFactory屬性時,手動創建一個會很有用。工廠是一個昂貴的操作。 ServiceProxyFactory維護通信客戶端的緩存。最佳實踐是儘可能緩存ServiceProxyFactory。