与单生产者模式相比,lmax 破坏者在多生产者模式下太慢了 [英] lmax disruptor is too slow in multi-producer mode compared to single-producer mode
问题描述
以前,当我使用破坏者的单生产者模式时,例如
Previously, when I use single-producer mode of disruptor, e.g.
new Disruptor<ValueEvent>(ValueEvent.EVENT_FACTORY,
2048, moranContext.getThreadPoolExecutor(), ProducerType.Single,
new BlockingWaitStrategy())
性能不错.现在我处于多个线程将写入单个环形缓冲区的情况.我发现 ProducerType.Multi
使代码比单生产者模式慢几倍.那种糟糕的表现是不会被我接受的.那么我应该在多个线程使用锁调用同一个事件发布方法时使用单生产者模式,可以吗?谢谢.
the performance is good. Now I am in a situation that multiple threads would write to a single ring buffer. What I found is that ProducerType.Multi
make the code several times slower than single producer mode. That poor performance is not going to be accepted by me. So should I use single producer mode while multiple threads invoke the same event publish method with locks, is that OK? Thanks.
推荐答案
恕我直言,由带锁的多线程访问的单个生产者不会解决您的问题,因为它只是将锁定从破坏者端转移到您自己的程序.
IMHO, single producer accessed by multi threads with lock won't resolve your problem, because it simply shift the locking from the disruptor side to your own program.
您的问题的解决方案因您需要的事件模型类型而异.IE.您是否需要按时间顺序消耗事件;合并;或任何特殊要求.由于您正在与破坏者和多生产者打交道,这在我看来非常像外汇交易系统 :-) 无论如何,根据我的经验,假设您需要每个生产者的时间顺序但不关心生产者之间的混合事件,我会建议你做一个队列合并线程.结构是
The solution to your problem varies from the type of event model you need. I.e. do you need the events to be consumed chronologically; merged; or any special requirement. Since you are dealing with disruptor and multi producers, that sounds to me very much like FX trading systems :-) Anyway, based on my experience, assuming you need chronological order per producer but don't care about mixing events between producers, I would recommend you to do a queue merging thread. The structure is
- 每个生产者产生数据并将它们放入自己的命名队列
- 工作线程不断检查队列.对于每个队列,它会移除一个或多个项目并将其放入您的单一生产者破坏者的单一生产者.
请注意,在上述场景中,
Note that in the above scenario,
- 每个生产者队列都是一个单一的生产者单消费者队列.
- 破坏者是单生产者多消费者破坏者.
- 根据您的需要,为了避免永远运行的线程,如果线程检查了 100 次运行并且所有队列都为空,它可以设置一些变量并转到 wait() 并且事件生产者可以 yield() 它当看到它在等待.
我认为这可以解决您的问题.如果没有,请发布您对事件处理模式的需求,让我们看看.
I think this resolve your problem. If not please post your need of event processing pattern and let's see.
这篇关于与单生产者模式相比,lmax 破坏者在多生产者模式下太慢了的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!