这种情况是有效的压力测试吗？
我有一个服务器应用程序，它以不同的方式处理客户端请求。
我想知道可以以最小的延迟为多少用户提供服务，因此我制作了一个小型压力测试应用程序来模拟用户的请求； 同时另一个应用程序监视内存/CPU 利用率。
压力测试工具每秒创建线程，其中每个线程代表一个用户。 如果压力测试由于缺乏资源而无法创建新线程，则会启动压力测试工具的新实例。
问题是，每个线程都会将每个请求的延迟和当前运行的线程数写入文件，因此这会导致 I/O 问题，因为几分钟后，您有很多线程需要写入磁盘，这种行为也会导致 I/O 问题。在实际场景中不存在，因为客户端仅请求数据。
当我想测量每个用户的最大延迟时，如何克服这个问题？
PS：
有些答案说要在不同的机器上运行以考虑网络延迟，这将是我的最终压力测试，目前我正在同一台服务器上进行此测试，以了解以最小延迟支持多少用户。
I have a server application that handles clients requests in different manner.
I want to know how many users can be served with minimal latency, so I made a small stress test application that simulate the users requests; at the same time another application monitor the memory/CPU utilization.
The stress test tool creates thread every second where every thread represents a user.
If the stress test can not create a new thread due to lack of resources it starts a new instance of the stress test tool.
The problem is, every thread writes into the file the latency for each request and the current number of threads running so this causes I/O problem as after couple of minutes you have a lot of threads that need to write into disk also this behavior will not be exist in the real scenario as the client only request the data.
How can I overcome this problem as I want to measure the maximum latency per user?
PS:
Some answers say to run on different machine to take into consideration the network latency ok, this well be my final stress test currently I am doing this test on the same server to find how many users are supported with minimal latency.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
目前还不清楚这是否是一个网络应用程序。 如果它是联网的，那么您可以通过在周末窃取每个人的桌面来运行压力测试来简单地扩展压力测试。 如果只是一些临时测试，这可能是扩展测试的最简单方法。
然而，听起来确实可以进行一些简单的改进。 如果这是一个长时间运行的压力测试，您可以创建一个线程池来工作，而不是为每个请求创建一个新线程（或者更简单，使用线程池，它将自动扩展）。 因此，您可以将测试定义为 2000 个用户，并启动 2000 个锤击服务器的线程。 每个线程本质上都处于一个执行测试并重复的循环中。
另一个不清楚的问题是所有线程是否都试图共享一个文件。 减少瓶颈的一种方法是将信息保留在内存中，直到程序关闭。 或者启动一个编写器线程，该线程负责文件写入，所有其他线程都为其提供信息。 如果 IO 确实得到备份，您的写入线程将简单地保留在内存中，直到 IO 可用，并且您的工作线程可以同时继续攻击服务器。 请记住，由于涉及线程同步，这可能无法很好地扩展，因此您可能希望在工作线程中缓冲一些条目，并且仅每 100 个请求同步到文件编写器线程一次。 我认为这不会是一个大问题，因为听起来您除了跟踪响应时间之外没有跟踪任何其他内容。
编辑：根据评论
在这种情况下，我建议尝试使用单个线程来管理 IO 操作。 所有工作线程都不会写入文件，而是创建一个包含任何详细信息的对象，并将其传递到要写入文件的队列。 要减少锁定/解锁，请在工作线程中使用队列，并且仅每隔一段时间进行同步。 确保在线程中交换信息时锁定。 另外，我可能会观察内存使用情况，因为这将允许任何待处理的内容在内存中累积。 如果这仍然导致您的 io 阻塞，我会考虑减少写入，或者调整或添加更快的硬盘。
It's not really clear whether this is a networked application or not. If it's networked then you can simply scale the stress test by stealing everyone's desktop over the weekend to run the stress test. This may be the easiest way to scale the test if it's just a few ad-hoc tests.
However, it does sound like there could be some simple improvements. If this is meant to be a long running stress test, instead of creating a new thread for every request, you can create a pool of threads to work from (or even easier, use the thread pool, which will scale automatically). So you would define a test to be say 2000 users, and spin up 2000 threads that hammer the server. Each thread would essentially be in a loop that does the test, and repeats.
Another item that isn't clear is whether all you're threads are trying to share a single file. One way to make this less of a bottleneck would be to keep the information in memory until the program is shutting down. Or spin up a writer thread, that is responsible for the file write, and all you're other threads give it information. If IO does get backed up, you're writer thread will simply hold in memory until IO is available, and you're worker threads can continue to hammer the server in the mean-time. Just keep in mind, that due to the thread synchronization involved, this may not scale well, so you may want to buffer some entries in the worker thread and only synchronize to the file writer thread once every 100 requests. I don't think this will be much of an issue since it doesn't sound like you're tracking anything more than response times.
Edit: Based on comment
I would suggest trying to use a single thread to manager you're IO operations in this case. All of you're worker threads would instead of writing to file, create an object with whatever the details are, and pass it to a queue to be written to file. To cut down on lock / unlocks, use a queue within the worker thread as well, and only sync every so often. Make sure you do lock when you're exchanging the info in the thread. Also, i'd maybe watch the memory usage since this will allow anything pending to build up in memory. If this is still causing you're io to block, i'd look at either writing less, or maybe tuning or adding a faster hard disk.
如果您对每个用户的最大延迟感兴趣，为什么不直接在线程中收集它，并在停止测试时让所有线程写入我们的最大延迟。 您也可以进行统计，计算最小/最大/方差以及运行的线程/用户数。 您也不应该更新屏幕输出。 如果您担心数据丢失，请经常将数据写入磁盘。
对于客户端/服务器应用程序执行此测试的线程不是最佳的。 只有有限数量的核心，只有很少的线程真正并行运行，但获得了它们的时间片。 在多个客户端上启动程序要好得多，并且还可以为您提供一些有关网络延迟的数据。 服务器软件可以 - 如果能够这样做 - 使用其硬件，就像在最终设置中一样，客户端将在 LAN 或 WAN 中运行。
显然，您将拥有一个混合环境，因为您不能像用户模拟那样拥有许多客户端计算机，但是诸如来自独立硬件的同时调用之类的场景将出现在这样的压力测试中，因为调用不是通过时间切片进行准序列化的。
If you are interested in the maximum latency per user, why not just collect this in the thread and when stopping the test have all the threads write our there max latency. You could do statistics as well, calculating min/max/variance and number of threads/users running. You shouldn't update screen output either. if you fear data loss, write the data out to disk frequently.
Threads are suboptimal doing this test for a client/server app. Having only a limited number of cores, only very few of the threads really run in parallel, but get their timeslices. It is much better, and gives you some figures on network latency as well, to start your program on several clients. The the server software can - if able to do so - use it's hardware as it will in the final setting, where clients will run in a LAN or WAN.
Obviously you will have a mixed environment, as you cannot have a many client machines as users simulated, but scenarios like simultaneous calls from independent hardware will show up in such a stresstest as calls are not quasi serialized through timeslicing.