是否有对10000客户端/秒问题的解决scheme进行现代审查
（通常称为C10K问题）
是否有一个更现代的c10k问题的解决scheme的审查（最后更新：2006年9月2日），专门针对Linux（epoll，signalfd，eventfd，timerfd ..）和像libev或libevent的库？
讨论所有在现代Linux服务器上解决和仍然没有解决的问题？
C10K问题通常假定您正在尝试优化单个服务器，但正如您的参考文章指出“硬件不再是瓶颈”。 因此，要采取的第一步是确保在混合中投入更多硬件并不是最简单和最便宜的。
如果我们有一个500美元的盒子每秒为X客户提供服务，那么只需再购买500美元的盒子来增加吞吐量就可以了，而不是让员工狼吞虎咽，谁知道多less小时和多less美元试图弄清楚如何挤压更多在原来的盒子外面。 当然，这是假设我们的应用程序是多服务器友好的，我们知道如何负载平衡等，等等…
巧合的是，就在几天前，Programming Reddit或者Hacker News提到了这件事：
数以千计的线程和阻止IO
在Java的早期，我的C编程的朋友们嘲笑我用套接字线程做了socket IO， 当时，没有别的select。 如今，凭借丰富的内存和处理器，这似乎是一个可行的策略。
这篇文章是2008年的，所以它把你的视野提高了几年。
要回答OP的问题，您可以说今天的等效文档并不是关于优化单个服务器的负载，而是优化整个在线服务的负载。 从这个angular度来看，组合的数量是如此之大，以至于你所寻找的不是一个文档，而是一个收集这样的体系结构和框架的实时网站。 这样一个网站存在和它的叫www.highscalability.com
附注1：
我认为，抛出更多的硬件是一个长期的解决scheme：
-
或许与单个服务器的成本相比，“获得”性能的工程师的成本高。 当您扩展时会发生什么？ 假设你有100台服务器。 服务器容量提高10％可以为您每个月节省10台服务器。
-
即使你只有两台机器，你仍然需要处理性能高峰。 在负载下正常降级的服务与发生故障的服务之间的区别在于有人花费时间优化负载情况。
附注2：
这篇文章的主题有点误导。 CK10文档并不试图解决每秒10k客户端的问题。 （每秒客户端的数量是无关紧要的，除非您在有限的延迟时间内定义一个工作负载以及持续的吞吐量，我认为Dan Kegel在写这个doc的时候已经意识到了这一点）。 把它看作一个构build并发服务器的方法的纲要，以及相同的微观基准。 也许在当时和现在之间发生了什么变化，你可以在一个时间点假定服务是为静态页面服务的网站。 今天，服务可能是一个noSQL数据存储，caching，代理或数百个networking基础设施软件之一。
你也可以看看这个系列的文章：
http://www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-3
他显示了大量的性能数据，以及为了支持10K和1M连接而必须执行的操作系统configuration工作。
看起来像一个有30GB内存的系统可以在一种社交networkingtypes的模拟上使用一个基于Erlang的应用服务器的libevent前端来处理一百万个连接的客户端。
libev对自己和libevent运行一些基准
我推荐读Zed Shaw的poll, epoll, science, and superpoll [1]。 为什么epoll并不总是答案，为什么有时甚至更好地去投票，以及如何带来最好的两个世界。
看看斯坦福的RamCloud项目： https ：//ramcloud.atlassian.net/wiki/display/RAM/RAMCloud
他们的目标是每秒100万次RPC操作/服务器。 他们有许多基准和评论系统中存在的阻碍他们达到吞吐量目标的瓶颈。
