|
软件测试中性能调优的过程解析
前言
业界衡量一个软件系统性能的三个指标：TPS(Transactions Per Second)，QPS(Query Per Second)以及RT(Response Time)，其实前二者可以等价于写操作和读操作。如此说来，系统性能优化无非是提升读写的效率，对应到实际应用场景就是增加系统的吞吐量，最终对于用户的直观感受就是较低的响应时延。
性能调优
无疑是个庞大的话题，也是很多项目中非常重要的一环，性能调优难做是众所周知的，毕竟性能调优涵盖的面实在是太多了，在这里我们蜻蜓点水般的来看看性能调优这项庞大的工程都有些什么过程，同时也看看这些过程中常见的一些做法。
过程
确定性能调优的目标
性能调优，首先是要确定性能调优的目标是什么，如果现在应用已经满足了需求，就没必要去做性能调优了，毕竟不经过一个系统的过程，其实是无法确定你所做的性能调整是否真的调优了性能，是否没有造成应用中其他的问题，所以确定性能目标是非常重要的，在定义性能目标的时候通常怎么定义的呢：
1、 最大并发数
同时刻同一时段在被测试系统上并且操作的人数。
2、Quality of Service
服务的质量，在软件系统方面我们认为主要表现在请求的出错率，系统的load等。
3、最长响应时间
对于任何请求所能承受的最大响应时间。
4、TPS
每秒需要支持的最大事务数，最典型的指标是：“某页面最高需要支撑每秒7000次的访问次数”。
例如一个web系统，需要定义出来的目标是：
并发目标：最高支撑200并发；
QoS：出错率须控制在万分之一，系统的load最高只能到达10；
TPS：每秒完成7000次请求的处理；
最大响应时间：最长允许的响应时间为5秒。
至于请求的平均响应时间这些就不在性能调优目标中定义，因为要达到TPS的要求，响应时间是必须要达到一个级别的，而且响应时间随着高并发是会出现劣化的。
当然，还可以把性能指标定到更为细节，例如某个方法的TPS在100并发时需要达到多少。
在确定好了性能目标后，重要的就是如何来测量系统的性能了。
测试系统性能
对于新系统而言，需要评估出其正式运行时的数据量的增长情况；而对于已运行的系统，则需要根据监控获取到系统的运行数据（例如高峰并发数、系统的响应速度情况、系统的load、网络流量、每类请求在总的请求中所占的百分比等）。
对于新系统而言，要评估出具体的性能相对来说稍微好做一点，因为此时系统通常较为单纯，数据量的增长也不可能是一夜之间增长的，因此基本可以按照一种正常的方法在测试环境评估出其正式运行的性能。
而对于已运行的系统而言，则较为麻烦，因为通常来讲要在测试环境中模拟正式运行环境基本是不太可能的，因此这个时候通常要采取一些模拟的方法或更高压力的方法来尽量更为准确的评估出系统的性能。
在测试系统性能时，通常可采用的方法有：
1、单元测试
可借助单元测试来测试某个请求的性能；
2、压力测试
压力测试无疑是测量系统性能中最常采用的方式，根据定义的性能目标对系统进行压力测试，以确定系统是否满足性能要求，同时也可以根据压力测试的结果来分析系统的瓶颈，进而进行对应的调优，可用于做压力测试的工具还是不少的，像loadrunner、jmeter等等。
分析系统性能瓶颈
根据测量系统性能的结果，多数是可以分析出系统性能的瓶颈，同时还可以结合像jvm堆栈、jprofiler、系统日志等来进行进一步的确定，另外也可以根据性能调优人员的经验，例如可以去了解开发人员是否采用了不适合的数据结构等。
简单说一个线程分析的例子：
借助kill -3 pid来获取到目前jvm的线程堆栈信息，特别需要关注的是里面wait for monitor这样的线程，这种线程是指在等待锁的线程，等待一两分钟后再次kill -3 pid，看看这些wait for monitor的线程的变化情况，这对于分析线程中是否存在不合理的竞争过高的锁的分析是非常重要的。
这一步无疑也是性能调优过程中最难的一步了，分析系统性能瓶颈这种基本只能结合实际例子来讲了，正确在后续抽取一两个例子来进行讲解。
性能调优
在分析出系统性能的瓶颈后，其实这一步相对来说还好做些，当然，需要建立在对软硬件知识都有很好的深入了解的基础上，在这里列举一些比较常见的性能调优的手段，多数是抄来或google来的，自己在这方面的经验还不多，希望大家多加指点。
在性能调优时，也应参考以上顺序，按照由易到难的原则进行性能调优：
1、硬件
2、参数（中间价、数据库、操作系统）
3、SQL语句优化
4、应用代码优化（业务逻辑和算法以及代码质量）
5、数据库设计
如何定位性能问题：
性能问题调优更多的时候是一个网络（对局域网，可以不考虑网络瓶颈）、应用服务器、DB服务器等几个环节的一个平衡的调整，所以在定位问题的时候，更多的是从系统的全局着手，分析问题不能只考虑性能问题点，性能测试的环境一定要独立、干净，性能调优的策略和方案一定要清晰、明确！
- 软件架构
软件的架构方面：
https://blog.csdn.net/weixin_43258870/article/details/95372032?utm_medium=distribute.pc_relevant.none-task-blog-utm_term-7&spm=1001.2101.3001.4242
a. 分层与解耦
b. 使用缓存
c. 读写分离
d. 负载均衡
e. 区分核心业务与非核心业务
2. 业务流程
单次请求
1.Request请求Body与Response响应Body的数据应该尽可能少
2.请求链路应该尽可能短/依赖尽可能少
3. Response的Body中应该尽可能减少额外的依赖
并发请求
- 将不存在顺序依赖的多个请求合并为单次请求
- 限制最大并发请求量
德实赋值
|