性能分析小案例系列, 可以通过下面链接查看哦
https://www.cnblogs.com/poloyy/category/1814570.html
系统架构背景
其中一台用作 web 服务器, 来模拟性能问题
另一台用作 Web 服务器的客户端, 来给 Web 服务增加压力请求
使用两台虚拟机 (均是 Ubuntu 18.04) 是为了相互隔离, 避免交叉感染
VM2 运行 ab 命令, 初步观察 Nginx 性能
简单介绍 ab 命令
ab(apache bench)是一个常用的 HTTP 服务性能测试工具
可以向目标服务器并发发送请求
运行 ab 命令
并发 10 个请求测试 VM1 的 Nginx 性能, 总共测试 100 个请求
ab -c 10 -n 10 http://172.20.72.58:10000/
从 ab 的输出结果可以看到, Nginx 能承受的每秒平均请求数只有 14.73(这也太辣鸡了吧)
那到底是哪里出了问题呢
接下来, 我们将通过 top,perf 来再次观察一波啥问题
深入分析
长时间运行 ab 命令
并发 10 个请求测试 VM1 的 Nginx 性能, 总共测试 10000 个请求
ab -c 10 -n 10000 http://172.20.72.58:10000/
VM1 终端运行 top 命令
输入后, 按 1, 查看每个 CPU 的使用率
系统中有几个 PHP-fpm 进程的 CPU 使用率加起来接近 200%
而每个 CPU 的用户使用率 (us) 也已经超过了 96%, 接近饱和
结论: 正是用户空间的 PHP-fpm 进程, 导致 CPU 使用率骤升
分析 PHP-fpm 进程到底是因为哪个函数导致了 CPU 使用率升高
在 VM1 终端运行 perf 命令
perf record -g -p 84408
record: 录制的意思
-g: 开启调用关系分析
-p: 指定 PHP-fpm 的进程号 84408
录制约 30s 后, ctrl+c 终止进程, 然后可以在当前目录下看到 perf.data 文件
然后执行下面命令, 分析报告(perf.data)
perf report
按方向键可上下切换, 有 + 的按回车键可以展开
可以看到, 最终是关系到 sqrt 和 add_function 这两个函数
查看 Nginx 应用的源码, 找到问题根源
找到 sqrt 函数
grep sqrt -r App/
原来只有 sqrt 函数在 App/index.PHP 文件中调用了
找到 add_function 函数
grep add_function -r App/
会发现找不到, 因为 add_function 是 PHP 内置函数
查看 index.PHP 源码
- <?PHP
- // test only.
- $x = 0.0001;
- for ($i = 0; $i <= 1000000; $i++) {
- $x += sqrt($x);
- }
- echo "It works!"
可以看到, 这里有一个循环很多次的代码段
解决方法
找到问题的根源, 就可以快速解决了, 删除循环代码块
- <?PHP
- echo "It works!"
perf 拓展
其实有一条命令更方便查看函数
perf top -g -p 84408
那为啥我要用 perf record 然后再用 perf report 呢
因为如果没有 perf 源码的话, 是无法读取到 PHP 的函数, 只会显示一堆十六进制码
修复问题后, 验证 Nginx 性能是否有所变化
VM2 终端再次运行 ab 命令
ab -c 10 -n 10000 http://172.20.72.58:10000/
可以看到每秒请求数突飞猛进的升到 2500
来源: https://www.cnblogs.com/poloyy/p/13399302.html