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

Question

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

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

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

问题是，每个线程都会在文件中写入每个请求的延迟和当前正在运行的线程数量，所以这会导致I/O问题，因为几分钟后您需要写入很多线程由于客户端只请求数据，所以在实际情况下这种行为也不存在。

因为我想测量每个用户的最大延迟，我该如何克服这个问题？

PS：

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

Answer 1

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

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

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

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

Answer 2

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

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

显然你会有一个混合的环境，因为用户不能模拟许多客户端机器，但像独立硬件的同时调用等情景会在压力测试中显示出来，因为调用不是通过时间片来准连续化的。