我正在尝试使用JMeter找到应用程序可扩展点。我将可伸缩性点定义为“任何增加不再增加每秒吞吐量的最小并发用户数”。
我正在使用以下技术。安排我的负载测试运行一个小时，每隔30秒启动一个发送SOAP / XML-RPC请求的新线程。我这样做是通过将我的线程数设置为120，将我的上升时间设置为3600秒。
然后在我的摘要报告侦听器中查看我的TOTAL行吞吐量。每30秒添加一个新行（线程），总吞吐量数量一直上升，直到在我的情况下80个线程处于活动状态后，它的平均值大约为每秒123个请求。然后，随着最后20个线程的添加，它会将吞吐量数量慢慢降至每秒120个。然后我得出结论，我的应用程序可伸缩性点是每秒123个请求，有80个活动用户。
我的问题是，这是找到应用程序可扩展点的有效方法，还是我应该尝试不同的技术？
答案 0 :(得分：1)
从技术角度来看，您正在做的事情确实回答了有关某个特定用户场景的问题，但我认为您可能会忽略大局。
首先请记住，您发送的实际HTTP请求和加速时间通常会影响您称之为可伸缩性的点。您的请求是否达到了缓存？它们不够随机吗？他们太随机了吗？它们代表现实世界的要求吗？是30秒会给你相同的结果20秒或10秒？
根据我的个人经验，在尝试分析应用程序性能时，查看图表会更容易，更直观。这不仅仅是原始数字的问题，还包括外观，趋势和变化率。
例如，这里有一个使用JMeter和交互式JMeter结果图测试ghost.org博客平台的示例。
http://blazemeter.com/blog/ghost-performance-benchmark