负载测试准则

负载测试并非易事。 通常不仅要下载JMeter或Gatling ，记录一些方案然后运行它们。 好吧，也许就是这样，但是如果您很幸运的话。 听起来像“上尉的讲话”，但最好记住一些可能浪费时间的事情。

因此，当您运行测试时，最终您将遇到瓶颈，然后必须弄清楚它在哪里。 有可能：

• 客户端瓶颈–如果您的负载测试工具使用HttpURLConnection，则客户端发送的请求数量非常有限 。 您必须从此开始，并确保有足够的请求离开负载测试机
• 网络瓶颈–检查您的出站连接是否允许所需数量的请求到达服务器
• 服务器计算机瓶颈–检查（很可能是）Linux服务器允许的打开文件数。 例如，如果默认值为1024，则最多可以有1024个并发连接。 因此增加（limits.conf）
• 应用程序服务器瓶颈–如果处理请求的线程池太低，则请求可能会一直等待。 如果其他一些微小的配置开关（例如，是否需要使用NIO，这值得单独介绍）具有错误的值，则可能会降低性能。 您必须熟悉服务器性能相关的配置。
• 数据库瓶颈–检查数据库的CPU使用率和响应时间，以查看是否不是导致请求减慢的原因。 数据库配置错误，或数据库服务器太小/很少，可能会成为瓶颈
• 应用程序瓶颈–您可能必须使用一些性能监视工具来进行自我调查（但请谨慎选择，因为其中有许多“新颖而又酷”但又不稳定且无用的工具）。 我们可以将这种类型分为两种：
  • 框架瓶颈–如果您使用的框架有问题。

您必须经常监视计算机的CPU，内存，网络和磁盘I / O使用情况，以了解何时遇到硬件瓶颈。

一个重要方面是能够以足够的请求轰炸您的服务器。 单台机器不足的可能性不大，尤其是如果您是一家大公司，并且您的产品可能在一开始就吸引大量客户和/或发出请求时也需要一定的处理能力，例如加密。 因此，您可能需要一堆机器来运行负载测试。 您使用的工具可能不支持该工具，因此您可能必须手动调整群集。

作为负载测试的结果，您必须考虑让连接等待多长时间以及何时拒绝连接。 这由客户端上的连接超时和服务器上的注册超时（或池借用超时）控制。 查看结果时也要记住这一点-响应太慢或连接被拒绝实际上是一回事-您的服务器无法处理请求。

如果您使用的是AWS，则有一些细节。 将自动缩放比例分开（可能应该至少在某些运行中将其禁用），您需要记住ELB需要预热。 多次运行测试以预热ELB（许多请求会失败，直到一切正常为止）。 另外，当使用负载平衡器并且长期连接处于打开状态（例如，您使用WebSocket）时，负载平衡器可能会永远断开其自身与位于其后的服务器之间的连接，并在新请求时重新使用它们。长寿的连接来了。

总体而言，负载（性能）测试和分析并不简单，存在许多可能的问题，但这是发布之前必须要做的事情。 好吧，除非您预计用户不会超过100。 下一次，我将使用自己的文章作为参考，以确保我不会丢失任何东西。

翻译自: https://www.javacodegeeks.com/2014/09/load-testing-guidelines.html