英文:
Spring Webflux - performance of event loop when only one core
问题
关于Spring Webflux在仅有一个核心的硬件上的性能问题，我知道你可能会问，“为什么”，甚至可能会问，“在2020年，如何在只有一个核心的机器上运行Spring Boot应用”，或者甚至类似于“不要那样做！”
我的问题更多地是为了收集一些经验数据、有根据的理论和性能结果。
众所周知，Spring Webflux是非阻塞的，使用事件循环（而不是线程）来处理IO、计算等等。
但是，如果事件循环在只有一个核心的机器上运行，会发生什么呢？会不会是某种灾难？也许会回退到线程模型？或者IO性能会变得非常糟糕，甚至重新变成阻塞状态？
或者也许没有问题，一个核心仍然可以很好地处理一切，只是将所有事件循环的特性都回馈给自己？
谢谢。
英文:
A small question on Spring Webflux's performance, but on hardware with only one core.
I know, you might be asking, "why", or even "how in 2020, to run Springboot app on machine with only one core", or even something like "don't do that!"
My question is rather to gather some empiric data, founded theory and performance result.
Spring Webflux is well known to be non-blocking and use event loop (and not thread) in order to deal with IO, computation etc...
But what will happen if the event core is running on a machine with only just one core, will it be some kind of catastrophe? Maybe falling back to thread model? Or maybe the IO performance will be horrible and somehow regress to become blocking again?
Or maybe it will have no issue and the one core will still take care of everything fine, just performing all event loop feature back to itself?
Thank you
答案1
得分: 2
但是如果事件核心在只有一个核心的机器上运行，会发生什么？会是某种灾难吗？
没有所谓的“事件核心”，只有在标准线程上运行的“事件循环”。事件循环线程（在单核设置中很可能）只是一个单独的线程，将被调度在CPU核心上运行，就像任何其他线程一样，但是根据事件循环模型，这个单独的线程将以非阻塞的方式工作，处理所有应用程序的流量。
或许会回退到线程模型？或者IO性能会变得非常糟糕，然后又以某种方式退回到阻塞状态？
没有“回退”到线程模型，这样做也没有太多意义。如果您在没有每个请求上下文切换开销的情况下努力在您的机器上运行所有内容，那么重新引入上下文切换永远不会有所帮助。
（唯一会有帮助的情况是在事件循环中有阻塞操作的情况下，但这完全与您的代码中的错误有关，与整体系统性能无关。）
英文:
> But what will happen if the event core is running on a machine with only just one core, will it be some kind of catastrophe?
There is no "event core", just an "event loop" running on a standard thread. The event loop thread is (most likely in a single core setup) just a single thread that will be scheduled to run on the CPUs core like any other, but, as per the event loop model, that single thread will operate in a non-blocking manner, handling all the application's traffic.
> Maybe falling back to thread model? Or maybe the IO performance will be horrible and somehow regress to become blocking again?
There is no "falling back" to a thread model, and it wouldn't make much sense to do so. If you're struggling to run everything on your machine without the overhead of thread-per-request context switching, adding that context switching back in is never going to help.
(The only case where it would is where you have blocking operations on your event loop, but that's everything to do with a bug in your code and nothing to do with the overall system performance.)
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论