负载测试并非易事。 通常不仅要下载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