我正在测试支持连续查询的数据流系统的性能。
它是这样工作的： - 有一个轮询服务将数据发送到我的系统。 - 当数据传入系统时，每个查询都基于当前时间的流窗口进行评估。 - 数据传入时窗口滑动。
我的问题是，当我向系统添加更多查询时，我应该预计吞吐量会降低，因为它无法应对数据速率。
但是，我实际上观察到吞吐量增加。
我不明白为什么会这样，我猜这与 JVM 分配 CPU、内存等的方式有关。
谁能解释我的问题？
【问题讨论】：
标签： java jvm streaming continuous
大多数 Java 虚拟机最初都会对 JVM 字节码进行交互，这比本机机器码的执行速度稍慢。当 JVM 发现您正在重复使用代码的特定部分时，它会将该部分代码编译为本机机器代码（提高其处理速度）。因此，有时对代码进行压力测试，甚至让代码运行更长时间，往往会加快执行速度，而不是减慢执行速度。 HotSpot JVM（来自 SUN 的默认 JVM）是最著名的 JVM，它执行本机编译以加快代码执行速度。
此外，与您过去可能遇到的一些库相比，许多 Java 库都非常成熟。这意味着他们可能不是分配线程来处理请求，而是在套接字上使用非阻塞侦听器、可重新分配的工作线程的线程池或任何数量的适合高吞吐量处理的技术。再加上 JIT（类似 HotSpot）JVM 的自我调整，对 Java 进行基准测试是一个相当大的挑战。一般来说，运行时间越长，事情就会变得越快，直到某个点。
【讨论】：
与往常一样，答案是配置文件。不过，只是提供一个猜测：Hotspot VM 在开始使用它的 JIT 魔法之前需要进行相当多的传递。
【讨论】：
您的问题在技术细节上非常简单，但这是一个猜测。
如果 IO 流子系统相当高效（例如基于select）并且单个客户端不会使网络接口饱和，那么许多客户端的存在可能会增加总吞吐量，因为服务器进程可以处理更多数据。
【讨论】：
Java 应用程序的性能，尤其是微基准测试（对一小段代码进行基准测试）在 Java 中可能非常困难，因为 JVM、JIT 编译器和垃圾收集器会对性能产生巨大且难以预测的影响程序。
Java 并发和性能大师 Brian Goetz 有一系列优秀的文章“Java 理论与实践”：
【讨论】：
另一个愚蠢的理论：嗯，吞吐量当然会随着负载的增加而增加，至少在你达到容量之前是这样。如果您平均每秒可以处理 100 个查询，并且您平均每秒发送 10 个查询，那么每秒吞吐量为 10 个查询。如果将负载平均增加到 100qps，吞吐量将（接近）100qps。之后当然会变得更糟。你不是接近容量了吗？抱歉，如果您确实排除了这种情况。
【讨论】：