本文主要是介绍8年经验之谈 —— 服务端性能瓶颈定位思路总结！，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
01、软件性能测试目标
软件性能测试的目的主要有以下三点：
-
评价系统当前性能，判断系统是否满足预期的性能需求。
-
寻找软件系统可能存在的性能问题，定位性能瓶颈并解决问题。
-
判定软件系统的性能表现，预见系统负载压力，在应用部署之前，评估系统性能。
而对于用户来说，则最关注的是当前系统：
-
是否满足上线性能要求？
-
系统极限承载如何？
-
系统稳定性如何？
02、软件性能测试中关键指标
资源指标
资源指标
-
CPU使用率：
指用户进程与系统进程消耗的CPU时间百分比，长时间情况下，一般可接受上限不超过85%。
-
内存利用率：
内存利用率=（1-空闲内存/总内存大小）*100%，一般至少有10%可用内存，内存使用率可接受上限为85%。
-
磁盘I/O:
磁盘主要用于存取数据，因此当说到IO操作的时候，就会存在两种相对应的操作，存数据的时候对应的是写IO操作，取数据的时候对应的是是读IO操作，一般使用% Disk Time（磁盘用于读写操作所占用的时间百分比）度量磁盘读写性能。
-
网络带宽：
一般使用计数器Bytes Total/sec来度量，Bytes Total/sec表示为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较。
系统指标
-
并发用户数：
某一物理时刻同时向系统提交请求的用户数。
-
在线用户数：
某段时间内访问系统的用户数，这些用户并不一定同时向系统提交请求。
-
平均响应时间：
系统处理事务的响应时间的平均值。事务的响应时间是从客户端提交访问请求到客户端接收到服务器响应所消耗的时间。对于系统快速响应类页面，一般响应时间为3秒左右。
-
事务成功率：
性能测试中，定义事务用于度量一个或者多个业务流程的性能指标，如用户登录、保存订单、提交订单操作均可定义为事务
-
超时错误率：
主要指事务由于超时或系统内部其它错误导致失败占总事务的比率。
现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：691998057【暗号：csdn999】
03、性能问题排查的过程
在性能测试过程中，如果出现性能问题，需要测试人员重点关注资源指标和系统指标或者应用性能数据，系统指标是直接观测到的测试数据，比如响应时间过长，事物请求成功率低，超时错误率高等等。
当系统指标出现问题时一般会表现在资源指标上，比如cpu高，内存占用多，网络宽带占用高，连接数多等。
当观测到系统资源异常时，比如响应时间长，事物成功率低，超时错误率高等情况时。应该先查应用相关信息，比如日志，应用监控、数据库等等信息，如果这些信息没有问题，再对资源信息进行分析。
资源信息分析如下：
-
CPU问题分析：
一般情况下CPU满负荷工作，有时候并不能判定为CPU出现瓶颈，比如Linux总是试图要CPU尽可能的繁忙，使得任务的吞吐量最大化，即CPU尽可能最大化使用。因此，一般判断CPU为瓶颈，主要从两方面：一是CPU空闲持续为0，二是运行队列大于CPU核数（经验值3-4倍），即可判定存在瓶颈，对于CPU高消耗主要由什么引起的，可能是应用程序不合理造成，也可能是硬件资源不足，需要具体问题具体分析，比如问题SQL语句引起，则需要跟踪并优化引起CPU使用过高的SQL语句。
-
内存问题分析：
一般至少有10%可用内存，内存使用率可接受上限为85%。当空闲内存变小时，系统开始频繁地调动磁盘页面文件，空闲内存过小可能是内存不足或内存泄漏引起，需要根据系统实际情况监控分析。
-
磁盘I/O问题分析：
磁盘I/O对于数据库服务器、文件服务器、流媒体服务器系统来说，更容易成为瓶颈，一般从以下几个方面对磁盘I/O进行分析判断：
每磁盘I/O数可用来与磁盘的I/O能力进行对比，如果经过计算得到的每磁盘I/O数超过了磁盘标称的I/O能力，则说明确实存在磁盘的性能瓶颈。
监控磁盘读写，如果磁盘长时间进行大数据量读写操作，且cpu等待超过20%，则说明磁盘I/O存在问题，考虑提高磁盘I/O读写性能。
-
网络带宽问题分析：判断网络带宽是否是系统运行性能瓶颈的首要条件是网络带宽是否会影响系统交易执行性能。例如：减小网络带宽，并发用户数、响应时间与事务通过率等性能指标是否不能接受；或者增加网络带宽，并发用户数、响应时间与事务通过率等性能指标会得到明显提高。
在实际性能测试中，如果发现始终报连接超时，而实际手工访问可以正常访问，可以通过ping应用服务器IP或网关IP，如果出现网络严重延迟或丢包，则说明网络不稳定，需要检查网络。
通过对资源指标的分析，实际上各个方面都是互相依赖的，不能孤立的单从某个方面进行排查。
当一个方面出现性能问题时，往往会引发其他方面的性能问题，例如，大量的磁盘读写势必消耗CPU和IO资源，而内存的不足会导致频繁地进行内存页写入磁盘、磁盘写到内存的操作，造成磁盘IO瓶颈，同时，大量的网络流量也会造成CPU过载，所以，在分析性能问题时，需要从各个方面进行考虑。
软件性能测试是执行、监控、分析、调优不断进行的过程，即监控是为分析提供更多的参考数据，分析是为了进行调优，调优是解决当前系统存在的性能瓶颈，为用户提供更好、更快的客户体验。
由于分析、调优需要根据具体问题进行具体分析，本文未做过多说明，只对通用的关键指标进行监控分析，建议在实际工作中可从资源指标与系统指标两个方面，层层检测、步步排查，性能问题就无处藏身，一旦找到出现问题的原因，性能问题也就迎刃而解！
下面是配套资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！
最后： 可以在公众号：程序员小濠 ！ 免费领取一份216页软件测试工程师面试宝典文档资料。以及相对应的视频学习教程免费分享！，其中包括了有基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。
如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一键三连哦！
这篇关于8年经验之谈 —— 服务端性能瓶颈定位思路总结！的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
