极客大学架构师训练营 性能优化 性能测试指标 性能测试 性能优化 CDN 网络 硬盘 缓存 异步 集群 第 13 课 听课总结

用户头像
John(易筋)
关注
发布于: 2020 年 07 月 22 日

说明

讲师:李智慧



架构师用了很多优化手段,如何给老板证明,性能提升了呢?



性能测试

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



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

(支付转账场景,用户点击转账后,有个倒计时的页面,即时反馈给用户,让用户感受到快。)

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



性能测试指标

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



响应时间

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



并发数

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



吞吐量

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



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

  • QPS(每秒查询数)。



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



性能计数器

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



Top 命令查看,Load Avg:正在处理的线程数 + 正在等待的线程数,三个时间段的平均时间。理想情况下是CPU的核数。

如果大于CPU的核数,表示CPU过载;如果小于CPU的核数,表示CPU空闲,资源利用不足。



性能测试方法

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



性能测试

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



负载测试

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



压力测试

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



稳定性测试

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



TPS

性能测试目标: 要把这条曲线测出来。

性能测试:a~b 并发数增加,TPS快速增加。

负载测试:b~c 并发数增加,TPS增长速度变小。

压力测试:c~d 并发数增加,TPS反而开始下降。



让系统在b点位置左右运行;如果在c点位置左右,那么就很容易系统奔溃了。

到底是在b点位置的左还是右呢?这要依赖于投资多少钱的机器。如果要省钱,那么在b点靠右的位置,安全性会低一点,到达c点比较危险。如果不差钱,那么可以多加机器(比如银行),那么就在b点靠左的位置。



响应时间

通常瓶颈点在于磁盘和内存数。



并发数 | 响应时间(ms)|TPS | 错误率(%)| Load | 内存(G)| 备注

  • | - | - | - | - | - | -

10 | 500 | 20 | 0 | 5 | 8 | 性能测试

20 | 800 | 30 | 0 | 10 | 10 | 性能测试

30 | 1000 | 40 | 2 | 15 | 14 | 性能测试

40 | 1200 | 45 | 20 | 30 | 16 | 性能测试

60 | 2000 | 30 | 40 | 50 | 16 | 性能测试

80 | --- | 0 | 100 | --- | --- | 性能测试



基于Flower的应用重构性能测试



性能测试压测可用性

重构前



Flower重构后



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

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

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



新来架构师,一看系统就觉的技术架构很落伍,要用业界比较牛的架构重构。一般这种架构师撑不过试用期。别这样,千万别这样。毕竟技术团队花了很长的时间在这套系统里面,要先了解系统。了解问题,比掌握技术更关键。不要盲目的那所谓的牛逼技术到处用。不要拿着锤子🔨去砸钉子,要先找到钉子。



性能测试的主要指标

  • 响应时间:完成一次任务花费的时间。

  • 并发数:同时处理的任务数。

  • 吞吐量:单位时间完成的任务数。

  • 性能计数器:System Load, 线程数,进程数,CPU,内存,磁盘,网络使用率。



Spark 应用性能测试

很多个Task在执行











性能优化的一般方法

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

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

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

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

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



系统性能优化的分层思想

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

  • 服务器与硬件性能优化。(垂直伸缩)

  • 操作系统性能优化。

  • 虚拟机性能优化。(垃圾回收性能优化,锁对性能的优化)

  • 基础组件性能优化

  • 软件架构性能优化

  • 软件代码性能优化



机房与骨干网络性能优化

  • 异地多活的多机房架构。

  • 专线网络与自主 CDN 建设。

从美国到中国网络传输需要300ms左右时间。就近提供机房,让用户快速访问。这是任何软件技术都解决不了的问题。



服务器与硬件性能优化

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



硬件性能优化案例

Spark 作业过程需要传输大量数据,进行资源瓶颈分析,发现大量时间消耗在网络传输上。

解决方案:压缩数据。(压缩以及解压缩,会增加CPU的负担,得不偿失。)



优化方案:升级网卡,10G网卡代替1G网卡。



操作系统性能优化案例

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



调查发现,起因是部分 Linux 版本缺省情况下打开 transparent huge page 导致。



优化方案:关闭 transparent huge page

虚拟机性能优化





虚拟机垃圾回收的期间,全世界都停下来了。Stop-the-world



基础组件性能优化

阿里巴巴应用服务器升级项目,采用Jetty 7.1.5 代替 JBoss 4.05 GA。

性能大幅提升,阿里巴巴全站下线 1/3 应用服务器,明年不用采购新机器。



  • 架构更轻量;

  • 配置更简单;

  • 应用更无状态化,开发和维护的福音;

  • 更加安全。



阿里巴巴应用服务器升级项目:

Apache2.2 + Mod - Proxy + Jetty 7.1.5 与阿里巴巴现有架构性能对比

软件架构性能优化三板斧

  • 缓存

  • 异步

  • 集群



缓存

  • 从内存获取数据,减少响应时间。

  • 减少数据库访问,降低存储设备负载压力。

  • 缓存结果对象,而不是原始数据,减少 CPU 计算。

  • 缓存主要优化读操作。





异步

  • 即时响应,更好的用户体验。

  • 控制消费速度,合适的负载压力。

  • 异步主要优化写操作。







集群

古老谚语:如果一匹马拉不动车,无需换一匹更强的马,而是用两匹马拉车。

互联网技术的发展路径是:更多的用户访问需要消耗更多的计算机资源,单一服务器计算资源的增加是有极限的,所以需要增加更多的服务器。关键是如何利用起来这些服务器。

集群的技术目标只有一个:如何使很多台服务器对使用者而言看起来像一台服务器。



2010年京东刚火起来,第一天,服务器崩溃,网站一天不可用。刘强东发一条微博,请信息部喝茶,放了一把刀的图片。第二天,服务器照样崩溃,网站又一天不可用。刘强东再发一条微博,请信息部喝茶,送了信息部900台服务器。第三天,服务器照样崩溃,网站依然一天不可用。科学技术需要技术手段解决,刀子和服务器都不能简单的使用。



软件代码性能优化

遵循面向对象的设计原则与设计模式编程,很多时候程序性能不好不是因为性能上有什么技术挑战,仅仅就是因为代码太烂了。

  • 并发编程,多线程与锁。

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

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

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



代码优化案例

Spark 任务文件初始化调优

  • 资源分析,发现第一个 stage 时间特别长,耗时长达 14s,CPU 和网络通信有一定开销,不符合应用代码逻辑。



打开 Spark 作业 log,分析这段时间的 Spark 运行状况。

根据 log 分析结果,阅读 Spark 相关源码。

发现 Spark 在任务初始化加载应用代码的时候,每个 Executor 都加载一次应用代码,当时没太服务器最多可启动48个 Executor,每个应用代码包 17M 大小,导致加载开销巨大。

  • 优化方案: Executor 加载应用程序包启用本地文件缓存模式。[SPARK-2713]

  • 优化效果:Stage1 运行时间从14s下降到不到1s。





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

John(易筋)

关注

问渠那得清如许?为有源头活水来 2018.07.17 加入

架构师,前阿里巴巴资深无线开发,汇丰银行专家。擅长算法、数据结构、设计模式、iOS、Java、 Spring Boot、Spring Cloud、Docker

评论

发布
暂无评论
极客大学架构师训练营 性能优化 性能测试指标 性能测试 性能优化 CDN 网络 硬盘 缓存 异步 集群 第13课 听课总结