架构师 0 期 | 性能测试与优化

 关注
发布于: 2020 年 07 月 20 日
工作中经常听到各种人说你这系统有点慢啊，看看人家的App咋体验那么好。。。一个系统是好是坏如何来衡量？ 光评主观的感受是不够靠谱的。那如何来测量一个系统的性能呢？
﻿
性能测试以系统设计初期规划的性能指标为预期目标，对系统不断施加压力，验证系统在资源可接受范围内，是否能达到性能预期。
即，在资源有限下，不断对系统施压，看是否能达到当初规划的能力。
主观感受用户感受到的性能，直观上的感受。这一块可以通过设计来提高感受。
比如，加载网页的时候，可以在收到文章标题时就开始展示，用户可以看到网页已经显示了，而不用等到整个网页加载完成再显示。整个体验就会感觉加载的快。
客观感受一系列性能指标参数决定的。包括不同视角下的，主要有响应时间、并发数、吞吐量、性能计数器等。
﻿
响应时间（最重要）直观的反应了系统的“快慢”。
从系统发出请求到收到最后响应数据所需的时间。
并发数系统能够同时处理请求的数目。体系了系统的负载特性。（同时在线程中需要处理的，那种浏览已经加载完成的商品页面详情的不算，这种属于在线用户数）
吞吐量单位时间内系统处理的请求数量。体现了系统的处理能力。
TPS（每秒事务数）
HPS（每秒HTTP请求数）
QPS（每秒查询数）
吞吐量 = （1000/响应时间ms）* 并发数
﻿
负载测试对系统不断的增加并发请求，增加系统压力。直到系统的某项或多项性能指标达到安全临界值。
当到达时，继续增加压力，系统的能力不但不能提高，反而下降。
压力测试超过安全负载情况下，继续施压，直到系统崩溃或不能处理任何请求，以此获得系统的最大压力承受能力。
稳定性测试在特定硬件、软件、网络环境下，给系统加载一定的业务压力，使系统运行很长时间，检验系统的稳定性。
真实情况下，一般都是波浪形，所以更好的模拟，此测试应该不均匀的对系统施加压力。
﻿
﻿
﻿
全链路压测线上实施全链路压测的真实目的：
在特定的业务场景下，将相关的链路完整的串联起来同时施压，尽可能模拟用户的真实行为。
当整个流量都上来时，就会暴露出性能瓶颈，能够探测出系统的真实处理能力。
可以指导大促前的容量规划和性能优化。
﻿
全链路压测的挑战系统众多，如何让流量畅通无阻，没有死角？
咋造数据，可以贴近真实用户？
在线上真实环境模拟，如何不影响线上服务？
大促的巨大流量咋造？
构造数据
﻿
数据隔离逻辑隔离，测试的数据和正常的写一块。通过标识符区分。  可能污染线上数据。
虚拟隔离，写数据的地方做mock，并不真正写进去。  可能不准确。
物理隔离，写的时候进行判断，存在隔离的地方。
流量构造
全链路压测平台化
﻿
软件优化的基本原则（2个）1. 不能优化一个没有测试的软件2. 不能优化一个你不了解的软件性能测试指标响应时间
并发数
吞吐量
性能计数器
System Load
线程数
进程数
CPU
内存
磁盘
网络使用率
性能优化的一般方法性能测试，获得性能指标
指标分析，发现瓶颈点
架构和代码分析，寻找关键所在
优化架构和代码
性能测试，闭环
优化的分层思想机房与骨干网络优化
服务器和硬件优化
操作系统优化
虚拟机优化
基础组件优化
软件架构优化
软件代码优化
﻿
1. 机房与骨干网络优化异地多活、多机房架构
专线网络、自主CDN建设
2. 服务器和硬件优化使用更好的硬件，这个可能比优化代码啥的提升更明显。
比如固态硬盘，替换机械硬盘。
万兆网卡，替换千兆网卡。
﻿
3. 操作系统优化设置操作系统默认参数等。
﻿
4. 虚拟机优化JVM垃圾回收机制。
﻿
5. 基础组件优化替换一下更新版本的中间件，或者使用更适合的中间件。可大幅度提高性能。
﻿
6. 软件架构优化（架构三把斧）优化架构，根据情况使用缓存、异步、集群。
1. 缓存（优化读操作）从内存读，减少响应时间
减少数据库访问，降低存储设备负载压力
缓存对象，不是原始数据，减少CPU计算
主要技术方案：CDN、Redis
2.异步（优化写操作）及时响应，更好的用户体验
控制消费速度，合适的负载压力
主要技术方案：队列、kafka、MQ
3.集群使用多台设备对外提供服务。
使用者看起来就像一台服务器。
比单台增加配置，更便宜。数量理论可无限大。
7. 软件代码优化遵循面向对象设计原则和设计模式。
并发编程，多线程和锁。
资源复用，线程池和对象池。
异步编程，生产者和消费者
数据结构，数组、链表、Hash、树、图