07 性能优化（一）

7.1 性能测试：系统性能的主要技术指标

性能测试

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

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

• 加载页（先文字后图片）

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

做性能优化的时候，一方面提高性能指标，另一方面要考虑到提高用户的主观感受（可以利用异步操作）。架构师训练营不介绍主观视角

性能测试指标

• 相应时间 RT, Response Time：用户感受到的时间（客户端视角）。应用系统从发出请求开始到收到最后响应数据所需要的时间。直观的反映了系统的快慢

• 并发数：系统能够同时处理请求的数目，系统的负载特性。对于网站而言，并发数即系统并发用户数，指同时提交请求的用户数目。注意与在线用户数（当前登录系统的用户数）和系统用户数（可能访问系统的总用户数）的区别。一般来说，并发数不会太大，淘宝双十一高峰并发数可能是百万级别，可能同时在线数达到亿级，用户数可能超过十亿。

• 吞吐量：单位时间内系统处理的请求数量，系统的处理能力。对于网站，请求数/秒，页面数/秒，访问人数/天，处理的业务数/小时

• TPS, Transactions Per Second 每秒事务数

• 性能计数器：描述服务器或操作系统性能的数据指标，包括 System Load、对象与线程数、内存使用、CPU 使用、磁盘与网络 I/O 等指标。

其他常用指标：

• RPS, Request Per Second：每秒请求数

• CPS, Codes Per Second：HTTP 返回码每秒

• PV, Page View：页面浏览量

• UV, Unique Vistor：独立访问者

• IP, Internet Protocal：独立 IP 数

• IOPS, Input/Output Operations Per Second 磁盘

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

吞吐量 Throughput 的讨论需要有时间单位，一般采用 Bytes/Second、Pages/Second 和 Request/Second 等单位。

• Bytes/Second 和 Pages/Second 表示的吞吐量，受网络设置、服务器架构、应用服务制约

• Request/Second 表示的吞吐量，受应用服务器和应用本身的制约

不同并发用户数场景下，即使系统具有相近的吞吐量，但是得到的系统性能瓶颈也不一样。

比如 100 个并发用户，每用户每隔 1 秒发出一个 Request 和 1000 个并发用户，每隔 10 秒发出一个 Request，两个场景有相同的吞吐量 100 Request/Second，但是两个场景所占用的资源不一样，性能拐点也肯定不一样。

性能测试方法

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

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

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

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

究竟部署多少台服务器（资源）比较合适？是架构师需要考虑的一个决策，找到性能、价格的平衡点。架构师要清醒的知道，决策的依据到底是什么，可能的代价是什么，是否能够承担这个责任……

• 空闲区间：系统并发用户数比较少，吞吐量也低，系统处于空闲状态

• 线性增长区间：系统整体负载不大，随着并发用户数增长，吞吐量也会随之线性增长

• 拐点：系统并发用户数进一步增长，系统处理能力趋于饱和，每个用户的响应时间逐渐变长；系统整体吞吐量不会随着并发用户数增长而继续线性增长。

• 过饱和区间：系统并发用户数继续增长，系统处理能力达到过饱和状态；如果继续增加并发用户数，最终所有用户的响应时间会变得无限长；系统整体吞吐量会降为零，系统处于被压垮的状态。

Performance Testing Methodology, Quest Soft, 2005

在 TPS 增加的过程中，响应时间一开始会处在较低的状态，也就是在 A 点之前。接着响应时间开始有些增加，直到业务可以承受的时间点 B，这时 TPS 仍然有增长的空间。再接着增加压力，达到 C 点时，达到最大 TPS。我们再接着增加压力，响应时间接着增加，但 TPS 会有下降（请注意，这里并不是必然的，有些系统在队列上处理得很好，会保持稳定的 TPS，然后多出来的请求都被友好拒绝）。最后，响应时间过长，达到了超时的程度。

——《02 丨性能综述：TPS 和响应时间之间是什么关系？》 性能测试实战 30 讲

通常从两个层面定义性能场景的需求指标：业务指标和技术指标。

所有的技术指标都是在有业务场景的前提下制定的，而技术指标和业务指标之间也要有详细的换算过程。

7.2 全链路压测的挑战

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

大多数情况下，全链路压测可能没有必要；除非在特别的情况下

全链路压测的挑战

• 压测相关的业务系统众多，并且牵涉到整条链路上所有的基础设施和中间件，如何确保压测流量能够通畅无阻，没有死角？

• 压测的数据怎么构造（亿万级的商品和用户），数据模型如何与真实贴近？

• 全链路压测直接在线上的真实环境进行模拟，如何保障对线上无影响？

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

数据构造

数据隔离

• 逻辑隔离：测试数据和正常数据写到一起，通过特殊的标识区分。可能污染线上数据，破坏线上数据安全

• 虚拟隔离：所有写数据的地方 mock，并不真正写进去。不会污染线上数据，但是 mock  可能干扰压测结果的准确性

• 物理隔离：所有写数据的地方对压测流量进行识别，如果是压测流量，就写到隔离位置，包括存储、缓存、搜索引擎

流量构造

天猫双十一全链路压测流量平台平稳输出 1000+w/s 的用户请求，同时保持过亿的无线用户长连接。

Master 节点作为压测管理台，负责整个平台的运转控制、命令发送、数据收集、决策等；

Slave 节点作为压测引擎，部署在全球各地的 CDN 节点上，负责具体请求发送，模拟从全球各地过来的用户请求。

全链路压测平台化

7.3 性能优化：系统性能优化的分层思想

性能优化的基本原则

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

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

性能测试的主要指标

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

• 并发数：同时处理的任务树

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

• 性能计数器：System Load，线程数，进程数，CPU、内存、磁盘、网络使用率

Spark 应用性能测试

性能优化的一般方法

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

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

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

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

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

性能优化的分层思想

• 机房与骨干网络

• 服务器与硬件

• 操作系统

• 虚拟机

• 基础组件

• 软件架构

• 软件代码

机房域骨干网络性能优化

异地多活的多机房架构

专线网络与自主 CDN 建设

服务器与硬件性能优化

使用更好的 CPU、磁盘（SSD）、内存、网卡，可能获得数量级的优化结果，远超代码和架构的优化结果

比如：升级网卡 10G 网卡代替 1G 网卡

操作系统性能优化

大量 sys 类型的 CPU 操作，消耗大量的计算资源。关闭 Linux 的 transparent huge page

虚拟机性能优化

基础组件性能优化

软件架构性能优化

• 缓存

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

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

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

• 缓存主要优化读操作

• 异步

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

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

• 异步主要优化写操作

• 集群

• 如何使用多台服务器，但是对使用者而言看起来像是一台服务器

• 互联网技术的发展路径：更多的用户访问需要消耗更多的计算资源，单一服务器计算资源增长是有极限的，所以需要更多的服务器，关键在于如何利用这些服务器。

软件代码性能优化

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

• 并发编程，多线程与锁

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

• 异步编程，生产者消费者

• 数据结构，数组、链表、hash 表、树

很多时候程序性能不好仅仅就是因为代码太烂了

Spark 任务文件初始化调优

第一个 Stage 耗时 14s，时间特别长

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

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

优化效果：Stage 1 运行时间从 14s 下降到不到 1s

7.4 操作系统：计算机如何处理成百上千的并发请求？

程序运行时架构

程序（代码）是静态的，程序（应用）运行起来以后，被称为进程。

代码从磁盘加载到内存，操作系统将可执行代码的入口交给 CPU 去执行

进程空间

• 可执行代码：

• 堆内存空间：程序运行过程中自己申请的内存

• 栈内存空间：进程自己的上下文信息

• 进程数据结构

操作系统多任务运行环境

计算机（服务器）的 CPU 核心数是有限的，但是通过进程分时执行，可以同时处理数以百计甚至数以千计的并发用户请求

进程的运行期状态

• 运行：当一个进程在 CPU 上运行时，称该进程处于运行状态，处于运行状态的进程数小于等于 CPU 的数目（核数）

• 就绪：当一个进程获得了除 CPU 以外的一切所需资源，只要得到 CPU 即可运行，该进程就处于就绪状态，也可以称之为等待运行状态

• 阻塞：也称为等待或睡眠状态，

进程 VS 线程

不同进程轮流在 CPU 上执行，每次都要进行进程间 CPU 切换，代价非常大，因此服务器应用通常是单进程多线程。

进程从操作系统获得基本的内存空间，所有的线程共享进程的内存地址空间，而每个线程样式拥有自己私有的内存地址范围，其他线程不能访问

在 Web 应用中，多个线程执行相同的代码，处理不同用户的请求（访问），每个线程有自己的运行空间（线程栈）

线程栈

void f() {  int x = g(1);  x++;   // g 函数返回，当前栈顶部为 f 函数栈桢，在当前栈桢继续执行 f 函数的代码}
int g(int x) {  return x + 1}

Java Web 应用多线程运行时视图

java org.apache.catalina.startup.Bootstrap "$@" start

线程安全

当某些代码修改内存堆（进程共享内存）里的数据的时候，如果有多个线程在同时执行，就可能会出现同时修改数据的情况，比如，两个线程同时对一个堆中的数据执行 +1 操作，最终这个数据只会被加一次，实际上线程的结果应该是依次加一，最终结果应该是 +2，这就是线程安全问题。

临界区

多个线程访问共享资源的这段代码被称为临界区，解决线程安全问题的主要方法是使用锁，将临界区的代码加锁，只有获得锁的线程才能执行临界区代码。

lock.lock();    // 线程获得锁i++;            // 临界区代码，i 位于堆中lock.unlock();  // 线程释放锁

阻塞导致高并发系统崩溃

锁（I/O）会引起线程阻塞，阻塞导致线程既不能继续执行，也不能释放资源，进而导致资源耗尽，最终引发系统崩溃。

避免阻塞引起的崩溃

• 限流：控制进入计算机的请求数，进而减少创建的线程数

• 降级：关闭部分功能程序的执行，尽早释放线程

• 反应式：一步；无临界区（Actor 模型）

7.5 锁：锁原语 CAS 与各类锁

锁原语 CAS

CAS ( V, E, N )

• V 要更新的变量

• E 预期值

• N 新值

如果 V 值等于 E 值，则将 V 的值设为 N，若 V 值和 E 值不同，什么都不做。

CAS 是一种系统原语，原语的执行必须是连续的，在执行过程中不允许中断。

Java 通过 CAS 原语在对象头中修改 Mark Word 实现加锁

Java 中的 synchronize 关键字

偏向锁、轻量级锁、重量级锁

• 偏向锁：一段同步代码一直被一个线程所访问，那么该线程就会自动获取锁，降低获取锁的代价

• 轻量级锁：当锁是偏向锁时，被另一个线程所访问，偏向锁就会升级为轻量级锁，其他县城会通过自旋的形式尝试获取锁，不会阻塞，提高性能

• 重量级锁：当锁是轻量级锁时，另一个线程虽然自旋，但自旋不会一直持续下去，当自旋到一定次数时，还没有获取到锁，就会进入阻塞，该锁膨胀为重量级锁，重量级锁会让其他申请的线程进入阻塞，性能降低。

多 CPU 情况下的锁

总线锁与缓存锁

• 总线锁：使用处理器的 LOCK# 信号，当一个处理器在内存总线上输出此信号的时候，其他处理器的请求将被阻塞，该处理器独占内存

• 缓存锁：内存区域如果被缓存在处理器的缓存行中，并且在 Lock 操作期间被锁定，那么当它执行锁操作回写到内存时，处理器不在总线上声言 LOCK# 信号，而是修改内部的内存地址，并允许它的缓存一致性机制来保证操作的原子性，因为缓存一致性机制会阻止同时修改两个以上处理器缓存的内存区域数据，当其他处理器回写已被锁定的缓存行数据时，会使缓存行无效。

公平锁与非公平锁

• 公平锁就是多个线程按照申请锁的顺序来获取锁

• 非公平锁是多个线程获取锁的顺序并不是按照申请锁的顺序，有可能后申请的线程比先申请的线程有限获取锁，可能会造成饥饿现象。

Java 通过 monitor 监视等待锁的队列实现重量级锁，按照申请顺序获得锁，公平锁；通过 CAS 获得轻量级锁，由 CPU 调度决定谁能获得锁，非公平锁。

可重入锁

可重入锁就是说某个线程已经获得某个锁，可以再次获取锁而不会出现死锁。

Java 中的偏向锁，其中记录了锁 ID

独享锁/互斥锁、共享锁、读写锁

• 独享锁/互斥锁：该锁一次只能被一个线程锁持有

• 共享锁：该锁可以被多个线程所持有，可以设置共享数目，比如 5 个线程共享一个锁，如果数字太大，则没有意义

• 读写锁：多个读线程之间并不互斥，而写线程则要求与任何线程互斥

乐观锁与悲观锁

• 悲观锁：认为对于同一个数据的并发操作，一定会发生修改的，哪怕没有修改，也会认为修改。因此对于同一个数据的并发操作，悲观锁采取加锁的形式。悲观的认为，不加锁的并发操作一定会出现问题。

• 乐观锁：认为对于同一个数据的并发操作，是不会发生修改的。在更新数据的时候，检查是否已经被修改过，如果修改过，就放弃。

悲观锁和乐观锁并不是真的锁，如果写频繁发生，那么加悲观锁；如果写比较少，那么可以乐观锁

分段锁

分段锁的设计目的是细化锁的粒度，当操作不需要更新整个数组的时候，就仅仅针对数组的一段进行加锁操作。

JDK ConcurrentHashMap 是通过分段锁的形式来实现高效并发操作的。

自旋锁

自旋锁是指尝试获取锁的线程不会立即阻塞，而是采用循环的方式去尝试获取锁，这样的好处是减少线程上下文切换的消耗，缺点是循环会消耗 CPU。

好多锁

7.6 案例：异步并发分布式编程框架 akka

Akka’s vision

• Simpler concurrency (scale up)

• Simpler distribution (scale out)

• Simpler fault-tolerance (self healing)

All of that with a single unified programming model

The Akka toolkit

• Akka runs on the JVM

• Akka can be used from Java and Scala

• Akka can be integrated with common infrastructure, e.g. Spring, etc.

Core concept: Actor

Carl Hewitt (1973): Fundamental unit of computation

• Behavior — react on messages it receives

• State — shielded from the rest of the world, no need for synchronization

• Communication — interact with other actors exclusively via messages

Receive message

one at a time

public class Hello extends UntypedActor {    @Override    public void onReceive(Object message) {        System.out.println(“Hello, world!”);    }}

Send message

Asynchronous and nonblocking

ActorRef hello = …hello.tell(“Hi”);

ActorRef path

• Local: Akka://Master/user/master

• Remote: Akka.tcp://Master@sr148:2052/user/master

The Akka ActorSystem

Create an actor system

ActorSystem system = ActorSystem.create(“hello”)

Create a top-level actor

ActorRef hello = system.actorOf(new Props(new Hello()));

Create a child actor

Actorref child = context().actorOf(new Props(new Child()));

Router for cluster

val router = system.actorOf(Props[SomeActor]									 .withRouter(RoundRobinRouter(nrOfInstances = 5)))

Embrace failure

Let it crash!

Supervision: Like in real life, parents supervise their children (manage children’s failures)

Depending on the parent’s supervisor strategy, failing actors can get stopped, restarted or resumed.

private SupervisorStrategy = new OneForOneStrategy(    10,    Duration.parse(“1.minute”),    new Function<Throwable, Directive>() {        @Override public Directive apply(Throwable t) {            if ( t instanceof ArithmeticException ) return resume();            else if (t instanceof NullPointerException) return restart();            else return escalate();        }});
@Override public SupervisorStrategy supervisionStrategy() {    return strategy;}

HakkyHour demo

The HakkyHour bar

Our drinks: Akkarita, MaiPlay, PinaScalada

Our actors: guests, waiters, head waiter, barkeepers

Our messages: Order, drink served, complaint, etc.

Our failures: Guest drunk, waiter frustrated

HakkyHour messages

Benefits of using Akka actors

• You don’t have to deal with concurrency details

• You can manage failures easily

• Distribution is just a deployment decision (not covered here)

akka {    actor {        deployment {            “/creationActor/*” {                remote = “akka.tcp://CalculatorWorkerSystem@127.0.0.1:2552”;            }        }    }}

Akka 在金融借贷领域的应用

推荐阅读：

《从零开始学大数据》24 | 从大数据性能测试工具 Dew 看如何快速开发大数据系统

《Java 并发编程实战》42 | Actor 模型：面向对象原生的并发模型

一个更完整的简单 Akka Hello World，来自《42 | Actor 模型：面向对象原生的并发模型》，专栏中还有一个更复杂的例子，用 4 个线程执行累加操作，没有锁，也没有 CAS，但是线程安全，代码就不贴了。

//该Actor当收到消息message后，//会打印Hello messagestatic class HelloActor     extends UntypedActor {  @Override  public void onReceive(Object message) {    System.out.println("Hello " + message);  }}
public static void main(String[] args) {  //创建Actor系统  ActorSystem system = ActorSystem.create("HelloSystem");  //创建HelloActor  ActorRef helloActor =     system.actorOf(Props.create(HelloActor.class));  //发送消息给HelloActor  helloActor.tell("Actor", ActorRef.noSender());}

Actor 模型和现实世界一样都是异步模型，理论上不保证消息百分百送达，也不保证消息送达的顺序和发送的顺序是一致的，甚至无法保证消息会被百分百处理。

7.7 第七周课后练习

作业一（至少完成一项）：

1. 性能压测的时候，随着并发压力的增加，系统响应时间和吞吐量如何变化，为什么？

2. 用你熟悉的编程语言写一个 Web 性能压测工具，输入参数：URL，请求总次数，并发数。输出参数：平均响应时间，95% 响应时间。用这个测试工具以 10 并发、100 次请求压测 www.baidu.com。

作业二：根据当周学习情况，完成一篇学习总结