看到由於EventMachine量產引起的長時間延遲 - 我如何加快速度？

Question

我正在開發一個使用EventMachine的實時應用程序。兩個客戶端A和B通過標準TCP連接到EventMachine服務器，或者通過帶有em-websocket的WebSocket連接到EventMachine服務器。

每次數據通過EventMachine時，代碼執行都需要95ms的時間。當A與服務器通話時，延遲時間爲95毫秒。當A與B對話時，則有190ms的延遲。

如果有許多請求快速連續發生，除了序列中的最終請求之外，延遲消失。所以，如果我發送10個快速請求，每個約5ms後我會得到9個響應，但第10個響應再次需要95ms。我推斷這和EventMachine.set_quantum有關。從文檔：

方法：EventMachine.set_quantum

對於高級用戶。此功能設置默認計時器粒度 ，默認爲，略小於100毫秒。調用這個 函數來設置更高或更低的粒度。該函數影響add_timer和add_periodic_timer的行爲 。大多數應用程序 將不需要調用此函數。

避免將量程設置爲非常低的值，因爲這可能會降低在某些極端條件下的性能。我們建議你不要 使用低於10的值。

那麼，這解釋了95ms來自何處。果然，延遲更改通過調用EventMachine.set_quantum，但由於文檔中的警告，我謹慎調整此值。

set_quantum究竟是幹什麼的？我找不到任何有關量子變量含義的文檔或解釋。

我該怎麼做才能減少這些延遲？我想了解減少10ms量子的潛在影響。

EventMachine甚至是正確的選擇嗎？我基本上用它作爲榮耀的TCP連接。也許我應該堅持使用原始套接字進行進程間通信，並找到不使用EventMachine的WebSocket服務器gem。

Answer 1

EventMachine的不斷運行的循環，它會檢查：

1. 無論任何計時器得到觸發。
2. 如果任何文件描述符與它們有關。

第二步涉及引擎蓋下的適當機構，例如，撥打select(..)。這就是量子價值所在。所以基本上這個循環看起來是這樣的：

1. 任何定時器被觸發？
2. 任何文件描述符都與它們有關？等他們，最多quantum毫斯。
3. 除非有關機請求，否則請轉到第1步。

因此，將quantum設置爲較低的值會使該循環更頻繁地迭代，從而消耗CPU週期。儘管如此，我認爲這不是一個真正的問題。

讓我感到意外的是，您完全有通信延遲，因爲如果文件描述符中有事件（例如數據），所有這些查詢機制（select或epoll或其他）會立即返回。這基本上意味着你不應該招致這些延誤。如果這種延遲是由設計引起的，那麼許多瘦用戶就會對此感到不安。

所有這些讓我覺得在你的代碼中存在一些稍微不正確的東西，使得它以這種方式工作。不幸的是，除非我看到它，否則我不能說更多。

希望它有幫助！