最高效的高性能服务器套接字/线程设计 [关闭]答案

【问题标题】：Most Efficient High-Performance Server Socket/Thread Design [closed]最高效的高性能服务器套接字/线程设计 [关闭]
【发布时间】：2013-06-26 15:01:04
【问题描述】：

我正在构建一个性能极高的企业软件，它将每秒接收、处理和响应超过 50,000 个 TCP 请求。这将分布在许多 Amazon EC2 服务器上，但我希望单个服务器能够每秒处理尽可能多的请求（以 5k/秒的速度拍摄）。我很可能会使用运行 Amazon Linux 的 m1.xlarge 实例。

我正在使用 Boost ASIO 用 C++ 构建这个软件，并且我正在尝试找出构建套接字处理的最有效方法。在示例 (http://www.boost.org/doc/libs/1_53_0/doc/html/boost_asio/examples.html) 中，我倾向于模拟“HTTP Server 2”，因为我们将有多个 vCPU 供员工使用。

谁能真正描述每个 HTTP 服务器示例的优缺点，并处理这么多的连接，我真的很感激任何额外的见解（关于 Boost 套接字和/或高吞吐量 EC2 配置）。

非常感谢！

【问题讨论】：

虽然每秒 50k 消息并没有完全消失，但我不会称其为“极高的性能”。 marketdatapeaks.com
对我来说它的性能非常好。当然它不是股票市场规模的（当然还有很多其他公司处理更大的交易量），但是这 50k 请求中的每一个都需要在后端完成相当多的处理（不仅仅是提供静态文件），所以我认为它相当密集。你有这样的经历吗？谢谢！
我知道，但不幸的是我不知道你引用的例子。

标签： c++ sockets boost amazon-ec2 boost-asio

【解决方案1】：

一些建议：

您没有提到您的服务器将要做什么。它是每秒接受和关闭 5 万个新请求，还是只为来自已建立的 TCP 连接的消息（请求）提供服务。所以我的建议可能有点笼统。

阅读C10K问题：http://www.kegel.com/c10k.html
投资使用 epoll 作为套接字通知解决方案，而不是 ASIO。 epoll 并不难。
考虑使用固定数量的线程 (2-8)。要么对这些线程之间的套接字连接进行负载平衡，要么只使用线程工作池来服务从套接字线程解析的请求消息。为多线程设计，但从仅使用 1 个线程开始。然后解决所有性能问题。一旦您使单线程解决方案运行良好并且性能达到顶峰，然后考虑增加线程数，以便可以在其他线程被阻塞的同时处理多个操作。
您的服务器的性能问题很有可能超出了套接字设计的范围。持续进行基准测试并运行 valgrind 等工具，以了解代码大部分时间花在哪里。机会很高，这是您最不期望的地方。例如，在我的服务器上，我发现大部分时间都花在为小的临时缓冲区分配和释放内存上。我永远也猜不到。然后我更改了服务器设计以预先分配内存，使用堆栈内存等......这样处理请求就不需要代码来分配内存。当我做出改变时，性能轻松翻倍。

【讨论】：

Boost asio应该使用epoll，见stackoverflow.com/questions/3106304/…
在我看来，目前没有 C10K 问题，这个链接被高估了。最近我把我们的项目从自写的 epoll reactor 转移到了 ASIO。现在它可以管理 10 倍以上的连接，并且不会在每个有问题的客户端上滞后；与手动使用库相比，TLS 也运行良好；现在所有服务器计时器都是异步的，与 epoll-version 相对（与计时器无关）。异步应用不仅是 epoll；它是计时器、错误的客户端和许多其他你只能在生产中学习的东西

【解决方案2】：

您可能希望研究非阻塞套接字并将输入/输出/处理分散到不同的线程中。可能每千个连接创建 3 个新的输入/输出/处理线程？

希望对您有所帮助。

【讨论】：