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

目前还不清楚这是否是一个联网的应用程序。如果它是联网的,那么你只需在周末偷取每个人的桌面来运行压力测试,就可以简单地扩展压力测试。如果只是一些特殊的测试,这可能是扩展测试的最简单方法。

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

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

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

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

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

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