上回说了软件性能问题错误修复大法鉴赏,如果不给出正确方法,那就止步于笑谈。那么软件出了性能问题,究竟应该如何去定位呢?
1.资源
首先,我们要明白一件事,软件发生性能问题,必定是资源不够用了。资源分为硬件资源和软件资源,硬件资源有:
CPU:内存插槽,核心,硬件线程
内存:DRAM,缓存
网络:以太网,WIFI,4G
存储设备:硬盘
控制器:储存,网络
软件资源有:
互斥锁:锁的平均占用的时间是一个重要的指标,等待锁的队列侧面反映了软件的饱和度
线程池:有限的线程处理海量的工作,必然会有事务等待处理
进程/线程/协程容量:系统的进程/线程的数量是有上限的,在 golang、erlang 这种原生支持协程的语言中,协程的数量也不是无上限的
文件描述符容量:系统的文件描述符也是有上限的
2.资源使用的三个维度
资源在使用时有三个维度:utilization(使用率),saturation(饱和度),errors(错误)。我们必须要先弄清楚这三个概念,然后才能查找性能问题。
2.1 使用率
在规定的时间内,资源用于服务工作的时间百分比。
2.2 饱和度
资源不能用于服务额外工作的程度,通常有等待队列。饱和程度可以用排队长度或者排队所花时间来衡量。
2.3 错误
软件运行出错。
3.USE 方法
研究这三个维度,查找性能问题的方法就叫USE 方法,USE 方法是一种研究高使用率、高饱和状态下性能问题最有效的方法。
3.1 工作流程
错误检查优先级最高的,不仅仅时因为修复错误的优先级比较高,更因为错误更容易被发现(只要检查错误日志)。
使用率和饱和度也是有顺序的,只有当使用率高达 100% 的时候,降低饱和度才有意义 [1]。
当你使用 USE 方法的时候,很可能发现了不止一个性能问题,你关心的问题并不会在一开始就出现,你需要多选择几项资源,才能找到你所关心的性能问题。不过,理论上所有的性能问题都应该被修复(在成本允许的情况下)
3.2 资源检查
使用率有两个红线:60%,100%
根据排队理论,60% 意味着优先级较低的工作将会被排在队列后面执行。100% 意味着该资源出现了严重的性能瓶颈,亟待解决。
饱和度:任何程度的饱和都是性能瓶颈。
错误:错误都是值得研究的,不仅仅是为了解决性能问题。
3.3 收费站现象
假设高速公路的收费站,一整天的使用率是 40%,你能据此断定收费站在早高峰的时候没有排队吗?
收费站现象表明了资源即使大部分情况下都是绰绰有余,但是系统依然会出性能问题,只是需要在特定时间点才能观察到。因此,我们还需要预留应急资源,或者异步处理分担峰值压力。
4.作者的话
4.1 吐槽
我一个研究服务端性能的文章竟然找不到话题节点,只能先借用移动性能测试的节点了,麻烦管理员加个服务端性能测试节点。
4.2 性能问题正确的定位方法
4.3 注
[1] 更准确地说,应该是瞬时使用率高达 100%
如果觉得《软件性能测试瓶颈定位 软件性能问题正确定位思路》对你有帮助,请点赞、收藏,并留下你的观点哦!