我們正試圖實施一個網絡應用程序，其中Apache Storm。達到Apache Storm的限制
應用
接收廣告請求一個巨大的負荷（100 TPS - 一百交易/秒），
使得他們一些簡單的計算，然後
店結果中的NoSQL數據庫
與10毫秒的最大延遲。
我們使用Cassandra作爲其書寫功能的接收器。
然而，我們已經overpassed的8 ms的要求，我們在100ms。
我們試圖通過使用螺栓的並行性來最小化緩衝區（Disruptor緩衝區）的大小並平衡拓撲結構。
但是我們仍然在20ms。
隨着4名工人（8核/ 16GB）我們在20k TPS這仍然是非常低的。
是否有優化的任何建議或
是我們剛剛達到Apache Storm
（的Java限制）的限制？
我不知道你使用的平臺，但在C++ 10ms是永恆。我認爲你正在使用錯誤的工具來完成這項工作。
使用C++，爲某些本地查詢服務應該需要微秒。
接觸多個內存位置和/或必須等待磁盤或網絡I/O的非本地查詢別無選擇，只能花費更多時間。在這種情況下，並行是你最好的朋友。
你必須找到瓶頸。
找到瓶頸後，您可以對其進行改進，異步處理和/或乘法（=並行化）。
這是一個非常有趣的建議，但它不是一個完整的解決方案。你知道處理非常好的I/O的Apache Storm（或任何開源分佈式流媒體真機）的一些替代品嗎？ –
在低延遲和高吞吐量之間存在折衷。
如果你真的需要高吞吐量，你應該依靠批量調整緩衝區的大小，或者使用Trident。
試圖避免向其他工作人員傳送元組有助於延遲低。 （本地或洗牌分組）
請不要忘記監控導致停止世界的GC。如果您需要低延遲，應該儘量減少。
我已經嘗試了這些選項，我最小化了LMAX緩衝區並使用LocalGrouping。批處理會引入額外的延遲，因此應該避免。 GC是主要問題，因爲它干擾如此之大，我們無法控制它。 –
如果員工處於完全GC狀態的時間超過預期，則不需要進一步調整。在解決其他問題之前，請調整GC以解決完全GC問題。 –
我們發現Storm因螺栓轉移成本而不適應毫秒級的延遲。 –
你能解釋一下爲什麼你需要10ms的延遲？是另一個應該從卡桑德拉讀取的系統，並對結果做些什麼？ –
好吧，最好的是風暴將結果發送到遠程服務器。這可以通過另一個內部服務器從Cassandra讀取數據並將其發送到遠程服務器來完成。但是，這些數據應該已經在卡桑德拉，收到請求後至多10毫秒。 –
然後你有你的答案，風暴應該直接發送數據到應該使用它的系統（並且如果你想爲其他原因存儲cassandra）。這將允許您在關鍵的低延遲系統中切入一步。 –