架构师训练营 2 期 Week07 总结

用户头像
Calvin
关注
发布于: 2020 年 12 月 07 日

性能测试

性能测试是性能优化的前提和基础,也是性能优化结果的检查和度量标准。不同视角下的网站性能有不同的标准,也有不同的优化手段。

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

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

性能测试指标

不同视角下有不同的性能标准,不同的标准有不同的性能测试指标,网站性能测试的主要指标有响应时间、并发数、吞吐量、性能计数器等。

响应时间

指应用系统从发出请求开始到收到最后响应数据所需要的时间。响应时间是系统最重要的性能指标,直观的反映了系统的“快慢”。

并发数

系统能够同时处理请求的数目,这个数字也反映了系统的负载特性。对于网站而言,并发数即系统并发用户数,指同时提交请求的用户数目,于此相对应,还有在线用户数(当前登录系统的用户数)和系统用户数(可能访问系统的总用户数)。

吞吐量

  • 指单位时间内系统处理的请求的数量,体现件系统的处理能力。对于网站,可以用“请求数/秒”或是“页面数/秒”来衡量,也可以用“访问人数/天”或是“处理的业务数/小时”等来衡量。

  • TPS(每秒事务数)也是吞吐量的一个指标,此外还有HPS(每秒HTTP请求数),QPS(每秒查询数)等。

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

性能计数器

是描述服务器或操作系统性能的一些数据指标。包括 System Load、对象与线程数、内存使用、CPU 使用、磁盘与网络 I/O 等指标。这些指标也是系统监控的重要参数,对这些指标设置报警阀值,当监控系统发现性能计数器超过阀值的时候,就向运维和开发人员报警,及时发现处理系统异常。

性能测试方法

性能测试是一个总称,具体可细分为性能测试、负载测试、压力测试、稳定性测试。

性能测试

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

负载测试

对系统不断地增加并发请求以增加系统压力,直到系统的某项或多项性能指标达到安全临界值,如某种资源已经呈饱和状态,这时候继续对系统施加压力,系统的处理能力不但不能提高,反而会下降。

压力测试

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

稳定性测试

被测试系统在特定硬件、软件、网络环境条件下,给系统加载一定业务压力,使系统运行一段较长时间,以此检测系统是否稳定。在生产环境,请求压力是不均匀的,呈波浪特性,因此为了更好地模拟生产环境,稳定性测试也应不均匀地对系统施加压力。

全链路压测

全链路压测其实指的就是在特定的业务场景下,将相关的链路完整的串联起来同时施压,尽可能模拟出真实的用户行为,当系统整站流量都被打上来的时候,必定会暴露出性能瓶颈,才能够探测出系统整体的真实处理能力,以及有指导的在大促前进行容量规划和性能优化,这便是线上实施全链路压测的真正目的。

全链路压测的挑战

  • 压测相关的业务系统上众多,并且牵涉到整条链路上所有的基础设施和中间件,如何确保压测流量能够通畅无阻,没有死角?压测的数据怎么构造(亿万级的商品和用户),数据模型如何与真实贴近?

  • 全链路压测直接在线上的真实环境进行模拟,怎么样来保障对线上无影响?

  • 大型促销活动所带来的巨大流量要怎么样制作出来?

数据隔离

  • 逻辑隔离,直接把测试数据和正常数据写到一起,通过特殊的标识能够区分开。

  • 可能污染线上数据,破坏线上数据安全性。

  • 虚拟隔离,在所有写数据的地方做 mock,并不真正的写进去。

  • 这个方案不会对线上产生污染,但是 mock 对压测结果的准确性会产生干扰。

  • 物理隔离,所有写数据的地方对压测流量进行识别,判断一旦是压测流量的写,就写到隔离的位置,包括存储、缓存、搜索引擎等等。

流量构造

天猫双十一全链路压测的流量平台是一个典型的 master+slave 结构,master 作为压测管控台管理着上千个 slave 节点;slave 节点作为压测引擎,负责具体的请求发送。Master 作为整个压测平台的大脑,负责的整个平台的运转控制、命令发送、数据收集、决策等。Slave 节点部署在全球各地的 cdn 节点上,从而模拟从全球各地过来的用户请求。整套全链路压测的流量平台在压测过程当中平稳输出 1000+w/s的用户请求、同时保持过亿的无线用户长链接。

链路压测平台化

将CDN组织起来,构建压测资源池,按需分组,使得全链路压测平台化、常态化。

性能优化

两个基本原则:

不能优化一个没有测试的软件

不 能优化一个你不了解的软件



性能优化的一般方法

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

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

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

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

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

系统性能优化的分层思想

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

  • 异地多活的多机房架构

  • 专线网络与自主 CDN 建设

  • 服务器与硬件性能优化

  • 使用更优的 CPU,磁盘,内存,网卡,对软件的性能优化可能是数量级的,有时候远远超过代码和架构的性能优化。

  • 操作系统性能优化

  • 案列:资源利用分析,发现大量 CPU操作为 sys 类型,消耗大量计算资源。

  • 虚拟机性能优化

  • 基础组件性能优化

  • 软件架构性能优化

  • 缓存

  • 从内存直接获取数据,缓存结果对象,优化读操作。

  • 异步

  • 即时响应,更好的用户体验,优化写操作。

  • 集群

  • 单一服务器计算能力有限,多台服务器使用起来像一台服务器,解决了资源问题。

  • 软件代码性能优化

  • 并发编程,多线程与锁

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

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

  • 数据结构,数组、链表、hash表和树

操作系统

程序运行时架构

程序是静态的。

程序运行起来以后,被称作进程。

未完待续。。。。。。

未完待续。。。。。。



用户头像

Calvin

关注

还未添加个人签名 2019.04.16 加入

还未添加个人简介

评论

发布
暂无评论
架构师训练营 2 期 Week07 总结