C++ 套接字服务器-无法饱和 CPU

问题描述：

我使用 boost::asio 用 C++ 开发了一个迷你 HTTP 服务器，现在我正在用多个客户端对其进行负载测试，但无法接近饱和 CPU。我正在 Amazon EC2 实例上进行测试，一个 CPU 的使用率约为 50%，另一个 CPU 的使用率为 20%，其余两个处于空闲状态（根据 htop）。

细节：

• 服务器每个核心启动一个线程

• 接收、解析、处理请求并写出响应

• 这些请求针对的是读取内存中的数据（本测试中为只读）

• 我使用两台机器“加载”服务器，每台机器运行一个 Java 应用程序，运行 25 个线程，发送请求

• 我看到大约每秒 230 个请求的吞吐量（这是应用程序请求，由许多 HTTP 请求组成）

那么，我应该注意什么来改善这个结果？鉴于 CPU 大部分时间处于空闲状态，我想利用额外的容量来获得更高的吞吐量，比如说每秒 800 个请求或其他。

我曾经有过的想法：

• 请求非常小，通常只需几毫秒即可完成，我可以修改客户端以发送/编写更大的请求（可能使用批处理）

• 我可以修改 HTTP 服务器以使用 Select 设计模式，这在这里合适吗？

• 我可以做一些分析来尝试了解瓶颈是什么

解决方案 1：

boost::asio 并不像您希望的那样线程友好 - boost/asio/detail/epoll_reactor.hpp 中的 epoll 代码周围有一个大锁，这意味着一次只有一个线程可以调用内核的 epoll 系统调用。对于非常小的请求，这会产生很大的不同（意味着您只会看到大致的单线程性能）。

请注意，这是 boost::asio 使用 Linux 内核设施的限制，不一定是 Linux 内核本身的限制。使用边缘触发事件时，epoll 系统调用确实支持多个线程，但要正确执行（没有过多锁定）可能非常棘手。

顺便说一句，我一直在这个领域做一些工作（将完全多线程的边缘触发的 epoll 事件循环与用户调度的线程/纤程相结合）并在nginetd项目下提供了一些代码。

解决方案 2：

由于您使用的是 EC2，所以所有赌注都无效。

使用真实硬件进行尝试，然后您也许能够看到发生了什么。尝试在虚拟机中进行性能测试基本上是不可能的。

我还没有弄清楚 EC2 有什么用处，如果有人知道了，请告诉我。

解决方案 3：

从您对网络利用率的评论来看，

您似乎没有太多的网络活动。

3 + 2.5 MiB/sec大致如此50Mbps（与您的 1Gbps 端口相比）。

我想说你遇到了以下两个问题之一，

1. 工作量不足（客户请求率低）

* 服务器阻塞（干扰响应生成）

查看cmeerw的注释和您的 CPU 利用率数字

（空闲时50% + 20% + 0% + 0%），

似乎很可能是您的服务器实现存在限制。

我赞同cmeerw的回答 (+1)。

解决方案 4：

对于如此简单的异步请求，每秒 230 个请求似乎太低了。因此，使用多个线程可能是过早的优化 - 让它正常工作并在单个线程中调整，看看是否仍然需要它们。只需摆脱不需要的锁定就可以加快速度。

本文详细介绍并讨论了 2003 年左右 Web 服务器风格性能的 I/O 策略。有人有更新的信息吗？

解决方案 5：

ASIO 适合处理中小型任务，但它不太擅长利用底层系统的功能。原始套接字调用或 Windows 上的 IOCP 都不是很好，但如果您有经验，您总是会比 ASIO 更好。无论哪种方式，所有这些方法的开销都很大，而 ASIO 的开销更大。

值得一提的是，在我的自定义 HTTP 上使用原始套接字调用，可以使用 4 核 I7 每秒处理 800K 个动态请求。它从 RAM 提供服务，这正是实现该性能水平所需要的。在此性能水平下，网络驱动程序和操作系统消耗了大约 40% 的 CPU。使用 ASIO，我每秒可以收到大约 50 到 100K 个请求，其性能变化很大，并且主要受限于我的应用程序。@cmeerw 的帖子主要解释了原因。

提高性能的一种方法是实施 UDP 代理。拦截 HTTP 请求，然后通过 UDP 将它们路由到后端 UDP-HTTP 服务器，这样可以绕过操作系统堆栈中的大量 TCP 开销。您还可以让前端自己通过 UDP 进行传输，这应该不难做到。HTTP-UDP 代理的优点是它允许您使用任何好的前端而无需修改，并且可以随意更换它们而不会产生任何影响。您只需要多几台服务器来实现它。对我的示例进行的修改将操作系统 CPU 使用率降低到 10%，这使我在该单个后端上的每秒请求数增加到刚好超过一百万。并且，对于任何高性能站点，您应该始终有一个前端-后端设置，因为前端可以缓存数据而不会减慢更重要的动态请求后端的速度。

未来似乎是编写自己的驱动程序，实现自己的网络堆栈，这样您就可以尽可能接近请求并在其中实现自己的协议。这可能不是大多数程序员想听到的，因为它更复杂。就我而言，我将能够使用 40% 以上的 CPU，并每秒处理超过 100 万个动态请求。UDP 代理方法可以让您接近最佳性能而无需这样做，但是您将需要更多服务器 - 虽然如果您每秒处理这么多请求，您通常需要多个网卡和多个前端来处理带宽，因此在那里使用几个轻量级 UDP 代理并不是什么大问题。

希望这些能够对你有用。

解决方案 6：

您有多少个 io_service 实例？ Boost asio 有一个示例，它为每个 CPU 创建一个 io_service 并以 RoundRobin 的方式使用它们。

您仍然可以创建四个线程并为每个 CPU 分配一个，但每个线程都可以轮询其自己的 io_service。