[系统运维] 从零开始自制实现WebServer（八）---- 花费两天解决性能瓶颈问题介绍一路调试历程以及推荐各种好用的工具

开发: C++知识库 Java知识库 JavaScript Python PHP知识库人工智能区块链大数据移动开发嵌入式开发工具数据结构与算法开发测试游戏开发网络协议系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程
数码: 电脑笔记本显卡显示器固态硬盘硬盘耳机手机 iphone vivo oppo 小米华为单反装机图拉丁

-> 系统运维 -> 从零开始自制实现WebServer（八）---- 花费两天解决性能瓶颈问题介绍一路调试历程以及推荐各种好用的工具 -> 正文阅读

[系统运维]从零开始自制实现WebServer（八）---- 花费两天解决性能瓶颈问题介绍一路调试历程以及推荐各种好用的工具

文章目录

前引

刚刚在写博客前想到了好多好多以前自己的往事
回想到其实这一路走过来真的觉得自己与绝大部分人走过的小学初中高中都不同也包括自己的大学

回想起来自己原来真的自己也做过好多错事犯过太多太多错误也做过很多对不起别人的事情但是距离真的自己感觉到做了错事的时候在我记忆中应该是停留在高二的时间了距离现在也快三年多四年了

有时想想啊人啊很多时候做事情真的得三思思考现在思考以往思考未来也许是这三四年内自己没有在做过什么错事心地也还算是善良一直以来都遇到好的人善良的人
到现在写博客前吃晚饭的之前去买汉堡奶茶的期间跟我的家人通话真的有的时候啊回想到以往觉得真的人真的太奇妙了回想我自己这一路走来尤其是这几年真的是啊

一直以来我都觉得我运气真的很好很多时候都能遇到对我人生有启示作用的对我未来指明道路的人或事情包括选择了我喜欢的专业我也还算不笨一直以来我都可以做自己想做的事情我的家人也一直都是无理由的支持我

我很感恩我现在所拥有的一切
我一直也很相信人在做天在看无论现在做的是好事情还是坏事情总会有一天会全部返还回来不论是好的结果还是坏的结果
希望之后自己也一直能像现在这样

原来一直不懂得一句话的含义
但行好事莫问前程
现在也能感受到一点了真的可能是这样的吧

做善良的人做一个对人善良的人做一个心地善良的人
多做好事心中做到问心无愧
人会是一帆风顺的会有好结果的
好了这部分就先写到这里吧

（八）---- 继续整改代码优化代码逻辑

1、兜兜转转了一天熟悉了很多工具但是没有找到优化

哎无奈啊苦恼啊
应该是哪里的逻辑还是有问题的

我目前的代码框架c10k 应该是承受不了的每次都会出现failed…
而且最明显的问题就是估计每次现在代码主要循环循环在主线程太明显了
但是不幸中的万幸是在哪里呢现在基本上文件描述符是全部正常关闭了

很明显现在有代码逻辑估计不知道是哪里出现了问题刚刚我仔细对比了一下 muduo库跑的时候和我的代码跑的时候的文件描述符打开情况

就是用lsof -p 随时都在看我的文件描述符最多的一个时刻我看了看大概就是在打开80多个还是什么这里的80多个应该是此刻接受比关闭多的80多个此刻而muduo库多的时候我看到了990u 也就是某一刻能够达到990多个每一瞬间几百个是非常正常的情况

但是现在我确实不知道哪里的代码逻辑出现了问题… 是卡在IO太多了还是什么地方有问题反正看出来我的主线程的负担太重了不论是C1000 还是C10k 基本上我的主线程都是CPU 80左右…
而且最烦人的是什么我的服务器目前还没有实现Logging 也就是日记库而muduo库的日记库其实是占比cpu最多的… 如果完全像我的代码目前一样没有任何输出的话肯定也是远超我的代码的…

哎头疼不知道从哪个地方入手也不知道是什么地方主线程负担会这么重… 干脆先从主线程入手对比一下我和muduo库的代码哪里有非常明显的差异的地方我再来分析一下这种差异会导致什么结果

strace是个好用的工具
我用这个工具逐步逐步分析了我的代码和 muduo库的运行流程

分析了一下午东改改西改改我还是没找到是什么问题导致的为什么主线程的负荷会这么重…

真的很头疼算了晚上回来就先不看代码了
因为长期的运算一段时间就ctrl+c把strace给中断看结果一下午虚拟机死机了好几次我发现ctrl+z 再关闭终端基本上不会死机而ctrl+c则会导致死机率异常之高

现在看到代码都头疼晚上回来算了先看看书能不能找到一些突破口有没有一些灵感发现自己主线程哪里出现了问题

在这里插入图片描述

昨天自己找了一天的问题删删补补左改右改修复了一些bug 就是很明显的编程问题自己也通过strace尝试去找到主线程究竟是哪里这么拖慢了服务器的运行速度昨天真的找了一天都没有找到

… 自己今天上午又去找到了一些很明显的代码错误
但还是没有找到服务器究竟是哪里拖慢了主线程

找了那么久我自己也测试了那么久发现主线程负荷是在80%左右也就是基本上CPU都轮转都在主线程上了由于某个非常核心的代码段严重影响了主线程接收新的文件描述符而muduo的话则是cpu非常均匀我只要电脑开了性能模式在10000并发的情况下电脑是被彻底带活了风扇乱吹

我在测试连续300秒的压力测试情况下我的服务器是出现了问题的… 如果是30/60秒的话都是没有出现任何failed的
之后在认真看看muduo库代码了仔细找一下究竟是哪里是核心问题哎…
真的是脑袋上的头发都快拧没了都没找到吃完午饭再回来看看了

在我刚刚仔细思考了会不会由于muduo在测试的时候是通过cout来输出了HEADER GET /hello 而我们的代码没有输出I/O 而主要集中运行代码子线程的任务相对而言就轻松的多自然而然主线程则CPU率就会高得多…

果不其然在我关闭了I/O 后 httpserver 也就是muduo库的httpserver明显主线程 CPU率高了起来但是同样的子线程也是一样的火力全开

我的电脑刚刚去百度了一下 i5-10400发现是6核12线程。。其实就是6核我还一直以为是8核呢
之后就都改了改成6核好了
好了不是几核的问题我的子线程给我的感觉就是不干活… 明显的不干活主线程挺累的感觉应该还是代码逻辑出现了问题才会导致这么大差异

没办法还是一点点的改吧

在这里插入图片描述

2、解决了部分问题但还是存在性能瓶颈…

刚刚找到一个非常严重的问题也是解决了部分的性能问题
问题就是我channel 发现有事件时比如有EPOLLIN 和 EPOLLOUT 竟然敲代码的时候是用if-else 来判断的。。。。那么就会造成一次触发不能执行着两个事件

子进程开始稍微动起来了但是刚刚测试了c10k 还是性能差了一些还是无法在c10k的情况下稳定的执行还是存在10000多的failed…
我在想muduo会不会也是跟我的情况差不多呢 30秒、60秒不出问题 300秒就会出现failed 但是没想到muduo c10k也能正常处理

说明我的代码还是存在有一些地方的问题下面两张截图的是muduo的子线程cpu能到50%
我改过的代码也只能到35%… 但至少这个算是这两天第一个有突破性的改进了…

muduo库 300s c10k（10k并发连接）

love'6 poor webserver（temporary will be better）
c10k

感觉分析系统调用调用了多少次没啥用… 因为毕竟可以正常运行只是哪里确实逻辑可能写的不是很好而导致效率比较低

3、终于解决性能瓶颈问题从来没有考虑的地方出了偏差两天得来不易的问题终于得以解决！

1、问题刚开始出现的出处

哈哈哈昨晚开开心心终于解决问题了！今天一觉睡到10点钟由于找了两天的问题解决了晚上请室友吃火锅了今天就不出寝室了不去图书馆了1

说实话在这两天的折磨中我真的到最后昨天出图书馆的时候想起来真的找不到问题出在哪里因为我用strace 也实实在在的跟踪了我的tiny_muduo 和muduo库的代码实在不知道哪里出了问题因为运行轨迹也是这么多

之前我还在想是不是因为重复的write read 哪里重复读/写而导致的性能瓶颈但是已经检查两天了从早到晚的看代码都没有发现哪里出了问题
有些代码有问题的也不是核心的性能瓶颈的源头因为说白了核心就在于epoll_wait tcpconnection acceptor channel

对于一些核心函数哪怕性能有差距自己没考虑什么优化也不至于会差距这么大
真的昨晚在最绝望的时候甚至产生了要不把这个项目删了一切从新来过的想法直接完完全全抄muduo 看看哪里出了问题就算这20天的时间打了水漂

可能是老天不负有心人吧也可能是真的自己在学习的路上看了一些书籍导致这个地方我写的时候出了偏差我马上去拿一下书籍因为我记得很清楚那两本书里面这个地方的参数都是这样的等一下…

下面是书里面关于listen后面的backlog 为什么我会在这里犯错…
写到这里应该各位读者就知道了问题出现在了listen的第二个参数
如果感兴趣的读者或者确实想看一下原来我写的代码的话可以去我写的第五篇webserver连载博客看一下我当时设置的backlog就是5

至于当时为什么我要设置成5 因为刚开始接触网络编程而且写到现在都是一步步迭代过来的当时根本没考虑到10000并发最开始先想的是怎么写一个能够正确运行的echo server 先把正确运行给弄出来了再说高并发的事情

而且主要刚开始学习网络编程的时候确实这些细节也不知道这么重要…
当时也想的是一个这么经典的backlog值5 这么多本书里面也写到了也就继续用下去当时理解成这个值是一个比较好的比较中立的值…

在这里插入图片描述

2、解决问题尝试过的各种方法心路历程

其实这部分也算是分享一下遇到这些问题我目前尝试过的方法
因为我觉得这部分还是挺宝贵的写像这样的网络库尤其是要求比较高并发的
更容易遇到各种问题

写出一个能够正常响应的服务器只要有思路有代码逻辑框架其实个人觉得实现起来就没有那么困难了
主要重要的是知道从哪里入手从哪里开始下手这部分其实我在最开始的几篇博客中写的还是挺多的因为那个时候我也很迷茫也没有引路人能够借鉴指导我怎么在这条路走下去

这也是我写这些博客的真的原因吧真的希望我花了时间能够帮助到各位
至少留下点属于我自己的东西

Digi ghetto这是我们的季节
疯狂的钻石才是黄金体验
这是我原来写操作系统最喜欢听的歌自立巷这里就不说了哈哈

这里就来正式介绍一下这一路上到现在我大概用了哪些方法调试吧
感觉网上写这种的还是挺少的…
我把我觉得很有用的一些工具也放在下面

1、printf（输出调试法）

这个是我还算比较喜欢的一个方法其实原来做很多东西最开始的时候都是通过这个方法来调试的不管是原来学数据结构还是写操作系统还是平时刷题有的时候感觉有些值或者有些条件或者有些运行逻辑不符合自己的预期的时候在一些适当的地方设置一些printf 然后自己用一些测试用例去尝试然后逐步找到问题我觉得这个还算是非常实用的方法了

2、strace调试（适合运行指令较多/需要看代码运行轨迹的调试）

strace 调试的话我觉得还是非常好用的
如果我这个问题不是一些比较隐晦的运行逻辑或者是确实是通过代码轨迹看不出来的问题的话

我觉得这个是绝对的利器了
尽管在解决我的问题上没有有很大的用但是通过这两天我觉得之后在工作中如果出现问题了那肯定是可以派上大用场的

这里就浅显的介绍一下我比较常用的一些组合技吧

先用pidof <process_name> 把进程的PID知道了或者用top 如果你的进程占用率高的话也可以直接看到pid
知道pid后可以有两个方式我觉得是解决问题比较好的呈现方式

1、观察运行轨迹把运行轨迹记录下来
sudo strace -p <pid> -o <strace_file_name> -o是指定输出轨迹在哪个文件 -p是指定跟踪进程
然后觉得快结束的适合可以ctrl+c运行进程或者也可以ctrl+c strace 然后记录就可以去查看了

但是需要注意一下 strace在运行的时候 cpu占用比相当高估计是在不停的IO导致的… 会使你的运行进程明显被拖慢
下面是示例图
在这里插入图片描述

2、记录系统调用次数记录系统调用的次数可以观察有哪些系统调用明显拖慢了进程运行
sudo strace -c -p <pid> -o <strace_file_name>
其实也就加了个c 如果有些系统调用明显调用的太多了看这个也能看出问题来下面给张我看我的代码运行系统调用的图

下面的截图只运行了3.8秒正常的话应该要多运行一会的…

在这里插入图片描述

3、top（监视服务器或者进线程状态）

这个top 真的也是帮了我大忙了
我分析我的服务器是否运行正常基本上就是靠top
我看cpu率还有内存占用率来判断是否运行
当然压力测试正常运行的连接数才是最主要判断是否允许的最主要的

top有几个参数是我非常常用的

例如 top就是直接的包括进程的没有筛选的
-p 可以指定进程号监视（配合pidof）
-H 监视包括同一进程下的所有线程

在监视的时候就这个项目而言
启动后先pidof查看进程号后用top -H -p <pid>即可
还有一些其他的参数啊那些就烦请各位自己去网上或者相关博客再深入了

4、tcpdump（linux下网络抓包工具）

尽管在交互的时候 tcpdump也只帮我过我一次忙但是也算有用
由于是本机测试而且 tcpdump参数太多了我也用的不是太多
下面就介绍一下我一般常用的指令吧

sudo tcpdump -i lo tcp port <port>
-i 主要就是指定主机
后面的tcp port 就是tcp协议指定端口端口一般的话是服务器的设置端口

我其实用的最多的就是这个指令了有的时候看服务器没有close文件描述符不太清楚网页发出的交互是不是关闭还是保持连接的就需要抓一下包看看是否发过来请求了确定服务器客户端目前的交互状态

由于tcpdump的指令太多了这里也就不介绍了详细的还有一些指令大家自己去查一下吧

5、netcat（好用的不行模拟客户端）

netcat是刚开始我测试是否成功交互的工具太好用了

直接讲一下我最常用的指令吧

nc <tcp address> <port> 例如 nc 127.0.0.1 233
然后就充当客户端与其交流了

如果是以HTTP协议交互的话就需要加个-C
例如 nc -C <tcp address> <port> 例如 nc -C 127.0.0.1 233
加个-C 其实也就是每句话回车后自动加个\r\n 也没其他的

还有有的时候希望断开的时间自动一点就可以加个 -w <time>
例如 nc 127.0.0.1 2333 -w 60
表示60s内没有消息交互的话就在60s后自动断开连接了

5、pstack（用过一次查看进/线程栈帧的）

尽管这里用过一次没啥用但觉得有些场合还是挺有用的
… 这里还是介绍一下吧而且gdb好像自带的有些问题必须要自己再把源码弄过来然后再链接
最后会友情提供正确的pstack代码具体怎么把错误的pstack重新链接这里就不介绍了网上查一下就好了

pstack <pid> 运行示例如下有的时候有些程序卡在一个循坏有的时候查看详细的此时的线程栈还是有奇效的

在这里插入图片描述

这里友情提供正确的pstack代码

#!/bin/sh
 
if test $# -ne 1; then
    echo "Usage: `basename $0 .sh` <process-id>" 1>&2
    exit 1
fi
 
if test ! -r /proc/$1; then
    echo "Process $1 not found." 1>&2
    exit 1
fi
 
# GDB doesn't allow "thread apply all bt" when the process isn't
# threaded; need to peek at the process to determine if that or the
# simpler "bt" should be used.
 
backtrace="bt"
if test -d /proc/$1/task ; then
    # Newer kernel; has a task/ directory.
    if test `/bin/ls /proc/$1/task | /usr/bin/wc -l` -gt 1 2>/dev/null ; then
    backtrace="thread apply all bt"
    fi
elif test -f /proc/$1/maps ; then
    # Older kernel; go by it loading libpthread.
    if /bin/grep -e libpthread /proc/$1/maps > /dev/null 2>&1 ; then
    backtrace="thread apply all bt"
    fi
fi
 
GDB=${GDB:-gdb}
 
# Run GDB, strip out unwanted noise.
# --readnever is no longer used since .gdb_index is now in use.
$GDB --quiet -nx $GDBARGS /proc/$1/exe $1 <<EOF 2>&1 |
set width 0
set height 0
set pagination no
$backtrace
EOF
/bin/sed -n \
    -e 's/^\((gdb) \)*//' \
    -e '/^#/p' \
    -e '/^Thread/p'