JMeter JDBC 数据库测试 - 最长等待时间（毫秒）
JMeter JDBC database testing - Max Wait (ms)
JDBC 连接配置中最大等待（毫秒）值的最佳做法是什么？
JDBC
我正在执行两种类型的测试：
- 每个线程数 20 个循环 - 以获得最大吞吐量
- 每个线程数需要 30 分钟的运行时间 - 以获得响应时间
在最大等待 = 10000 毫秒的情况下，我可以使用 10、20、30、40、60 和 80 个线程执行 JDBC 请求而不会出现错误。使用 Max Wait = 20000ms，我可以更高并执行 100、120、140 个线程而不会出现错误。这似乎是合乎逻辑的行为。
现在提问。
我可以根据需要增加 Max Wait 值吗？如何获得更多测试结果是正确的方法吗？
如果某些报告出现任何错误，我是否应该停止测试并且不增加线程数？我得到了例如10000 个样本的误差为 0.06%。这是为了我的测试而停止吗？
谢谢
Everything depends on what your requirements are and how you defined performance baseline.
我可以根据需要增加最大等待值吗？获得更多测试结果的正确方法是什么？
- 如果您接受更长的响应时间并且该功能应该可以正常工作，那么您可以尽可能多地保留最长时间。但是，实际上，响应时间会有阈值（例如，执行登录事务需要 2 秒），您将其定义为性能 SLA 或性能基线的一部分。因此，尽管您通过增加最大时间使请求成功，但最终由于响应时间长（通过超过阈值）而被视为失败请求
注意：数据库操作的响应时间较长最终会导致 Web 应用程序（或最终用户）的响应时间较长
如果某些报告出现错误，我是否应该停止测试并且不增加线程数？
- 同样适用于错误率。如果 SLA 表示同意某个百分比的错误率，那么如果实际错误率小于该百分比，则可以认为测试满足 SLA 或性能基线。例如：如果要求说错误率为 0%，那么 0.1% 也被视为 失败。
这是我的测试站吗？
- 您可以随时停止测试。它完全基于您要捕获的指标。据我所知，建议继续测试，直到达到无法继续测试的程度，如错误率达到 99% 等。如果错误率为 0.6%，那么我建议继续通过测试，了解系统的崩溃点，如服务器崩溃、响应时间达到不可接受的值、内存问题等
以下是一些很好的参考资料：
- https://www.nngroup.com/articles/response-times-3-important-limits/
- http://calendar.perfplanet.com/2011/how-response-times-impact-business/
- difference between baseline and benchmark in performance of an application
- https://msdn.microsoft.com/en-us/library/ms190943.aspx
- https://msdn.microsoft.com/en-us/library/bb924375.aspx
- http://searchitchannel.techtarget.com/definition/service-level-agreement
根据文档，此设置映射到 DBCP -> BasicDataSource -> maxWaitMillis parameter：
The maximum number of milliseconds that the pool will wait (when there are no available connections) for a connection to be returned before throwing an exception, or -1 to wait indefinitely
它应该与您的应用程序数据库配置的相关设置相匹配。如果您的目标是确定最大性能 - 只需将 -1 放在那里，超时将被禁用。
关于我的测试是否停止？ - 这取决于多种因素，例如应用程序正在做什么、您想要实现什么以及正在进行什么类型的测试实施。如果您测试编排核电站运行的数据库，那么零错误阈值是唯一可以接受的。而如果这是一个猫的图片库，这个错误级别可以认为是可以接受的。
在大多数情况下，性能测试分为几个测试执行，例如：
- Load Testing - 将系统置于预期负载下以查看它是否能够处理预测的用户数量
- Soak Testing - 与负载测试基本相同，但会长时间保持负载。这允许检测例如内存泄漏
- Stress testing - 确定应用程序的边界、饱和点、瓶颈等。从零负载开始并逐渐增加直到它打破提及最大用户数量、响应时间等其他指标的相关性， Throughput, Error Rate等随着用户量的增加，检查负载恢复正常后应用是否恢复等
有关上述测试类型的详细描述，请参阅 Why ‘Normal’ Load Testing Isn’t Enough 文章。
JDBC 连接配置中最大等待（毫秒）值的最佳做法是什么？ JDBC
我正在执行两种类型的测试：
- 每个线程数 20 个循环 - 以获得最大吞吐量
- 每个线程数需要 30 分钟的运行时间 - 以获得响应时间
在最大等待 = 10000 毫秒的情况下，我可以使用 10、20、30、40、60 和 80 个线程执行 JDBC 请求而不会出现错误。使用 Max Wait = 20000ms，我可以更高并执行 100、120、140 个线程而不会出现错误。这似乎是合乎逻辑的行为。
现在提问。 我可以根据需要增加 Max Wait 值吗？如何获得更多测试结果是正确的方法吗？ 如果某些报告出现任何错误，我是否应该停止测试并且不增加线程数？我得到了例如10000 个样本的误差为 0.06%。这是为了我的测试而停止吗？ 谢谢
Everything depends on what your requirements are and how you defined performance baseline.
我可以根据需要增加最大等待值吗？获得更多测试结果的正确方法是什么？
- 如果您接受更长的响应时间并且该功能应该可以正常工作，那么您可以尽可能多地保留最长时间。但是，实际上，响应时间会有阈值（例如，执行登录事务需要 2 秒），您将其定义为性能 SLA 或性能基线的一部分。因此，尽管您通过增加最大时间使请求成功，但最终由于响应时间长（通过超过阈值）而被视为失败请求
注意：数据库操作的响应时间较长最终会导致 Web 应用程序（或最终用户）的响应时间较长
如果某些报告出现错误，我是否应该停止测试并且不增加线程数？
- 同样适用于错误率。如果 SLA 表示同意某个百分比的错误率，那么如果实际错误率小于该百分比，则可以认为测试满足 SLA 或性能基线。例如：如果要求说错误率为 0%，那么 0.1% 也被视为 失败。
这是我的测试站吗？
- 您可以随时停止测试。它完全基于您要捕获的指标。据我所知，建议继续测试，直到达到无法继续测试的程度，如错误率达到 99% 等。如果错误率为 0.6%，那么我建议继续通过测试，了解系统的崩溃点，如服务器崩溃、响应时间达到不可接受的值、内存问题等
以下是一些很好的参考资料：
- https://www.nngroup.com/articles/response-times-3-important-limits/
- http://calendar.perfplanet.com/2011/how-response-times-impact-business/
- difference between baseline and benchmark in performance of an application
- https://msdn.microsoft.com/en-us/library/ms190943.aspx
- https://msdn.microsoft.com/en-us/library/bb924375.aspx
- http://searchitchannel.techtarget.com/definition/service-level-agreement
根据文档，此设置映射到 DBCP -> BasicDataSource -> maxWaitMillis parameter：
The maximum number of milliseconds that the pool will wait (when there are no available connections) for a connection to be returned before throwing an exception, or -1 to wait indefinitely
它应该与您的应用程序数据库配置的相关设置相匹配。如果您的目标是确定最大性能 - 只需将 -1 放在那里，超时将被禁用。
关于我的测试是否停止？ - 这取决于多种因素，例如应用程序正在做什么、您想要实现什么以及正在进行什么类型的测试实施。如果您测试编排核电站运行的数据库，那么零错误阈值是唯一可以接受的。而如果这是一个猫的图片库，这个错误级别可以认为是可以接受的。
在大多数情况下，性能测试分为几个测试执行，例如：
- Load Testing - 将系统置于预期负载下以查看它是否能够处理预测的用户数量
- Soak Testing - 与负载测试基本相同，但会长时间保持负载。这允许检测例如内存泄漏
- Stress testing - 确定应用程序的边界、饱和点、瓶颈等。从零负载开始并逐渐增加直到它打破提及最大用户数量、响应时间等其他指标的相关性， Throughput, Error Rate等随着用户量的增加，检查负载恢复正常后应用是否恢复等
有关上述测试类型的详细描述，请参阅 Why ‘Normal’ Load Testing Isn’t Enough 文章。