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

Question

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

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

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

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

如何衡量每位用户的最大延迟时间？如何解决此问题？

PS：

有些答案说要在不同的机器上运行以考虑网络延迟确定，这是我最后的压力测试，目前我在同一台服务器上进行此测试，以确定支持的用户数量，延迟时间最短。

Answer 1

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

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

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

Answer 2

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

然而，听起来似乎有一些简单的改进。如果这是一个长时间运行的压力测试，而不是为每个请求创建一个新线程，您可以创建一个线程池来工作（甚至更容易，使用线程池，它将自动扩展）。所以你要定义一个测试来说2000用户，然后启动2000个线程来锤击服务器。每个线程基本上都在一个循环中进行测试，并重复。

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

编辑：根据评论 在这种情况下，我建议尝试使用单个线程来管理你的IO操作。所有工作线程都不是写入文件，而是创建一个包含任何细节的对象，并将其传递给队列以写入文件。要减少锁定/解锁，还要在工作线程中使用队列，并且每隔一段时间才进行同步。确保在交换线程中的信息时锁定。此外，我可能会观察内存使用情况，因为这将允许任何待处理的内容在内存中建立。如果这仍然导致你被阻止，我会考虑少写，或者调整或添加更快的硬盘。