爲什麼Java lmax disruptor在通過EventProcessors傳遞事件時有很大的延遲？

我在我的項目中有一個環形緩衝區，其中很多發佈者將發佈事件（例如500個發佈者），並且我有3個EventProcessors應該按順序處理事件。所有事件都應該通過這種方式：爲什麼Java lmax disruptor在通過EventProcessors傳遞事件時有很大的延遲？

{很多出版商} - > {UpStreamProcessor} - > {DownStreamProcessor} - > {LogProcessor中}

的問題是，我失去了很多時間在傳遞活動在UpStreamProcessor的發佈和啓動之間，以及UpStreamProcessor的結束以啓動DownStreamProcessor。

例如，當我有500個發佈者時，它在UpStreamProcessor和DownStreamProcessor中處理的平均持續時間爲1ms，而在UpStreamProcessor完成時間和DownStreamProcessor開始時間之間持續400ms。

這是用於構建環形緩衝器和處理器的代碼段：

SequenceBarrier sequenceBarrier; 

receiveBuffer = new RingBuffer<>(
    MessageContext.FACTORY, 
    new MultiThreadedLowContentionClaimStrategy(inputBufferSize), 
    new YieldingWaitStrategy() 
); 

upStreamAgentProcessor = new BatchEventProcessor<>(
    receiveBuffer, 
    receiveBuffer.newBarrier(), 
    new UpStreamAgent() 
); 
sequenceBarrier = receiveBuffer.newBarrier(
    upStreamAgentProcessor.getSequence() 
); 

downStreamAgentProcessor = new BatchEventProcessor<MessageContext>(
    receiveBuffer, 
    sequenceBarrier, 
    new DownStreamAgent() 
); 
sequenceBarrier = receiveBuffer.newBarrier(
    downStreamAgentProcessor.getSequence() 
); 

logMapAgentProcessor = new BatchEventProcessor<MessageContext>(
    receiveBuffer, 
    sequenceBarrier, 
    LogMap.getInstance() 
); 


receiveBuffer.setGatingSequences(logMapAgentProcessor.getSequence()); 

operationalExecutor.submit(upStreamAgentProcessor); 
operationalExecutor.submit(downStreamAgentProcessor); 
operationalExecutor.submit(logMapAgentProcessor);

來源

2013-10-30 Saeed

所有的時間聽起來都很長。你確定它是毫秒而不是微秒？你確定所有的代碼已經被預熱了嗎？你有多少個CPU？您嘗試使用相同資源的生產者越多，其訪問速度就越慢。我會盡量減少製造商的數量，理想情況下少於您擁有的CPU數量。你是否糾正了協調遺漏？ –

是的，他們是毫秒，但1毫秒不是很長，因爲它總是0廣告，有時會達到1毫秒。我有4個CPU。我不知道任何有關協調省略 – Saeed

擾斷是設計來處理這取0.0001毫秒消息如果一個1毫秒或甚至0.1毫秒的延遲不打擾你，我使用普通的ExecutorService。如果您看到延遲或超過0.001毫秒，則不太可能會造成干擾，並且您正在執行的任務所花費的時間太長。

這是關於協調省略的一個很好的介紹。 http://www.infoq.com/presentations/latency-pitfalls壞消息是，如果你有一個瓶頸，讓你看起來比較慢，那麼延遲可能會比你測量的要差很多。

來源

2013-10-30 10:10:20

如果我的處理器持續約1ms，哪種解決方案適合我的項目？使用隊列？ – Saeed

@saeed幾乎任何東西都適合，即使JMS速度較慢。 1毫秒是3,000,000個時鐘週期，這對計算機來說是永恆的。我會使用看起來最簡單的解決方案。這並不能解決你的問題，但它可以幫助你更詳細地解決你的問題。我懷疑你正在試圖通過一個緩慢的消費者爲你提供太多的事件來給你帶來不便。如果每秒超過1000個事件，那麼1毫秒太慢;如果每秒有100個事件，則超過1毫秒。 –

我無法加載網絡上的任何Flash實體導致我的互聯網約束。我有沒有關於協調遺漏的好文件？ – Saeed

爲什麼Java lmax disruptor在通過EventProcessors傳遞事件時有很大的延遲？

回答

相關問題