写点什么

[架构师训练营第 1 期] 第七周学习总结

发布于: 2020 年 11 月 08 日

本周对性能测试有了一个全面的了解。

性能测试概述


性能测试是性能优化的前提和基础,也是性能优化结果的检查和度量标准。

不同视角下的网站性能有不同标准,也就有不同的优化手段。

  • 主观视角:用户直观感受的性能

  • 客观视角:性能指标衡量的性能


两种视角并不统一。

主观视角的性能优化通常从用户体验入手。(如渲染先后顺序、即时反馈如进度条等)

客观视角的性能优化通常从技术指标入手。


性能优化的最终目的是为了提升用户体验,主观视角的性能的优化体现在表面上,客观视角的性能提升体现在本质上,后者是前者真实性和可靠性的保证。比如前端缺少后端支持,渲染了一些假数据,主观视角上性能提升了,但实际上并没有。


主观视角的产品性能主要由产品经理关注,客观视角的产品性能主要由架构师关注。


总而言之,为了提升用户体验,必须优化产品性能,为了优化产品性能,必须找到产品性能问题,为了找到产品性能问题,必须做性能测试并分析其结果,而如何展示一个可分析的性能测试结果,就必须引入性能测试指标,而如何获得性能测试结果,就必须引入性能测试方法,为了更全面地测试系统性能、保证系统在特别高并发的情况下的高可用,还必须做全链路压测,而获得测试结果后,还需要采取相应的性能优化手段。

性能测试指标


常用的性能测试指标有:

  • 响应时间(核心)

  • 并发数(核心)

  • 吞吐量(核心)

  • 性能计数器(辅助,反映资源利用率等)

响应时间

定义:应用系统从发出请求开始,到收到最后响应数据为止,之间所需要的时间。(服务端反之)

响应时间是系统最重要的性能指标,直观反映了系统的“快慢”。

并发数

定义:系统能够同时处理请求的数目。

反映系统的负载。

对于网站,并发数可以是:

  • 系统并发用户数(同时提交请求的用户数目,或同时正在处理的请求数)

以下不是并发用户数:

  • 在线用户数(当前登录系统的用户数,可能没有同时发送请求)

  • 系统用户数(可能访问系统的总用户数,同上)

通常:系统用户数 >= 在线用户数 >= 并发用户数

吞吐量

定义:单位时间内系统处理的请求数量。

反映系统的处理能力。

对于网站,吞吐量可以用以下两个单位来衡量:

  • 请求数/秒

  • 页面数/秒

  • 访问人数/天

  • 处理业务/小时


相关指标包括:

  • TPS:每秒事务数

  • HPS:每秒 HTTP 请求数

  • QPS:每秒查询数


吞吐量与并发数的关系:吞吐量等于响应时间为 1 秒 的并发数。

比如:系统的响应时间为 500ms,则吞吐量 = 并发数/500ms = 2×并发数/秒

吞吐量 = (1000 / 响应时间 ms) × 并发数

性能计数器

定义:描述服务器或操作系统性能的一些技术指标。

包括:

  • 系统负载

  • 对象与线程数

  • 内存使用

  • CPU 使用

  • 磁盘与网络 I/O

使用时通常对这些指标设置报警阈值,并持续监控,当性能计数器超过预设阈值时,向运维或开发人员报告异常,尽快降低系统故障影响面。

性能测试方法


性能测试是一个总称,具体可细分为:

  • 性能测试

  • 负载测试

  • 压力测试

  • 稳定性测试

性能测试

定义:以系统设计初期规划的性能指标为预期目标,对系统不断施加压力,验证系统在资源可接受范围内,是否能够达到性能预期。

负载测试

定义:对系统不断施加并发请求以增加系统压力,直到系统的某项或多项性能指标达到安全临界值。

如:某种资源已经呈现饱和状态,此时持续对系统施加压力,系统处理性能不但不能提高,反而下降。

压力测试

定义:超过安全负载的情况下,对系统继续施加压力,直到系统崩溃或不能再处理任何请求,以此获得系统最大压力承受能力。

稳定性测试

定义:被测试系统在特定硬件、软件、网络环境条件下,给系统加载一定业务压力,是系统运行一段较长时间,以此检测系统是否稳定。

在生产环境下,请求压力是不均匀的,呈波浪特性。

因此为了更好地模拟生产环境,稳定性测试也应不均匀地对系统施加压力。

性能测试曲线

TPS
| | | |
| | c|_|d
| b|/ | |\
| /| | | \
|/|_||____系统资源(如服务器集群中服务器的数量,并发用户数等)
5 7 10
性 负 压
能 载 力
测 测 测
试 试 试
复制代码


问:若性能测试得到曲线如上,则正常生产环境应让系统大部分时间处于 a b c 哪个点?

答:放哪里都有道理,需要在成本与风险之间就实际情况做权衡。

全链路压测


性能测试的测试对象是单个接口,全链路压测的测试对象是整个系统。


一般情况下,系统测试只需要对几个关键的接口进行性能测试即可。


但在特殊情况下,如并发量特别大时,就需要考虑到一些不常用的接口,使用全链路压测来保证系统的稳定和可用。


全链路压测就是在特定的业务场景下,将相关的链路完整地串联起来同时施压,尽可能模拟出真实的用户行为。

当系统整站流量都被打上来时,必定会暴露出性能瓶颈,此时才能够探测出系统整体的真实处理能力,

并据此有指导地在实际投入运行(如大促)前进行容量规划和性能优化,这也是线上实施全链路压测的目的。


全链路压测的难点或挑战:

  • 压测范围无死角

  • 压测数据怎构造

  • 线上压测无影响

  • 压测流量怎模拟

性能优化:系统性能优化的分层思想


软件性能优化的两个基本原则:

  • 不能优化一个没有测试的软件:进行性能测试才能发现性能问题,分析性能问题才能进行有目的地优化,优化之后还需要进行性能测试验证优化结果。

  • 不能优化一个没有了解的软件:


性能测试的主要指标:

  • 见前


性能优化的一般方法:

  • 性能测试:获得性能指标

  • 指标分析:发现性能与资源瓶颈

  • 架构与代码分析:寻找性能和资源瓶颈的关键所在

  • 架构与代码即其他优化:优化关键技术点,平衡资源利用

  • 性能测试:进入性能优化闭环


性能优化的思想:分层

  • 机房与骨干网络的性能优化

  • 服务器与硬件的性能优化

  • 操作系统的性能优化

  • 虚拟机的性能优化

  • 基础组件的性能优化

  • 软件架构的性能优化

  • 软件代码的性能优化

机房与骨干网络的性能优化


  • 异地多活的多机房架构

  • 专线网络与自主 CDN 建设

服务器与硬件的性能优化


硬件性能优化案例:Spark 1G 网卡 -> 10G 网卡

操作系统的性能优化


硬件性能优化案例:Spark 部分版本 Linux Transparent huge page 选项默认开启 -> 关闭

虚拟机的性能优化


虚拟机的性能优化案例:Java 虚拟机

基础组件的性能优化


基础组件的性能优化案例:ODBC 中间件 Jetty 7.5.2 替代 JBoss4.0.5GA

软件架构的性能优化


软件架构的性能优化案例:

  • 缓存:优化读性能

- 从内存中获取数据:降低响应时间

- 减少数据库访问:降低存储设备负载压力

- 缓存结果对象而非原始数据:降低 CPU 计算量

  • 异步:优化写性能

- 即时响应:降低响应时间

- 控制消费速度:产生合适的负载压力(削峰填谷)

  • 集群:

软件代码的性能优化


遵循面向对象的设计原则与设计模式编程。

很多时候不是性能上有什么技术挑战,而仅仅是代码写得太糟糕。

先写好代码,再关注技术方面,如:

  • 并发编程:多线程与锁

  • 资源复用:线程池与对象池

  • 异步编程:生产者与消费者

  • 数据结构:数组、链表、hash 表、树等


软件代码的性能优化案例:Spark

发布于: 2020 年 11 月 08 日阅读数: 55
用户头像

还未添加个人签名 2018.03.26 加入

还未添加个人简介

评论

发布
暂无评论
[架构师训练营第 1 期] 第七周学习总结