这个场景是有效的压力测试吗？

Question

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

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

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

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

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

PS：

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

Answer 1

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

然而，听起来确实可以有一些简单的改进。如果这是一个长时间运行的压力测试，而不是为每个请求创建一个新线程，您可以创建一个线程池来工作(或者更简单，使用线程池，它将自动扩展)。因此，您可以将一个测试定义为2000个用户，并启动2000个线程来冲击服务器。每个线程基本上都在执行测试的循环中，然后重复执行。

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

编辑:基于注释，我建议尝试使用单个线程来管理本例中的IO操作。你们所有的工作线程都不会写到文件中，而是创建一个具有任何细节的对象，并将其传递到一个队列以写入文件。为了减少锁定/解锁，还可以在工作线程中使用一个队列，并且仅偶尔同步一次。当你在线程中交换信息时，一定要锁定。此外，我可能会观察内存使用情况，因为这将允许任何挂起的内容在内存中积聚。如果这仍然导致你的io阻塞，我会考虑写得更少，或者调优或添加一个更快的硬盘。

Answer 2

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

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

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