系统与数据库2017people.eecs.berkeley.edu编辑精选
为什么事件驱动对高并发服务器是个坏主意（2003）
Why events are a bad idea for high-concurrency servers (2003)
进阶 · 约 45 分钟读完前置知识：操作系统线程与调度基础、事件驱动编程模型、并发服务器设计
导读
这篇 2003 年的 HotOS 论文（Berkeley 的 Brewer 等人）挑战了当时流行的观点，论证事件驱动架构并非高并发服务器的最优选择，认为设计良好的线程模型在性能、可扩展性和编程复杂度上可以与事件模型竞争甚至更优。论文基于当时 2×2GHz Xeon、1GB 内存的 Linux 服务器进行测试。
HN 关注点：事件驱动 vs 线程是服务器编程的经典争论（nginx 与 Apache 是典型代表），这篇论文是该话题的标志性文献，HN 上每隔几年就会重新讨论一次。
后来怎么样
这篇 HotOS 观点论文引发了关于线程与事件驱动模型优劣的长期争论，其论点在后续十余年的系统研究中被反复检验和引用，成为并发服务器设计领域讨论线程可扩展性时的经典参考文献。
HN 评论精选
这几条评论里：支持 1 质疑 2 补充 1
质疑论文结论受限于 2003 年的硬件水平，如今参考价值有限
值得注意的是这是 2003 年的论文，事件驱动服务器的性能顾虑已被硬件和软件的进步大大缓解。论文的测试环境是 2×2000MHz Xeon SMP、1GB 内存、Linux 2.4.20——2003 年的扎实服务器配置，但基本相当于今天 Digital Ocean 上每月 5 美元的机器。如果你想在这样一台 5 美元的服务器上跑 10 万个并发任务，这篇论文才对你有意义。
pavlov查看英文原文
Worth noting this is from 2003. The performance concerns of event-based servers have been greatly alleviated by both hardware and software advancements. The test setup used for this paper was a "2x2000 MHz Xeon SMP with 1 GB of RAM running Linux 2.4.20". Solid PC server iron for 2003, but basically equivalent to a $5/month server from Digital Ocean today. If you're looking to squeeze 100,000 concurrent tasks from that $5 server, this paper is relevant to you.
支持作者以 2020 年 Sigmetrics 论文实证支持：实现良好的线程可媲美事件模型
我们即将发表的论文结果明确证实了这篇论文的观点：如果实现得当，线程的性能和可扩展性可以与事件模型一样好，且内存开销不大。我在博士期间研究这个课题，成果将发表在 Sigmetrics 2020。我们开发了一个 M:N 用户级线程库，在 32 核和 64 核服务器上用 memcached 和 web 服务器与事件驱动方案及 pthread 方案做了详尽对比测试。论文和源码见：https://cs.uwaterloo.ca/~mkarsten/papers/sigmetrics2020.html
saman_b查看英文原文
The results of our to be published paper clearly confirm the claims of this paper and shows that if implemented well, threads can perform and scale as good as events with not much memory overhead. I worked on this subject during my Phd, and the result is a paper that will be published in sigmetrics2020. We developed an M:N user-level threading library and exhaustively tested it against event-based alternatives and pthread based solutions. We used both memcached and webservers to test it on 32 core and 64 core servers. Even connection/pthread looks promising in terms of performance. You can find the paper and source files here: https://cs.uwaterloo.ca/~mkarsten/papers/sigmetrics2020.html
质疑反方观点：nginx 的事件驱动架构在连接数扩展上明显优于线程方案
事件驱动能处理的连接数远超线程方案。例如 nginx 采用事件驱动架构，官方博客称每个 worker 进程可扩展到数十万连接，每个新连接只增加一个文件描述符和少量内存，上下文切换很少发生；而每连接一进程的阻塞式方案每个连接都需要大量额外资源，上下文切换频繁。不过今天很多服务器仍用 thread-per-connection，也可接受，比如 Postgres 的性能随活跃连接增多是缓慢下降的。
the_unproven查看英文原文
Events can handle much more connections than a thread based approach. For example nginx is implemented with event-driven architecture: https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/ > NGINX scales very well to support hundreds of thousands of connections per worker process. Each new connection creates another file descriptor and consumes a small amount of additional memory in the worker process. There is very little additional overhead per connection. NGINX processes can remain pinned to CPUs. Context switches are relatively infrequent and occur when there is no work to be done. > In the blocking, connection‑per‑process approach, each connection requires a large amount of additional resources and overhead, and context switches (swapping from one process to another) are very frequent. This is their explanation on events vs threading approach. Still, a lot of web servers today use a thread-per-connection which is acceptable since a database(e.g. postgres) performance degrades slowly as more active connections are introduced.[1] [1] https://brandur.org/postgres-connections
补充从上下文切换成本角度论证：少量线程轮询消息队列优于每事件一线程
现代处理器远快于内存和持久化存储等外围设备，处理器和编译器擅长优化对连续内存块的顺序访问模式。任务间上下文切换代价高昂，因为处理器状态必须（至少部分）序列化保存，还会丢失缓存的隐式上下文。因此，让若干线程（数量取决于硬件能力和任务可分解程度）轮询消息队列，比为每个事件开一个独立线程合理得多。围绕消息传递设计的语言显然是这类编程的明智之选。
mjevans查看英文原文
Modern processors are much faster than the outlying memory and persistent storage devices. They and compilers in combination are relatively good at optimizing for predictable patterns of using sequential blocks of the outlying memory. Context switches between tasks are expensive, because the state of the processor must be (at least partially) serialized and stored as well as the loss of the implicit context of the caches. Thus it makes /far/ more sense to have a number of threads (dependent on the hardware capacity and how readily the problem can be divided to independent or very loosely coupled tasks) which poll message queues than it does to have a completely independent thread for every event. Languages based around message passing are thus the obvious choice for this type of programming.
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2017Hacker News 讨论帖72 分 · 11 评
- 2020Hacker News 讨论帖115 分 · 45 评
同领域还值得读
I/O 比 CPU 更快——让我们划分资源并消除操作系统抽象
I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions
指出在现代服务器硬件上 I/O 速度已接近甚至超过 CPU，传统操作系统抽象反而成为瓶颈。
系统与数据库2019 · 817 分 · 277 评进阶 · 约 30 分钟编辑精选使用 io_uring 的高效 I/O
Efficient IO with io_uring
由 Linux 内核开发者 Jens Axboe 撰写，介绍 Linux 新的异步 I/O 接口 io_uring。
系统与数据库2019 · 426 分 · 96 评进阶 · 约 45 分钟编辑精选线程对大多数用途而言是个坏主意（1995）
Threads Are a Bad Idea for Most Purposes (1995)
这篇 1995 年的文章由 John Ousterhout 撰写，讨论为什么线程对大多数用途而言是坏主意，并主张事件驱动编程通常更简单、更高效。
系统与数据库2017 · 423 分 · 382 评进阶 · 约 25 分钟编辑精选学习型索引结构之论证
The Case for Learned Index Structures
提出把索引看作一种"模型"：既然 B-tree 等结构本质上是在学习数据的分布，就可以用机器学习模型（如回归模型、神经网络）来近似键到位置的映射，从而替代 B-tree、哈希索引…
系统与数据库2017 · 398 分 · 66 评 · 引用 25进阶 · 约 60 分钟编辑精选FoundationDB：一个分布式、解耦的事务型键值存储
FoundationDB: A distributed, unbundled, transactional key value store
介绍 FoundationDB：一个分布式、解耦设计的事务性键值存储。
系统与数据库2021 · 283 分 · 99 评进阶 · 约 90 分钟编辑精选