识别 nginx php t2.micro 主机上的 Web 服务器瓶颈?

识别 nginx php t2.micro 主机上的 Web 服务器瓶颈?

我正在使用 t2.micro 实例试用 AWS 免费套餐。我使用 elasticbeanstalk 和 apache 以及 php7.1 制作了一个简单的 php 网站。我使用 apache ab load test util 向一个简单的“helloworld.php”页面发送 1000 个并发请求。平均延迟为 6.5 秒。99% 的请求都快于 13.5 秒。然后我改为使用 nginx 和 php 7.1 fpm。结果类似:平均 7.5 秒,p99 为 14 秒。

CPU 不会超过几个百分点,内存也不会达到最大值。可能是网络 I/O 延迟吗?我不确定如何测量。有什么提示可以识别瓶颈吗?在运行负载测试时,通过查看“htop”或 ec2 指标图表,没有什么特别之处。

负载测试输出示例:

ab -k -n 1000 -c 1000 -H “接受编码:gzip,deflate” -g ab_out.dathttp://example.com/public_html/api/test.html

Document Path:          /public_html/api/test.html
Document Length:        32 bytes

Concurrency Level:      1000
Time taken for tests:   16.252 seconds
Complete requests:      1000
Failed requests:        0
Keep-Alive requests:    1000
Total transferred:      284000 bytes
HTML transferred:       32000 bytes
Requests per second:    61.53 [#/sec] (mean)
Time per request:       16251.548 [ms] (mean)
Time per request:       16.252 [ms] (mean, across all concurrent requests)
Transfer rate:          17.07 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0  449 339.8    427    1038
Processing:  1037 4113 2784.5   3258   15493
Waiting:     1037 4113 2784.5   3258   15493
Total:       1196 4562 2903.3   3540   16184

Percentage of the requests served within a certain time (ms)
  50%   3540
  66%   4950
  75%   5740
  80%   6591
  90%   9252
  95%  11355
  98%  12383
  99%  12518
 100%  16184 (longest request)

编辑,更多数据点:

当我访问一个空的 html 文件时,我也遇到了同样的延迟。当我将 ab -n 和 -c 参数从 1000 减少到 100 时,延迟就合理得多了。但是,我仍然想知道为什么当我将并发请求数从 100 增加到 1000 个时,请求会变得更慢。

100次请求次数:

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       54  128  41.2    131     198
Processing:   169  376 126.4    374     592
Waiting:      169  376 126.5    374     591
Total:        223  504 167.6    505     790

答案1

我建议考虑使用更先进的负载测试工具,它可以增加负载逐步地,这样您就可以将增加的负载与增加的响应时间和减少的吞吐量关联起来。此外,敲打单个页面与现实生活场景没有任何共同之处,因为 nginx 和 elastic beanstalk 都可以缓存响应。

表现良好的负载测试需要尽可能接近地表示最终用户活动,包括 cookie、标头、缓存、嵌入式资源(图像、脚本、字体、样式)的处理、JavaScript 调用等,而 ab 工具则并非如此,因为它仅下载主 HTML 响应,而不处理任何链接内容、会话、尊重缓存控制标头等。

因此,请看一下以下替代方案:

查看开源负载测试工具:您应该使用哪一个?文章中提供了有关上述工具的更多信息,包括示例脚本、报告和功能比较表

还要确保监控操作系统健康指标,包括但不限于:

  • 中央处理器
  • 内存
  • 网络输入输出
  • 磁盘输入输出
  • 交换文件使用情况

您可以使用内置Linux 监控程序或者亚马逊云监控或者JMeter PerfMon 插件,这样您将能够说明性能下降是否是由于资源不足造成的。

最后但并非最不重要的一点是,默认的 nginx 配置适用于开发和调试,当遇到高负载时,您需要执行一些额外配置

相关内容