这种情况是有效的压力测试吗？

Question

我有一个以不同方式处理客户端请求的服务器应用程序。

我想知道可以以最小的延迟为多少用户提供服务，所以我制作了一个模拟用户请求的小型压力测试应用程序；同时另一个应用程序监视内存/CPU 利用率。

压力测试工具每秒创建一个线程，每个线程都代表一个用户。 如果压力测试由于资源不足而无法创建新线程，则会启动压力测试工具的新实例。

问题是，每个线程都会将每个请求的延迟和当前运行的线程数写入文件，因此这会导致 I/O 问题，因为几分钟后您还有很多线程需要写入磁盘这种行为在真实场景中不会存在，因为客户端只请求数据。

当我想测量每个用户的最大延迟时，如何解决这个问题？

PS：

有些答案说要在不同的机器上运行以考虑网络延迟，这将是我的最后一次压力测试，目前我正在同一台服务器上进行此测试，以找出以最小延迟支持多少用户。

Answer 1

目前还不清楚这是否是一个网络应用程序。如果它是联网的，那么您可以通过在周末窃取每个人的桌面来运行压力测试来简单地扩展压力测试。如果只是一些临时测试，这可能是扩展测试的最简单方法。

不过，听起来确实可以进行一些简单的改进。如果这是一个长期运行的压力测试，那么您可以创建一个线程池来工作，而不是为每个请求创建一个新线程（或者更简单，使用线程池，它会自动扩展）。因此，您可以将测试定义为 2000 个用户，并启动 2000 个锤击服务器的线程。每个线程本质上都在一个循环中进行测试并重复。

另一个不清楚的项目是你的所有线程是否都试图共享一个文件。减少瓶颈的一种方法是将信息保存在内存中，直到程序关闭。或者启动一个负责文件写入的写入器线程，而你所有的其他线程都会给它信息。如果 IO 确实得到了备份，那么您的编写器线程将简单地保留在内存中，直到 IO 可用，而您的工作线程可以在此期间继续锤击服务器。请记住，由于涉及线程同步，这可能无法很好地扩展，因此您可能希望在工作线程中缓冲一些条目，并且每 100 个请求只同步一次文件写入器线程。我认为这不是什么大问题，因为听起来您只跟踪响应时间。

编辑：基于评论 在这种情况下，我建议尝试使用单个线程来管理您的 IO 操作。你们所有人都是工作线程，而不是写入文件，而是使用任何详细信息创建一个对象，并将其传递给要写入文件的队列。要减少锁定/解锁，也可以在工作线程中使用队列，并且只每隔一段时间同步一次。确保在线程中交换信息时锁定。另外，我可能会注意内存使用情况，因为这将允许任何未决的东西在内存中建立。如果这仍然导致您的 io 阻塞，我会考虑减少写入，或者调整或添加更快的硬盘。

Answer 2

如果您对每个用户的最大延迟感兴趣，为什么不在线程中收集它，并且在停止测试时让所有线程写入我们的最大延迟。您也可以进行统计，计算最小/最大/方差和运行的线程/用户数。您也不应该更新屏幕输出。如果您担心数据丢失，请经常将数据写入磁盘。

为客户端/服务器应用程序执行此测试时，线程不是最理想的。只有有限数量的内核，只有很少的线程真正并行运行，但得到它们的时间片。在多个客户端上启动程序要好得多，并且还为您提供了一些有关网络延迟的数据。服务器软件可以 - 如果能够这样做 - 使用它的硬件，因为它将在最终设置中，客户端将在 LAN 或 WAN 中运行。

显然，您将拥有一个混合环境，因为您不能像用户模拟的那样拥有许多客户端机器，但是来自独立硬件的同时调用等场景将出现在这样的压力测试中，因为调用不是通过时间片进行准序列化的。