问题标签 [throughput]

TL;DR：我的反应堆吞吐量是否可能受到限制？我该怎么说？io_service 的实现有多昂贵和可扩展性（跨线程）？

我有一个非常大规模的并行应用程序，运行在具有大量 RAM 和快速 SSD RAID 的超线程双四核至强机器上。这是使用 boost::asio 开发的。

这个应用程序接受来自大约 1000 台其他机器的连接，读取数据，解码一个简单的协议，并将数据打乱到使用 mmap() 映射的文件中。该应用程序还使用 madvise(WILLNEED) 预取“未来”mmap 页面，因此它不太可能阻塞页面错误，但可以肯定的是，我已经尝试生成多达 300 个线程。

这是在 Linux 内核 2.6.32-27-generic（Ubuntu Server x64 LTS 10.04）上运行的。Gcc 版本是 4.4.3，boost::asio 版本是 1.40（两者都是 Ubuntu LTS）。

运行 vmstat、iostat 和 top，我看到磁盘吞吐量（在 TPS 和数据量中）是个位数的 %。同样，磁盘队列长度总是比线程数小很多，所以我不认为我受 I/O 限制。此外，RSS 攀升，但随后稳定在几场演出（如预期的那样）并且 vmstat 显示没有分页，所以我想我没有内存限制。CPU 恒定在 0-1% 用户，6-7% 系统，其余为空闲。线索！一个完整的“核心”（记住超线程）占 CPU 的 6.25%。

我知道系统落后了，因为客户端机器在超过 64kB 未完成时阻止 TCP 发送，并报告事实；他们都不断报告这一事实，系统的吞吐量远低于预期、预期和理论上的可能。

我的猜测是我正在争夺某种锁。我使用应用程序级锁来保护可能发生变异的查找表，因此我将其拆分为 256 个顶级锁/表以打破这种依赖关系。然而，这似乎一点帮助都没有。

所有线程都通过一个全局 io_service 实例。在应用程序上运行 strace 表明它大部分时间都在处理 futex 调用，我想这与 io_service reactor 的基于事件的实现有关。

我的反应堆吞吐量是否可能受到限制？我该怎么说？io_service 的实现有多昂贵和可扩展性（跨线程）？

编辑：我最初没有找到这个其他线程，因为它使用了一组与我的不重叠的标签：-/ 我的问题很可能是在 boost::asio 反应器的实现中使用了过多的锁定。请参阅C++ 套接字服务器 - 无法使 CPU 饱和 但是，问题仍然存在：我如何证明这一点？我该如何解决？

我正在开发一个允许在单台机器上模拟网络的程序。为此，我将 Twisted 用于异步 I/O，因为每个“连接”都有一个线程可能有点多。（我还使用他们的 NIO 在 Java 中实现了一个类似的程序）。然而，当我扩大模拟网络规模时，Twisted 的吞吐量会下降。将此与 Java 实现进行比较时，对于相同的网络规模，Java 吞吐量继续增长。（增长速度放缓，但仍在增长）。例如（Python 100 个节点 = 58MB 总吞吐量，300 个节点 = 45MB，Java 100 个节点 = 24 MB，300 个节点 = 56MB）。

我想知道是否有人对为什么会发生这种情况有任何建议？

我能想到的唯一原因是 Java 让每个“对等点”都在自己的线程中运行（其中包含自己的选择器，用于监视对等点的连接）。在 python 版本中，所有内容都注册到反应器（以及随后的一个选择器）。随着 python 的扩大，一个选择器无法快速响应。然而，这只是一个猜测，如果有人有任何更多的具体信息，将不胜感激。

编辑：我按照 Jean-Paul Calderone 的建议进行了一些测试，结果发布在imgur。对于那些可能想知道测试报告的以下平均吞吐量的人。（分析是用 cProfile 完成的，测试运行了 60 秒）

Epoll Reactor：100 个对等点：20.34 MB，200 个对等点：18.84 MB，300 个对等点：17.4 MB

选择 Reactor：100 个对等点：18.86 MB，200 个对等点：19.08 MB，300 个对等点：16.732 MB

报告的吞吐量似乎上下波动的几件事是对 main.py:48(send) 的调用，但这种相关性并不令人惊讶，因为这是发送数据的地方。

对于这两个反应器，套接字上的发送函数所花费的时间随着吞吐量的降低而增加，并且对发送函数的调用次数随着吞吐量的降低而减少。（即：在套接字上发送的时间更多，在套接字上发送的调用更少。）例如，在 100 个对等点上进行 413600 次调用的 epoll {method 'send' of '_socket.socket' objects} 需要 2.5 秒，达到 5.5秒用于 300 个对等点上的 epoll，用于 354300 次调用。

为了尝试回答最初的问题，这些数据是否似乎表明选择器是一个限制因素？在选择器中花费的时间似乎随着对等点数量的增加而减少（如果选择器使一切都变慢了，难道不会期望在选择器中花费的时间会增加吗？）还有什么其他可能会减慢正在发送的数据量? （数据的发送只是每一个用reactor.calllater一次又一次注册的peer的一个函数。就是main.py:49（send））

为了检查吞吐量，我修改了蓝牙聊天示例。

1. 我在 UI 中提供了一个发送按钮，它发送一些预定义的编号。字节到服务器套接字并等待确认

2. ServerSocket 等待某个字符串，一旦获得数据，它就会通过发送确认来回复。

这里我计算的这个连接的吞吐量如下。

1. 我记录发送数据的开始时间。

2. 收到确认后，我记录结束时间。

3. 所以吞吐量将是（发送的数据大小+接收的确认大小）/花费的时间。

结果是：

dataSent(KB)-------吞吐量（每秒千位）

根据从应用程序获得的一些数据 行为是，对于 1 KB 或 5 KB 等低数据，吞吐量较小。它增加到大约 40 KB 或但在 50 KB 左右之后又开始减少。我可以看到接收端发生了一些垃圾收集，这增加了延迟。

我想知道这是否是正确的行为。为什么像 1KB 或 5 KB 这样的更少数据吞吐量会减少然后它会增加。我可以考虑哪些可能会增加延迟的事实。现在，当发送方收到接收方的确认时计算吞吐量（其完整的往返计算）。我可以像发送数据一样进行单程旅行，并且在接收到所有内容后，我会计算接收器中的吞吐量。我试过了，但是两部手机之间存在毫秒差异，这给了我错误的结果，有些时间是负值。请帮助我理解正确的行为。

我想知道如何在运行时最好地测量网络吞吐量。我正在编写一个客户端/服务器应用程序（都在 java 中）。服务器定期通过套接字向客户端发送消息（压缩媒体数据）。我想调整服务器使用的压缩级别以匹配网络质量。

所以我想测量一大块数据（比如 500kb）完全到达客户端所需的时间，包括中间的所有延迟。Iperf 之类的工具似乎不是一种选择，因为它们通过创建自己的流量来进行测量。

我能想到的最好的主意是：以某种方式确定客户端和服务器的时钟差异，包括服务器发送每条消息的时间戳，然后让客户端向服务器报告此时间戳与客户端收到的时间之间的差异信息。然后，服务器可以确定消息到达客户端所用的时间。

有没有更简单的方法来做到这一点？有没有这方面的图书馆？

我需要向我们的服务器发送大量 SIP 请求以进行测试。我发现的一种解决方案是 SIPp。现在我想测量每单位时间我的客户端可以发送的 SIP 请求的数量。SIPp 提供了设置呼叫速率的可能性，但我知道也存在物理限制（客户端 CPU、网卡……）。这就是我想首先测试的。我认为这个问题可以扩展为：如何测量一个客户端每单位时间发送的数据包数量。我考虑过通过计算一秒钟内发送的 SIP INVITE 数据包的数量（使用时间列）来使用 Wireshark，但我不知道这种方法的精度如何。

我们向客户端提供 SOAP 接口。SOAP 的吞吐量应该是每秒 1000 个请求左右，而我们只有一两个客户端。现在我们有两个选择：

1. 因为客户端可能同时发送很多请求，我们需要提供很多线程来处理这些并发请求。

2. 我们是否可以要求客户端保持少量连接，因为这些连接应该是长连接。

如果我们选择选项 1，由于短连接导致性能不佳，我们需要提供更多线程。我们需要更多资源用于这些并发线程（例如，JDBC 连接）。这很糟糕，我想。

所以，我想选择选项2。但我不知道我的选择是否容易被客户接受。那是设计模式吗？

我已经从我的机器上的二进制安装程序安装了 ejbberd-2.1.10（Win7 32bit 2.93GHz Core2Duo 3GB RAM）。由于我们的设置需要非常高的消息吞吐量，因此我查看了 性能调整参考并在我的 ejabberd.cfg 和 ejabberdctl.cfg 文件中进行了更改

{整形器，正常，{maxrate，10000000}}
ERL_MAX_PORTS=65536
ERL_PROCESSES=250000
ERL_MAX_ETS_TABLES=20000

现在当客户端A向客户端B发送消息时，每个1500字节有10条消息

所用时间如下
1）使用默认值 -14.3 秒
2）使用上面给出的我的覆盖值 - 1.70283 秒

这仍然不能满足性能要求。任何人都可以帮助我如何进一步推动这个限制？？？我是否遗漏了什么或设置了错误的值。对此的任何帮助都会非常棒。

谢谢

我使用文本协议编写了​​接受连接和轰炸消息（~100 字节）的服务器，并且我的实现能够使用第 3 方客户端发送大约 400K/秒的环回消息。我为这个任务选择了 Netty，SUSE 11 RealTime，JRockit RTS。但是当我开始基于 Netty 开发自己的客户端时，我面临着吞吐量的急剧下降（从 400K 降至 1.3K msg/sec）。客户端的代码非常简单。请您提供建议或举例说明如何编写更有效的客户端。实际上，我更关心延迟，但从吞吐量测试开始，我认为环回时有 1.5Kmsg/秒是不正常的。PS客户端的目的只是从服务器接收消息，很少发送heartbits。

更新。在服务器端，有一个定期线程写入接受的客户端通道。并且通道很快变得不可写。更新 N2。在管道中添加了 OrderedMemoryAwareExecutor，但吞吐量仍然非常低（大约 4k msg/sec）

固定的。我将 executor 放在整个管道堆栈的前面，它成功了！

我也在考虑将破坏者模式集成到我们的应用程序中。在开始使用破坏者之前，我对一些事情有点不确定

1. 我有 3 个生产者，主要是一个反序列化请求的 FIX 线程。另一个随着市场变化不断修改订单价格的线程。此外，我们还有一个线程负责反序列化从 GUI 应用程序发送的请求。所有三个线程当前都写入阻塞队列（因此​​我们看到队列上有很多争用）
2. 颠覆者谈到了单一作者原则，从我读到的内容来看，这种方法的规模最好。有什么办法可以让上述三个线程遵守单写原则？
3. 同样在典型的请求/响应应用程序中，特别是在我们的案例中，我们在内存缓存中存在争用，因为当我们使用响应更新缓存时，我们需要锁定缓存，而请求可能针对相同的顺序发生。我们如何通过破坏者处理这个问题，即我如何绑定对特定请求的响应？如果可以，我可以消除缓存上的锁定吗？

任何建议/指针将不胜感激。我们目前使用的是 Java 1.6

是否可以从 Apache 日志文件中确定每秒请求的指标？如果是这样，怎么做呢？

干杯，卡塔尔。