2013-10-15 81 views
3

此服務是一個remote session pool。我需要請求與其他服務合作。在大多數情況下,這個池將有一個會議可用,所以在15ms我會有一個迴應。但有時候,它需要按需創建一個會話,需要長達800ms才能創建。我應該爲外部服務設置哪個超時時間?

我心裏有兩個選項來處理這種情況:

  1. 要設置超時時間爲15ms,並實現重試的政策了一個指數退避至800毫秒。無論我是否連接到該服務,該服務都將創建所需的會話。

  2. 設置800ms超時,並保持連接到該服務,直到我有一個會話可用。

在這兩種情況下,我都無法保證800ms後會有一個會話。

所以問題是:哪些是每個選項的贊成/反對?

+0

您認爲每種選擇的優缺點是什麼? – Kristian

+0

我沒有一個有根據的意見,這就是爲什麼我問。我的一些論據是: 15ms: +可以將會話缺失與系統工作緩慢區分開來(對我來說非常重要) 800ms: +客戶端的簡單代碼 – Leandro

回答

1

1。要設置15ms的超時時間,並實施重試策略,並以指數回退直到800ms。無論我是否連接到該服務,該服務都將創建所需的會話。

  1. 檢測會話不是立即可用,不需要等待這幾乎是一秒鐘。
  2. 客戶可以再次請求會話或以其他方式進行請求,您可以爲不同的用例提供更多的靈活性。
  3. 您可以區分每次執行回退策略時等待會話超過15毫秒的非預期事件,這對檢測異常會話池行爲有用。

缺點

  1. 的代碼是因爲後備行爲更加複雜。
  2. 由於超時時間不同,有多個參數。

2。設置800ms超時,並保持連接到服務,直到我有一個會話。

  1. 簡單和直觀的實現
  2. 簡單的參數化

缺點

  1. 你不能看到從會話的會話創建事件延遲池。這對跟蹤和診斷非常重要,這種簡單的方法可能會隱藏會話池問題。
  2. 針對不同客戶用例的靈活實施。

-

我想這個決定驅動程序是,如果你需要一個只是工作對於這種使用情況,或者如果這種做法將被用於不同的客戶端和使用情況的解決方案。


PS:如果你需要創建針對不同客戶的解決方案也許將是值得創建一個更復雜的協議,如:

// just takes a session if available, no more than 15msec delay expected 
get_session(...) : session 

// if not available, creates one 
get_session_or_create(...) : session 

available_sessions(...) : int 

// between 0 and 1, the proportion of available sessions 
availability(...) : double 

... 

這取決於客戶端如何使用它。

而且根據會話創建延遲方差,超出了某個安全%的超時參數。

相關問題