性能思路文章收集

目录

1、性能调优攻略 转自：http://coolshell.cn/articles/7490.html

2、网站性能优化的三重境界 转自：http://www.raychase.net/311

3、Where SLOW 转自：http://huoding.com/2014/09/30/375

4、常见性能优化策略的总结 转自：https://tech.meituan.com/performance_tunning.html

5、蚂蚁金服技术专家总结：性能优化的常见招式 https://yq.aliyun.com/articles/54411

6、系统性能优化之道 http://mrchenatu.com/2017/02/21/performance-tuning/

 

 

1、性能调优攻略

关于性能优化这是一个比较大的话题，在《由12306.cn谈谈网站性能技术》中我从业务和设计上说过一些可用的技术以及那些技术的优缺点，今天，想从一些技术细节上谈谈性能优化，主要是一些代码级别的技术和方法。本文的东西是我的一些经验和知识，并不一定全对，希望大家指正和补充。

在开始这篇文章之前，大家可以移步去看一下酷壳以前发表的《代码优化概要》，这篇文章基本上告诉你——要进行优化，先得找到性能瓶颈！ 但是在讲如何定位系统性能瓶劲之前，请让我讲一下系统性能的定义和测试，因为没有这两件事，后面的定位和优化无从谈起。

一、系统性能定义

让我们先来说说如何什么是系统性能。这个定义非常关键，如果我们不清楚什么是系统性能，那么我们将无法定位之。我见过很多朋友会觉得这很容易，但是仔细一问，其实他们并没有一个比较系统的方法，所以，在这里我想告诉大家如何系统地来定位性能。 总体来说，系统性能就是两个事：

1. Throughput ，吞吐量。也就是每秒钟可以处理的请求数，任务数。
2. Latency， 系统延迟。也就是系统在处理一个请求或一个任务时的延迟。

一般来说，一个系统的性能受到这两个条件的约束，缺一不可。比如，我的系统可以顶得住一百万的并发，但是系统的延迟是2分钟以上，那么，这个一百万的负载毫无意义。系统延迟很短，但是吞吐量很低，同样没有意义。所以，一个好的系统的性能测试必然受到这两个条件的同时作用。 有经验的朋友一定知道，这两个东西的一些关系：

• Throughput越大，Latency会越差。因为请求量过大，系统太繁忙，所以响应速度自然会低。
• Latency越好，能支持的Throughput就会越高。因为Latency短说明处理速度快，于是就可以处理更多的请求。

二、系统性能测试

经过上述的说明，我们知道要测试系统的性能，需要我们收集系统的Throughput和Latency这两个值。

 

• 首先，需要定义Latency这个值，比如说，对于网站系统响应时间必需是5秒以内（对于某些实时系统可能需要定义的更短，比如5ms以内，这个更根据不同的业务来定义）

• 其次，开发性能测试工具，一个工具用来制造高强度的Throughput，另一个工具用来测量Latency。对于第一个工具，你可以参考一下“十个免费的Web压力测试工具”，关于如何测量Latency，你可以在代码中测量，但是这样会影响程序的执行，而且只能测试到程序内部的Latency，真正的Latency是整个系统都算上，包括操作系统和网络的延时，你可以使用Wireshark来抓网络包来测量。这两个工具具体怎么做，这个还请大家自己思考去了。

• 最后，开始性能测试。你需要不断地提升测试的Throughput，然后观察系统的负载情况，如果系统顶得住，那就观察Latency的值。这样，你就可以找到系统的最大负载，并且你可以知道系统的响应延时是多少。

再多说一些，

• 关于Latency，如果吞吐量很少，这个值估计会非常稳定，当吞吐量越来越大时，系统的Latency会出现非常剧烈的抖动，所以，我们在测量Latency的时候，我们需要注意到Latency的分布，也就是说，有百分之几的在我们允许的范围，有百分之几的超出了，有百分之几的完全不可接受。也许，平均下来的Latency达标了，但是其中仅有50%的达到了我们可接受的范围。那也没有意义。

• 关于性能测试，我们还需要定义一个时间段。比如：在某个吞吐量上持续15分钟。因为当负载到达的时候，系统会变得不稳定，当过了一两分钟后，系统才会稳定。另外，也有可能是，你的系统在这个负载下前几分钟还表现正常，然后就不稳定了，甚至垮了。所以，需要这么一段时间。这个值，我们叫做峰值极限。

• 性能测试还需要做Soak Test，也就是在某个吞吐量下，系统可以持续跑一周甚至更长。这个值，我们叫做系统的正常运行的负载极限。

性能测试有很多很复要的东西，比如：burst test等。 这里不能一一详述，这里只说了一些和性能调优相关的东西。总之，性能测试是一细活和累活。

三、定位性能瓶颈

有了上面的铺垫，我们就可以测试到到系统的性能了，再调优之前，我们先来说说如何找到性能的瓶颈。我见过很多朋友会觉得这很容易，但是仔细一问，其实他们并没有一个比较系统的方法。

3.1）查看操作系统负载

首先，当我们系统有问题的时候，我们不要急于去调查我们代码，这个毫无意义。我们首要需要看的是操作系统的报告。看看操作系统的CPU利用率，看看内存使用率，看看操作系统的IO，还有网络的IO，网络链接数，等等。Windows下的perfmon是一个很不错的工具，Linux下也有很多相关的命令和工具，比如：SystemTap，LatencyTOP，vmstat, sar, iostat, top, tcpdump等等 。通过观察这些数据，我们就可以知道我们的软件的性能基本上出在哪里。比如：

1）先看CPU利用率，如果CPU利用率不高，但是系统的Throughput和Latency上不去了，这说明我们的程序并没有忙于计算，而是忙于别的一些事，比如IO。（另外，CPU的利用率还要看内核态的和用户态的，内核态的一上去了，整个系统的性能就下来了。而对于多核CPU来说，CPU 0 是相当关键的，如果CPU 0的负载高，那么会影响其它核的性能，因为CPU各核间是需要有调度的，这靠CPU0完成）

2）然后，我们可以看一下IO大不大，IO和CPU一般是反着来的，CPU利用率高则IO不大，IO大则CPU就小。关于IO，我们要看三个事，一个是磁盘文件IO，一个是驱动程序的IO（如：网卡），一个是内存换页率。这三个事都会影响系统性能。

3）然后，查看一下网络带宽使用情况，在Linux下，你可以使用iftop, iptraf, ntop, tcpdump这些命令来查看。或是用Wireshark来查看。

4）如果CPU不高，IO不高，内存使用不高，网络带宽使用不高。但是系统的性能上不去。这说明你的程序有问题，比如，你的程序被阻塞了。可能是因为等那个锁，可能是因为等某个资源，或者是在切换上下文。

通过了解操作系统的性能，我们才知道性能的问题，比如：带宽不够，内存不够，TCP缓冲区不够，等等，很多时候，不需要调整程序的，只需要调整一下硬件或操作系统的配置就可以了。

3.2）使用Profiler测试

接下来，我们需要使用性能检测工具，也就是使用某个Profiler来差看一下我们程序的运行性能。如：Java的JProfiler/TPTP/CodePro Profiler，GNU的gprof，IBM的PurifyPlus，Intel的VTune，AMD的CodeAnalyst，还有Linux下的OProfile/perf，后面两个可以让你对你的代码优化到CPU的微指令级别，如果你关心CPU的L1/L2的缓存调优，那么你需要考虑一下使用VTune。 使用这些Profiler工具，可以让你程序中各个模块函数甚至指令的很多东西，如：运行的时间 ，调用的次数，CPU的利用率，等等。这些东西对我们来说非常有用。

我们重点观察运行时间最多，调用次数最多的那些函数和指令。这里注意一下，对于调用次数多但是时间很短的函数，你可能只需要轻微优化一下，你的性能就上去了（比如：某函数一秒种被调用100万次，你想想如果你让这个函数提高0.01毫秒的时间 ，这会给你带来多大的性能）

使用Profiler有个问题我们需要注意一下，因为Profiler会让你的程序运行的性能变低，像PurifyPlus这样的工具会在你的代码中插入很多代码，会导致你的程序运行效率变低，从而没发测试出在高吞吐量下的系统的性能，对此，一般有两个方法来定位系统瓶颈：

1）在你的代码中自己做统计，使用微秒级的计时器和函数调用计算器，每隔10秒把统计log到文件中。

2）分段注释你的代码块，让一些函数空转，做Hard Code的Mock，然后再测试一下系统的Throughput和Latency是否有质的变化，如果有，那么被注释的函数就是性能瓶颈，再在这个函数体内注释代码，直到找到最耗性能的语句。

最后再说一点，对于性能测试，不同的Throughput会出现不同的测试结果，不同的测试数据也会有不同的测试结果。所以，用于性能测试的数据非常重要，性能测试中，我们需要观测试不同Throughput的结果。

四、常见的系统瓶颈

下面这些东西是我所经历过的一些问题，也许并不全，也许并不对，大家可以补充指正，我纯属抛砖引玉。关于系统架构方面的性能调优，大家可移步看一下《由12306.cn谈谈网站性能技术》，关于Web方面的一些性能调优的东西，大家可以看看《Web开发中需要了解的东西》一文中的性能一章。我在这里就不再说设计和架构上的东西了。

一般来说，性能优化也就是下面的几个策略：

• 用空间换时间。各种cache如CPU L1/L2/RAM到硬盘，都是用空间来换时间的策略。这样策略基本上是把计算的过程一步一步的保存或缓存下来，这样就不用每次用的时候都要再计算一遍，比如数据缓冲，CDN，等。这样的策略还表现为冗余数据，比如数据镜象，负载均衡什么的。

• 用时间换空间。有时候，少量的空间可能性能会更好，比如网络传输，如果有一些压缩数据的算法（如前些天说的“Huffman 编码压缩算法” 和 “rsync 的核心算法”），这样的算法其实很耗时，但是因为瓶颈在网络传输，所以用时间来换空间反而能省时间。

• 简化代码。最高效的程序就是不执行任何代码的程序，所以，代码越少性能就越高。关于代码级优化的技术大学里的教科书有很多示例了。如：减少循环的层数，减少递归，在循环中少声明变量，少做分配和释放内存的操作，尽量把循环体内的表达式抽到循环外，条件表达的中的多个条件判断的次序，尽量在程序启动时把一些东西准备好，注意函数调用的开销（栈上开销），注意面向对象语言中临时对象的开销，小心使用异常（不要用异常来检查一些可接受可忽略并经常发生的错误），…… 等等，等等，这连东西需要我们非常了解编程语言和常用的库。

• 并行处理。如果CPU只有一个核，你要玩多进程，多线程，对于计算密集型的软件会反而更慢（因为操作系统调度和切换开销很大），CPU的核多了才能真正体现出多进程多线程的优势。并行处理需要我们的程序有Scalability，不能水平或垂直扩展的程序无法进行并行处理。从架构上来说，这表再为——是否可以做到不改代码只是加加机器就可以完成性能提升？

总之，根据2：8原则来说，20%的代码耗了你80%的性能，找到那20%的代码，你就可以优化那80%的性能。 下面的一些东西都是我的一些经验，我只例举了一些最有价值的性能调优的的方法，供你参考，也欢迎补充。

4.1）算法调优。算法非常重要，好的算法会有更好的性能。举几个我经历过的项目的例子，大家可以感觉一下。

• 一个是过滤算法，系统需要对收到的请求做过滤，我们把可以被filter in/out的东西配置在了一个文件中，原有的过滤算法是遍历过滤配置，后来，我们找到了一种方法可以对这个过滤配置进行排序，这样就可以用二分折半的方法来过滤，系统性能增加了50%。

• 一个是哈希算法。计算哈希算法的函数并不高效，一方面是计算太费时，另一方面是碰撞太高，碰撞高了就跟单向链表一个性能（可参看Hash Collision DoS 问题）。我们知道，算法都是和需要处理的数据很有关系的，就算是被大家所嘲笑的“冒泡排序”在某些情况下（大多数数据是排好序的）其效率会高于所有的排序算法。哈希算法也一样，广为人知的哈希算法都是用英文字典做测试，但是我们的业务在数据有其特殊性，所以，对于还需要根据自己的数据来挑选适合的哈希算法。对于我以前的一个项目，公司内某牛人给我发来了一个哈希算法，结果让我们的系统性能上升了150%。（关于各种哈希算法，你一定要看看StackExchange上的这篇关于各种hash算法的文章 ）

• 分而治之和预处理。以前有一个程序为了生成月报表，每次都需要计算很长的时间，有时候需要花将近一整天的时间。于是我们把我们找到了一种方法可以把这个算法发成增量式的，也就是说我每天都把当天的数据计算好了后和前一天的报表合并，这样可以大大的节省计算时间，每天的数据计算量只需要20分钟，但是如果我要算整个月的，系统则需要10个小时以上（SQL语句在大数据量面前性能成级数性下降）。这种分而治之的思路在大数据面前对性能有很帮助，就像merge排序一样。SQL语句和数据库的性能优化也是这一策略，如：使用嵌套式的Select而不是笛卡尔积的Select，使用视图，等等。

4.2）代码调优。从我的经验上来说，代码上的调优有下面这几点：

• 字符串操作。这是最费系统性能的事了，无论是strcpy, strcat还是strlen，最需要注意的是字符串子串匹配。所以，能用整型最好用整型。举几个例子，第一个例子是N年前做银行的时候，我的同事喜欢把日期存成字符串（如：2012-05-29 08:30:02），我勒个去，一个select  where between语句相当耗时。另一个例子是，我以前有个同事把一些状态码用字符串来处理，他的理由是，这样可以在界面上直接显示，后来性能调优的时候，我把这些状态码全改成整型，然后用位操作查状态，因为有一个每秒钟被调用了150K次的函数里面有三处需要检查状态，经过改善以后，整个系统的性能上升了30%左右。还有一个例子是，我以前从事的某个产品编程规范中有一条是要在每个函数中把函数名定义出来，如：const char fname[]=”functionName()”, 这是为了好打日志，但是为什么不声明成 static类型的呢？

• 多线程调优。有人说，thread is evil，这个对于系统性能在某些时候是个问题。因为多线程瓶颈就在于互斥和同步的锁上，以及线程上下文切换的成本，怎么样的少用锁或不用锁是根本（比如：多版本并发控制(MVCC)在分布式系统中的应用 中说的乐观锁可以解决性能问题），此外，还有读写锁也可以解决大多数是读操作的并发的性能问题。这里多说一点在C++中，我们可能会使用线程安全的智能指针AutoPtr或是别的一些容器，只要是线程安全的，其不管三七二十一都要上锁，上锁是个成本很高的操作，使用AutoPtr会让我们的系统性能下降得很快，如果你可以保证不会有线程并发问题，那么你应该不要用AutoPtr。我记得我上次我们同事去掉智能指针的引用计数，让系统性能提升了50%以上。对于Java对象的引用计数，如果我猜的没错的话，到处都是锁，所以，Java的性能问题一直是个问题。另外，线程不是越多越好，线程间的调度和上下文切换也是很夸张的事，尽可能的在一个线程里干，尽可能的不要同步线程。这会让你有很多的性能。

• 内存分配。不要小看程序的内存分配。malloc/realloc/calloc这样的系统调非常耗时，尤其是当内存出现碎片的时候。我以前的公司出过这样一个问题——在用户的站点上，我们的程序有一天不响应了，用GDB跟进去一看，系统hang在了malloc操作上，20秒都没有返回，重启一些系统就好了。这就是内存碎片的问题。这就是为什么很多人抱怨STL有严重的内存碎片的问题，因为太多的小内存的分配释放了。有很多人会以为用内存池可以解决这个问题，但是实际上他们只是重新发明了Runtime-C或操作系统的内存管理机制，完全于事无补。当然解决内存碎片的问题还是通过内存池，具体来说是一系列不同尺寸的内存池（这个留给大家自己去思考）。当然，少进行动态内存分配是最好的。说到内存池就需要说一下池化技术。比如线程池，连接池等。池化技术对于一些短作业来说（如http服务） 相当相当的有效。这项技术可以减少链接建立，线程创建的开销，从而提高性能。

• 异步操作。我们知道Unix下的文件操作是有block和non-block的方式的，像有些系统调用也是block式的，如：Socket下的select，Windows下的WaitforObject之类的，如果我们的程序是同步操作，那么会非常影响性能，我们可以改成异步的，但是改成异步的方式会让你的程序变复杂。异步方式一般要通过队列，要注间队列的性能问题，另外，异步下的状态通知通常是个问题，比如消息事件通知方式，有callback方式，等，这些方式同样可能会影响你的性能。但是通常来说，异步操作会让性能的吞吐率有很大提升（Throughput），但是会牺牲系统的响应时间（latency）。这需要业务上支持。

• 语言和代码库。我们要熟悉语言以及所使用的函数库或类库的性能。比如：STL中的很多容器分配了内存后，那怕你删除元素，内存也不会回收，其会造成内存泄露的假像，并可能造成内存碎片问题。再如，STL某些容器的size()==0  和 empty()是不一样的，因为，size()是O(n)复杂度，empty()是O(1)的复杂度，这个要小心。Java中的JVM调优需要使用的这些参数：-Xms -Xmx -Xmn -XX:SurvivorRatio -XX:MaxTenuringThreshold，还需要注意JVM的GC，GC的霸气大家都知道，尤其是full GC（还整理内存碎片），他就像“恐龙特级克赛号”一样，他运行的时候，整个世界的时间都停止了。

4.3）网络调优

关于网络调优，尤其是TCP Tuning（你可以以这两个关键词在网上找到很多文章），这里面有很多很多东西可以说。看看Linux下TCP/IP的那么多参数就知道了（顺便说一下，你也许不喜欢Linux，但是你不能否认Linux给我们了很多可以进行内核调优的权力）。强烈建议大家看看《TCP/IP 详解 卷1:协议》这本书。我在这里只讲一些概念上的东西。

A） TCP调优

我们知道TCP链接是有很多开销的，一个是会占用文件描述符，另一个是会开缓存，一般来说一个系统可以支持的TCP链接数是有限的，我们需要清楚地认识到TCP链接对系统的开销是很大的。正是因为TCP是耗资源的，所以，很多攻击都是让你系统上出现大量的TCP链接，把你的系统资源耗尽。比如著名的SYNC Flood攻击。

所以，我们要注意配置KeepAlive参数，这个参数的意思是定义一个时间，如果链接上没有数据传输，系统会在这个时间发一个包，如果没有收到回应，那么TCP就认为链接断了，然后就会把链接关闭，这样可以回收系统资源开销。（注：HTTP层上也有KeepAlive参数）对于像HTTP这样的短链接，设置一个1-2分钟的keepalive非常重要。这可以在一定程度上防止DoS攻击。有下面几个参数（下面这些参数的值仅供参考）：

net.ipv4.tcp_keepalive_probes = 5
net.ipv4.tcp_keepalive_intvl = 20
net.ipv4.tcp_fin_timeout = 30

对于TCP的TIME_WAIT这个状态，主动关闭的一方进入TIME_WAIT状态，TIME_WAIT状态将持续2个MSL(Max Segment Lifetime)，默认为4分钟，TIME_WAIT状态下的资源不能回收。有大量的TIME_WAIT链接的情况一般是在HTTP服务器上。对此，有两个参数需要注意，

net.ipv4.tcp_tw_reuse=1
net.ipv4.tcp_tw_recycle=1

前者表示重用TIME_WAIT，后者表示回收TIME_WAIT的资源。

TCP还有一个重要的概念叫RWIN（TCP Receive Window Size），这个东西的意思是，我一个TCP链接在没有向Sender发出ack时可以接收到的最大的数据包。为什么这个很重要？因为如果Sender没有收到Receiver发过来ack，Sender就会停止发送数据并会等一段时间，如果超时，那么就会重传。这就是为什么TCP链接是可靠链接的原因。重传还不是最严重的，如果有丢包发生的话，TCP的带宽使用率会马上受到影响（会盲目减半），再丢包，再减半，然后如果不丢包了，就逐步恢复。相关参数如下：

net.core.wmem_default = 8388608
net.core.rmem_default = 8388608
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

一般来说，理论上的RWIN应该设置成：吞吐量  * 回路时间。Sender端的buffer应该和RWIN有一样的大小，因为Sender端发送完数据后要等Receiver端确认，如果网络延时很大，buffer过小了，确认的次数就会多，于是性能就不高，对网络的利用率也就不高了。也就是说，对于延迟大的网络，我们需要大的buffer，这样可以少一点ack，多一些数据，对于响应快一点的网络，可以少一些buffer。因为，如果有丢包（没有收到ack），buffer过大可能会有问题，因为这会让TCP重传所有的数据，反而影响网络性能。（当然，网络差的情况下，就别玩什么高性能了） 所以，高性能的网络重要的是要让网络丢包率非常非常地小（基本上是用在LAN里），如果网络基本是可信的，这样用大一点的buffer会有更好的网络传输性能（来来回回太多太影响性能了）。

另外，我们想一想，如果网络质量非常好，基本不丢包，而业务上我们不怕偶尔丢几个包，如果是这样的话，那么，我们为什么不用速度更快的UDP呢？你想过这个问题了吗？

B）UDP调优

说到UDP的调优，有一些事我想重点说一样，那就是MTU——最大传输单元（其实这对TCP也一样，因为这是链路层上的东西）。所谓最大传输单元，你可以想像成是公路上的公交车，假设一个公交车可以最多坐70人，带宽就像是公路的车道数一样，如果一条路上最多可以容下100辆公交车，那意味着我最多可以运送7000人，但是如果公交车坐不满，比如平均每辆车只有20人，那么我只运送了2000人，于是我公路资源（带宽资源）就被浪费了。 所以，我们对于一个UDP的包，我们要尽量地让他大到MTU的最大尺寸再往网络上传，这样可以最大化带宽利用率。对于这个MTU，以太网是1500字节，光纤是4352字节，802.11无线网是7981。但是，当我们用TCP/UDP发包的时候，我们的有效负载Payload要低于这个值，因为IP协议会加上20个字节，UDP会加上8个字节（TCP加的更多），所以，一般来说，你的一个UDP包的最大应该是1500-8-20=1472，这是你的数据的大小。当然，如果你用光纤的话， 这个值就可以更大一些。（顺便说一下，对于某些NB的千光以态网网卡来说，在网卡上，网卡硬件如果发现你的包的大小超过了MTU，其会帮你做fragment，到了目标端又会帮你做重组，这就不需要你在程序中处理了）

再多说一下，使用Socket编程的时候，你可以使用setsockopt() 设置 SO_SNDBUF/SO_RCVBUF 的大小，TTL和KeepAlive这些关键的设置，当然，还有很多，具体你可以查看一下Socket的手册。

最后说一点，UDP还有一个最大的好处是multi-cast多播，这个技术对于你需要在内网里通知多台结点时非常方便和高效。而且，多播这种技术对于机会的水平扩展（需要增加机器来侦听多播信息）也很有利。

C）网卡调优

对于网卡，我们也是可以调优的，这对于千兆以及网网卡非常必要，在Linux下，我们可以用ifconfig查看网上的统计信息，如果我们看到overrun上有数据，我们就可能需要调整一下txqueuelen的尺寸（一般默认为1000），我们可以调大一些，如：ifconfig eth0 txqueuelen 5000。Linux下还有一个命令叫：ethtool可以用于设置网卡的缓冲区大小。在Windows下，我们可以在网卡适配器中的高级选项卡中调整相关的参数（如：Receive Buffers, Transmit Buffer等，不同的网卡有不同的参数）。把Buffer调大对于需要大数据量的网络传输非常有效。

D）其它网络性能

关于多路复用技术，也就是用一个线程来管理所有的TCP链接，有三个系统调用要重点注意：一个是select，这个系统调用只支持上限1024个链接，第二个是poll，其可以突破1024的限制，但是select和poll本质上是使用的轮询机制，轮询机制在链接多的时候性能很差，因主是O(n)的算法，所以，epoll出现了，epoll是操作系统内核支持的，仅当在链接活跃时，操作系统才会callback，这是由操作系统通知触发的，但其只有Linux Kernel 2.6以后才支持（准确说是2.5.44中引入的），当然，如果所有的链接都是活跃的，过多的使用epoll_ctl可能会比轮询的方式还影响性能，不过影响的不大。

另外，关于一些和DNS Lookup的系统调用要小心，比如：gethostbyaddr/gethostbyname，这个函数可能会相当的费时，因为其要到网络上去找域名，因为DNS的递归查询，会导致严重超时，而又不能通过设置什么参数来设置time out，对此你可以通过配置hosts文件来加快速度，或是自己在内存中管理对应表，在程序启动时查好，而不要在运行时每次都查。另外，在多线程下面，gethostbyname会一个更严重的问题，就是如果有一个线程的gethostbyname发生阻塞，其它线程都会在gethostbyname处发生阻塞，这个比较变态，要小心。（你可以试试GNU的gethostbyname_r()，这个的性能要好一些） 这种到网上找信息的东西很多，比如，如果你的Linux使用了NIS，或是NFS，某些用户或文件相关的系统调用就很慢，所以要小心。

4.4）系统调优

A）I/O模型

前面说到过select/poll/epoll这三个系统调用，我们都知道，Unix/Linux下把所有的设备都当成文件来进行I/O，所以，那三个操作更应该算是I/O相关的系统调用。说到  I/O模型，这对于我们的I/O性能相当重要，我们知道，Unix/Linux经典的I/O方式是（关于Linux下的I/O模型，大家可以读一下这篇文章《使用异步I/O大大提高性能》）：

第一种，同步阻塞式I/O，这个不说了。

第二种，同步无阻塞方式。其通过fctnl设置 O_NONBLOCK 来完成。

第三种，对于select/poll/epoll这三个是I/O不阻塞，但是在事件上阻塞，算是：I/O异步，事件同步的调用。

第四种，AIO方式。这种I/O 模型是一种处理与 I/O 并行的模型。I/O请求会立即返回，说明请求已经成功发起了。在后台完成I/O操作时，向应用程序发起通知，通知有两种方式：一种是产生一个信号，另一种是执行一个基于线程的回调函数来完成这次 I/O 处理过程。

第四种因为没有任何的阻塞，无论是I/O上，还是事件通知上，所以，其可以让你充分地利用CPU，比起第二种同步无阻塞好处就是，第二种要你一遍一遍地去轮询。Nginx之所所以高效，是其使用了epoll和AIO的方式来进行I/O的。

再说一下Windows下的I/O模型，

a）一个是WriteFile系统调用，这个系统调用可以是同步阻塞的，也可以是同步无阻塞的，关于看文件是不是以Overlapped打开的。关于同步无阻塞，需要设置其最后一个参数Overlapped，微软叫Overlapped I/O，你需要WaitForSingleObject才能知道有没有写完成。这个系统调用的性能可想而知。

b）另一个叫WriteFileEx的系统调用，其可以实现异步I/O，并可以让你传入一个callback函数，等I/O结束后回调之， 但是这个回调的过程Windows是把callback函数放到了APC（Asynchronous Procedure Calls）的队列中，然后，只用当应用程序当前线程成为可被通知状态（Alterable）时，才会被回调。只有当你的线程使用了这几个函数时WaitForSingleObjectEx, WaitForMultipleObjectsEx, MsgWaitForMultipleObjectsEx, SignalObjectAndWait 和 SleepEx，线程才会成为Alterable状态。可见，这个模型，还是有wait，所以性能也不高。

c）然后是IOCP – IO Completion Port，IOCP会把I/O的结果放在一个队列中，但是，侦听这个队列的不是主线程，而是专门来干这个事的一个或多个线程去干（老的平台要你自己创建线程，新的平台是你可以创建一个线程池）。IOCP是一个线程池模型。这个和Linux下的AIO模型比较相似，但是实现方式和使用方式完全不一样。

当然，真正提高I/O性能方式是把和外设的I/O的次数降到最低，最好没有，所以，对于读来说，内存cache通常可以从质上提升性能，因为内存比外设快太多了。对于写来说，cache住要写的数据，少写几次，但是cache带来的问题就是实时性的问题，也就是latency会变大，我们需要在写的次数上和相应上做权衡。

B）多核CPU调优

关于CPU的多核技术，我们知道，CPU0是很关键的，如果0号CPU被用得过狠的话，别的CPU性能也会下降，因为CPU0是有调整功能的，所以，我们不能任由操作系统负载均衡，因为我们自己更了解自己的程序，所以，我们可以手动地为其分配CPU核，而不会过多地占用CPU0，或是让我们关键进程和一堆别的进程挤在一起。

• 对于Windows来说，我们可以通过“任务管理器”中的“进程”而中右键菜单中的“设置相关性……”（Set Affinity…）来设置并限制这个进程能被运行在哪些核上。

• 对于Linux来说，可以使用taskset命令来设置（你可以通过安装schedutils来安装这个命令：apt-get install schedutils）

多核CPU还有一个技术叫NUMA技术（Non-Uniform Memory Access）。传统的多核运算是使用SMP(Symmetric Multi-Processor )模式，多个处理器共享一个集中的存储器和I/O总线。于是就会出现一致存储器访问的问题，一致性通常意味着性能问题。NUMA模式下，处理器被划分成多个node， 每个node有自己的本地存储器空间。关于NUMA的一些技术细节，你可以查看一下这篇文章《Linux 的 NUMA 技术》，在Linux下，对NUMA调优的命令是：numactl 。如下面的命令：（指定命令“myprogram arg1 arg2”运行在node 0 上，其内存分配在node 0 和 1上）

numactl --cpubind=0 --membind=0,1 myprogram arg1 arg2

当然，上面这个命令并不好，因为内存跨越了两个node，这非常不好。最好的方式是只让程序访问和自己运行一样的node，如：

$ numactl --membind 1 --cpunodebind 1 --localalloc myapplication

C）文件系统调优

关于文件系统，因为文件系统也是有cache的，所以，为了让文件系统有最大的性能。首要的事情就是分配足够大的内存，这个非常关键，在Linux下可以使用free命令来查看 free/used/buffers/cached，理想来说，buffers和cached应该有40%左右。然后是一个快速的硬盘控制器，SCSI会好很多。最快的是Intel SSD 固态硬盘，速度超快，但是写次数有限。

接下来，我们就可以调优文件系统配置了，对于Linux的Ext3/4来说，几乎在所有情况下都有所帮助的一个参数是关闭文件系统访问时间，在/etc/fstab下看看你的文件系统 有没有noatime参数（一般来说应该有），还有一个是dealloc，它可以让系统在最后时刻决定写入文件发生时使用哪个块，可优化这个写入程序。还要注间一下三种日志模式：data=journal、data=ordered和data=writeback。默认设置data=ordered提供性能和防护之间的最佳平衡。

当然，对于这些来说，ext4的默认设置基本上是最佳优化了。

这里介绍一个Linux下的查看I/O的命令—— iotop，可以让你看到各进程的磁盘读写的负载情况。

其它还有一些关于NFS、XFS的调优，大家可以上google搜索一些相关优化的文章看看。关于各文件系统，大家可以看一下这篇文章——《Linux日志文件系统及性能分析》

4.5）数据库调优

数据库调优并不是我的强项，我就仅用我非常有限的知识说上一些吧。注意，下面的这些东西并不一定正确，因为在不同的业务场景，不同的数据库设计下可能会得到完全相反的结论，所以，我仅在这里做一些一般性的说明，具体问题还要具体分析。

A）数据库引擎调优

我对数据库引擎不是熟，但是有几个事情我觉得是一定要去了解的。

• 数据库的锁的方式。这个非常非常地重要。并发情况下，锁是非常非常影响性能的。各种隔离级别，行锁，表锁，页锁，读写锁，事务锁，以及各种写优先还是读优先机制。性能最高的是不要锁，所以，分库分表，冗余数据，减少一致性事务处理，可以有效地提高性能。NoSQL就是牺牲了一致性和事务处理，并冗余数据，从而达到了分布式和高性能。
• 数据库的存储机制。不但要搞清楚各种类型字段是怎么存储的，更重要的是数据库的数据存储方式，是怎么分区的，是怎么管理的，比如Oracle的数据文件，表空间，段，等等。了解清楚这个机制可以减轻很多的I/O负载。比如：MySQL下使用show engines;可以看到各种存储引擎的支持。不同的存储引擎有不同的侧重点，针对不同的业务或数据库设计会让你有不同的性能。
• 数据库的分布式策略。最简单的就是复制或镜像，需要了解分布式的一致性算法，或是主主同步，主从同步。通过了解这种技术的机理可以做到数据库级别的水平扩展。

B）SQL语句优化

关于SQL语句的优化，首先也是要使用工具，比如：MySQL SQL Query Analyzer，Oracle SQL Performance Analyzer，或是微软SQL Query Analyzer，基本上来说，所有的RMDB都会有这样的工具，来让你查看你的应用中的SQL的性能问题。 还可以使用explain来看看SQL语句最终Execution Plan会是什么样的。

还有一点很重要，数据库的各种操作需要大量的内存，所以服务器的内存要够，优其应对那些多表查询的SQL语句，那是相当的耗内存。

下面我根据我有限的数据库SQL的知识说几个会有性能问题的SQL：

• 全表检索。比如：select * from user where lastname = “xxxx”，这样的SQL语句基本上是全表查找，线性复杂度O(n)，记录数越多，性能也越差（如：100条记录的查找要50ms，一百万条记录需要5分钟）。对于这种情况，我们可以有两种方法提高性能：一种方法是分表，把记录数降下来，另一种方法是建索引（为lastname建索引）。索引就像是key-value的数据结构一样，key就是where后面的字段，value就是物理行号，对索引的搜索复杂度是基本上是O(log(n)) ——用B-Tree实现索引（如：100条记录的查找要50ms，一百万条记录需要100ms）。

• 索引。对于索引字段，最好不要在字段上做计算、类型转换、函数、空值判断、字段连接操作，这些操作都会破坏索引原本的性能。当然，索引一般都出现在Where或是Order by字句中，所以对Where和Order by子句中的子段最好不要进行计算操作，或是加上什么NOT之类的，或是使用什么函数。

• 多表查询。关系型数据库最多的操作就是多表查询，多表查询主要有三个关键字，EXISTS，IN和JOIN（关于各种join，可以参看图解SQL的Join一文）。基本来说，现代的数据引擎对SQL语句优化得都挺好的，JOIN和IN/EXISTS在结果上有些不同，但性能基本上都差不多。有人说，EXISTS的性能要好于IN，IN的性能要好于JOIN，我各人觉得，这个还要看你的数据、schema和SQL语句的复杂度，对于一般的简单的情况来说，都差不多，所以千万不要使用过多的嵌套，千万不要让你的SQL太复杂，宁可使用几个简单的SQL也不要使用一个巨大无比的嵌套N级的SQL。还有人说，如果两个表的数据量差不多，Exists的性能可能会高于In，In可能会高于Join，如果这两个表一大一小，那么子查询中，Exists用大表，In则用小表。这个，我没有验证过，放在这里让大家讨论吧。另，有一篇关于SQL Server的文章大家可以看看《IN vs JOIN vs EXISTS》

• JOIN操作。有人说，Join表的顺序会影响性能，只要Join的结果集是一样，性能和join的次序无关。因为后台的数据库引擎会帮我们优化的。Join有三种实现算法，嵌套循环，排序归并，和Hash式的Join。（MySQL只支持第一种）

• 嵌套循环，就好像是我们常见的多重嵌套循环。注意，前面的索引说过，数据库的索引查找算法用的是B-Tree，这是O(log(n))的算法，所以，整个算法复法度应该是O(log(n)) * O(log(m)) 这样的。
• Hash式的Join，主要解决嵌套循环的O(log(n))的复杂，使用一个临时的hash表来标记。
• 排序归并，意思是两个表按照查询字段排好序，然后再合并。当然，索引字段一般是排好序的。

还是那句话，具体要看什么样的数据，什么样的SQL语句，你才知道用哪种方法是最好的。

• 部分结果集。我们知道MySQL里的Limit关键字，Oracle里的rownum，SQL Server里的Top都是在限制前几条的返回结果。这给了我们数据库引擎很多可以调优的空间。一般来说，返回top n的记录数据需要我们使用order by，注意在这里我们需要为order by的字段建立索引。有了被建索引的order by后，会让我们的select语句的性能不会被记录数的所影响。使用这个技术，一般来说我们前台会以分页方式来显现数据，Mysql用的是OFFSET，SQL Server用的是FETCH NEXT，这种Fetch的方式其实并不好是线性复杂度，所以，如果我们能够知道order by字段的第二页的起始值，我们就可以在where语句里直接使用>=的表达式来select，这种技术叫seek，而不是fetch，seek的性能比fetch要高很多。

• 字符串。正如我前面所说的，字符串操作对性能上有非常大的恶梦，所以，能用数据的情况就用数字，比如：时间，工号，等。

• 全文检索。千万不要用Like之类的东西来做全文检索，如果要玩全文检索，可以尝试使用Sphinx。

• 其它。
  • 不要select *，而是明确指出各个字段，如果有多个表，一定要在字段名前加上表名，不要让引擎去算。
  • 不要用Having，因为其要遍历所有的记录。性能差得不能再差。
  • 尽可能地使用UNION ALL  取代  UNION。
  • 索引过多，insert和delete就会越慢。而update如果update多数索引，也会慢，但是如果只update一个，则只会影响一个索引表。
  • 等等。

关于SQL语句的优化，网上有很多文章， 不同的数据库引擎有不同的优化技巧，正如本站以前转发的《MySQL性能优化的最佳20+条经验》

先写这么多吧，欢迎大家指正补充。

注：这篇文章的确是个大杂烩。其实其中的说到的很多技术在网上都有很多很多的技术文章，google一下就能找到一堆有很多细节的文章，所以我也就不写了。这篇性能调优的文章写作的动机是之前看到 @淘宝褚霸 强推的highscalability.com上的这篇文章：Big List Of 20 Common Bottlenecks，觉得这篇文章泛泛而谈，觉得自己能写得比它好，所以就产生了动机。

 

---

 2、网站性能优化的三重境界

这篇文章是关于网站性能优化体验的，性能优化是一个复杂的话题，牵涉的东西非常多，我只是按照我的理解列出了性能优化整个过程中需要考虑的种种因素。点到为止，包含的内容以浅显的介绍为主，如果你有见解能告知我那再好不过了。无论如何，希望阅读它的你有所收获。

 

我眼中的网站性能问题都反映了一个网站的“Availability”（中文叫做可用性，但是这个翻译也不足够达意），以往我的认识是，这个网站如果全部或者部分不可用，那是功能问题，但是如果响应慢、负载差，这才是性能问题；可是后来我逐渐意识到，性能问题涵盖的范围更广，我还没法给出一个准确定义，但是许多非业务逻辑错误引起的网站问题都可能可以算做性能问题，比如可扩展性差，比如单点故障问题。

 

在网站性能优化的最初阶段，也就是所谓的“第一重境界”，做局部的定位、分析和修正，考虑的仅仅是“优化”，这也是初涉性能优化问题的大多数人的认识。在问题发生以后，发现它和业务逻辑没有太大关系，就开始尝试寻找问题产生的原因并加以解决。

 

无论是网站无响应还是响应缓慢，还是响应曲线异常波动，比如，可以围绕CPU的使用问自己这样几个问题：

 

• 从CPU使用看系统是否繁忙？
• 如果系统繁忙，系统在做什么，为什么？（典型问题：HashMap不安全并发导致的死循环）
• 如果系统空闲，那么瓶颈在哪里？（典型问题：IO无响应）
• 如果响应波动，是否存在周期，周期是什么？（典型问题：连接迅速占满，每一周期批量超时断开一批）
• 如果响应波动，性能到波谷时系统在做什么？
• 是否有背景CPU使用？（即无压力下观察CPU的使用情况。典型问题：正执行的定时任务占用过多系统资源）

在这些问题中，情况虽然千变万化，简单地说，CPU的使用是核心，CPU使用率高，说明系统资源被充分利用，可能系统在实实在在地做事，反之，需要寻找其他瓶颈。通过结合进程、线程的快照，来初步确定问题的范围。CPU使用率低的情况居多而且容易定位，只需要寻找其他的系统瓶颈；CPU占用率偏高的问题往往比较不容易定位，虽然也有一些办法。关于具体性能问题的定位技术，这里不着过多笔墨，后续有机会详细介绍。

 

对于一个刚开始做性能优化的网站系统，下面的事情不妨都做一做，会有立竿见影的效果：

 

• 对于使用的成熟的技术，技术社区、官方文档，往往会给出这种技术的白皮书或者优化指导，请参考。比如 Struts2的官方性能调优指南、Java6性能优化白皮书。
• 平台和虚拟机调优。对于使用平台和虚拟机的项目来说，这是必须要做的，一个JVM的参数可以对系统有显著的影响。比如Linux下连接管理的参数，JVM关于堆大小分布的参数等等。
• 前端审查。这里的审查指的是通过Page speed、YSlow等工具，以及一些业界通用的法则和经验（比如yahoo的若干条前端性能优化法则）来评估现有页面的问题。

如果你需要系统的指导，不妨参考这张图（点此下载大图和mmap文件：Site_Performance_Practice_Road_Map）：

 

从使用的工具上说，性能问题的定位很大程度上是面向操作系统、虚拟机系统的问题定位。从问题定位的时机上说，又可以分为：

 

• 截取型：截取系统某个层面的一个快照加以分析。比如一些堆栈切面和分析的工具，jstack、jmap、kill -3、MAT、Heap Analyser等。
• 监控型：监视系统变化，甚至数据流向。比如JProfiler、JConsole、JStat、BTrace等等。
• 验尸型：系统已经宕机了，但是留下了一些“罪证”，在事后来分析它们。最有名的就是JVM挂掉之后可能会留下的hs_err_pid.log，或者是生成的crash dump文件。

了解到这里，再给出这样几个常见问题定位的场景：

 

第一类：请求无响应，浏览器始终处于等待状态。

定位方法：kill -3或者jstack先分析线程堆栈，找到当前block的线程。

常见于：外部接口调用无返回或者网络IO阻塞无响应；死锁；死循环；……。

 

第二类：宕机，进程挂掉。

定位方法（这一类问题普遍比较难定位）：

    （1）寻找hs_err_pidxxx.log这样的JVM日志

    （2）使用JVM参数在JVM crash时写入到dump文件中

    （3）catalina.out中寻找最后的日志

    （4）宕机前环境数据采集

常见于：JDK bug（数次遇到过JIT引起的这一类问题）；调用dll的问题；……

 

第三类：请求响应时间长。

定位方法：kill -3或者jstack先分析线程堆栈，看线程大都停留在什么操作上面，再细化分析。

常见于： 内存不足，可见到连续的Full GC；网络拥塞；LoadRunner等压力客户端瓶颈；数据库瓶颈，可进一步分析DB快照；……

 

第四类：TPS低；TPS逐渐降低；TPS振荡幅度过大。

定位方法（这一类问题最常见，定位的方法也最复杂）：

首先观察在压力增大时，CPU使用率能否上去，如果不能上去，寻找其他瓶颈：网络/内存/磁盘/……；CPU

使用率上去了，观察在无压力时，是否有背景CPU使用（例如有后台定时任务线程消耗了大量CPU资源），如果没有，那可以尝试JProfiler等工具结合线程分析、业务分析，寻找热点。

常见于：其他业务线程干扰；内存泄露；连接句柄用完；缓存命中率低下……

 

好，暂时说到这里，下面来看第二重境界。达到这重境界意味着已经能够跳出“事后优化”的局限了，在设计和编码的过程当中，能够正式和全面地考虑性能的因素，比如：

 

• 减少使用时间敏感的容器管理，而使用容量或数量敏感的容器管理。比如我往一个缓冲里面存放若干数据，一种设计是每10分钟flush入库一次，还有一种设计是数据到达10M大小的时候flush入库一次，通常情况下，你觉得哪个方案更可靠？
• 线程的统一管理使用。我的经验是，10次对线程创建或者线程池的使用，往往就有5次是会出问题的。
• 避免使用同步Ajax。同步Ajax会造成浏览器假死，直至响应返回。
• 分析对同步、锁的使用。即便在一些有名的开源库中，我们也不止一次发现过不合理的同步设计，N多数据，单一的全局同步块（这是一种性能设计层面上的“中心化”），结果它就成为了瓶颈，改动还不容易下手，很麻烦。

对于不成熟的团队，建议能安排有经验的程序员把关设计文档和编码中的性能问题，把常见的问题列出来参考学习。

 

达到第二重境界还有一个明显的特征，就是在软件流程的前中期就开始做性能目标的论证和性能问题的验证：

 

• 性能切面分析。这指的是在系统设计初期，为了评估一个系统的性能表现，做出一个性能类似的系统原型，并对其做性能测试和评估，这时候因为性能问题而涉及到方案的变更，影响较小。据我所知，能够做到这一点的项目极少。在大多数团队中，依赖于架构师和掌握话语权的设计者依靠经验来避免性能问题带来的大的方案变更（或者，干脆摔一次跤，再进行痛苦的“重构”）。
• 性能的自动化测试验证。这一步必须伴随着Coding进行才有较大的意义，以便尽早发现性能问题。
• 设计和代码层面的评审。其实功能问题考虑得多、暴露得早，真正有危险的往往都是那些被忽视的非功能性问题，比如性能问题。

 

最后是第三重境界。达到这重境界的团队能够在早期规划构想阶段就将性能作为一个必备因素包含在内，这可不是随口说说的经验的估计，而是要有数据驱动的理论设计，比如做性能建模，根据市场大小、业务量、服务等级等等计算出性能的具体指标，并且在此要求下做合理的架构设计。

 

这里涉及的东西有很多，除了数据，还需要有大量的思考，对于一个网站来说，不妨问问如下的问题：

 

• 数据量会有多大，我该设计什么样的存储？一致性的要求又如何？
• 实时性要求是怎么样的？用户可以接受多少时间的数据延迟？
• 网站需要考虑到什么程度的可伸缩性？
• 哪些流程的数据处理有性能风险，数据量是什么级别的？怎么解决这个问题？
• 主要的业务时间消耗是怎样的，我需要设计怎样的业务流来满足？

所有的性能问题和其他一切非功能性问题一样，都是一定程度上的trade off，所以越优秀的设计者越需要思考，来规划这些问题的解决方案，在规划中因为性能问题而涉及到的因素有哪些，太多太多了。

而要解决这样在规划中就预料到的性能问题，也有许多内容值得讨论，下面列出一些供参考：

 

• 1、集群组网：这是最基本的横向扩展的方式，把单节点的压力通过负载均衡分担到多个节点下，提高了系统负载能力的同时，亦提高了稳定性。
• 2、反向代理：一个大型的互联网网站不能不引入反向代理对静态资源的处理，Servlet容器用来处理静态图像和文本是非常奢侈的，Apache、Nginx、Squid都是优秀的解决方案。
• 3、页面静态化：互联网应用“缓存为王”，这可能是数种方案中能带来惠利最明显的一种，通过静态页面的生成和访问，有效地降低了系统负载。Web2.0的应用缓存命中率通常要稍差。
• 4、数据库优化：用户的访问难以满足了，数据库硬件设备的强化以外，从最基本的拆表、SQL调优，到纵向和横向的分库几乎成为必不可少的解决办法，或者更换廉价存储解决方案，使用NoSQL数据库等等。
• 5、CDN：CDN指的是内容分发网络，通过网络的广域层面对用户需求的分担，避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，提高用户体验。
• 6、分布式存储：海量信息的爆炸，需要廉价存储的解决方案，Web2.0的数据尤甚。分布式存储系统可以保证大吞吐量的数据读写和海量数据存储，实时性就显得不那么重要了。
• 7、数据缓存：这里的数据缓存和页面缓存区分开，数据缓存通常包括持久层层面的缓存和外部接口调用的缓存，数据缓存可以减小各类I/O调用，增加用户响应的平均时间。
• 8、功能性集群：初步的集群是对等的，这类集群方式简单可控；但是随着产品日益复杂化，用户访问压力日益增大，单纯的对等集群解决不了所有的问题，且产生大量冗余处理逻辑，使用功能性集群可以将完成不同功能的节点规约在一起。
• 9、页面分区：对一个大型网站，这是必不可少的。目的就是要进行页面静态化，并将动态和静态的区域分离开，以便在用户访问的时候，只做简单的聚合操作。
• 10、页面片段的生成和页面的聚合相剥离：许多频繁访问的相对静态的页面片段通常只需要的定时或事件触发的情况下才生成一次，甚至可以放在系统压力较轻的夜间生成。用户每次请求时只需要将静态的页面片段聚合成一个完整的页面（亦需要添加上动态的部分）即可。
• 11、隔离：对复杂系统的隔离和备份主要是为了解决稳定性问题，保持每一个单元的“简单”，化整为零，更容易将单元独立开发、产品化。
• 12、聚合方式的改进：引入高性能的服务端页面聚合方式（经过验证，常规SSI、ESI的性能存在缺陷）；甚至客户端聚合：将展示模板送到客户端，再通过Ajax请求将JSON（或其它简单格式）数据流送到客户端，在客户端使用Ajax聚合出最终的页面来，好处在于将服务端的压力分担到客户端。
• 13、组件服务化：服务化的好处在于易于将组件的处理并行化，增加整体的响应速度。模式可以遵循SOA的方式，系统中使用高性能的ESB来进行服务编排和任务分派。

要达到第三重境界还要能够预测性能问题。这就需要成熟的监控体系，监控系统的变化，尽快做出反应。

 

比如国内发生了重大事件，用户量陡增，监控系统能够及时识别出用户量监控曲线一个非常明显的跳跃过程（比如持续事件超过某个值，且曲线斜率超过某个值），发出告警，并且自动扩容来应付潜在的风险。这些，都是建立在常规的业务运营数据收集基础之上的，然后需要做数据挖掘，给出关键点。

 

再比如互联网应用“缓存为王”。对于缓存的设计，甚至很大程度上决定了应用的成败（如果你很有钱，靠大量的CDN这种非常规路线的另说，呵呵）。缓存的设计需要考虑到缓存的大小、分级、队列、命中率计算、生命周期、更新换页、数据分发、数据一致性和数据持久化等等问题，这些东西往往被很多只重视那些页面展示效果和功能的人所忽视，但如果你是优秀的设计者，你需要积累这些思考。

 

Think big。有这样一个真实的例子，我们曾经发现页面模板的OGNL性能不高（两次反射之故），遂在项目中把大部分OGNL表达式都改成了EL表达式，花了很多时间精力，性能也确实提高了，但是能提高多少呢？大概只有30%，这是一种细水长流的改进，对系统的破坏性不大，但是收效也不足以令人沾沾自喜，还失去了一些OGNL的灵活性。之后，我们换了一个思路，从大局入手，给页面划分区域，定制缓存框架，引入页面缓存能力，虽然整套方案有些复杂，但是这种架构上的进化，由于页面的生成或者部分生成直接命中了缓存文件，性能一下有了飞跃，提高了600%~800%。这就是Think big，从大处着想，见得到工程大块的结构，需要足够的视野、足够的经验和积累，可以带来显著的效果。

 

通常系统容量的设计都会要求到峰值容量以上，如果是像秒杀、抢购之类对性能要求非常高的系统，往往还存在一个问题：设计了这么大的容量，平时大部分时间业务量都比较小，这些资源浪费怎么办？（题外话：这大概也是Amazon涉足云存储和云计算的初始缘由吧）

 

我们来看这样一个在性能驱动下架构变迁发展的例子：

初期，只有简单的应用服务器和DB服务器分家，使用简单的Jetty容器，系统的瓶颈在DB侧。简单就是美，网站刚刚运营，能访问就是王道：

系统在发展中不断地演化。

有一天发现用户压力越来越大，终于无法承受了，系统屡屡到达崩溃的边缘，在现有硬件和架构条件下很难支撑现有的业务，做出了这样的改变：

在这次改变中，做了这几件重要的事情：

• 1、引入了全页面的缓存。互联网应用缓存为王，全页面的缓存可以起到立竿见影的效果。
• 2、把页面展现抽象成为“主题”，和页面数据分离开来。并且，为此，引入了“聚合”的概念，它为以后的进一步发展打下了一个伏笔。
• 3、为了缓解数据库的瓶颈，使用了RAC方式做持久层的集群。
• 4、对于JS、CSS、图片等几乎一成不变的静态资源，引入反向代理，优先处理。

网站继续安安静静地发展，悄悄地演化。

终于有一天，用户访问量激增，百万级的PV达到了，WEB2.0业务也增加进来，缓存的命中率越来越低，CPU成为了瓶颈，访问异常缓慢。这一次，又要动刀了：

这一次的架构重构做了这么几件重要的事情：

• 1、静态资源（特别是可供下载的文件），使用CDN缓解压力。
• 2、把请求拆分成主请求、异步数据请求和静态资源请求，其中主请求仅仅是获取页面不变的部分（模板+静态数据），动态的数据以异步JSON的方式获取，并在浏览器端使用JavaScript聚合。这一步把某些聚合操作放置到了客户端进行，缓解了服务端压力。
• 3、真正将页面的聚合展现和页面的生成拆分开来，保证了用户响应是快速的。
• 4、引入多层次缓存（内存中对象集合使用Memcached缓存，接口层面缓存报文，页面缓存缓存文件等），同时，对于层次的划分，容易将整个系统拆分成若干个子部件独立运作，简单、独立。
• 5、数据库进一步拆分，读写分离。
• 6、页面分块。这是大型Web2.0网站共有的特点，一个页面上往往总有那么一部分是固定不变的，这些部分应当能以页面片段的形式缓存到磁盘上，每次页面生成的时候只需要更关注变化的部分即可。

继续、继续……

访问量增长了几十倍，集群的服务器也第一次达到了三位数，系统不稳定，速度重新落下，问题定位也无比困难，一切又开始扑朔迷离起来。

这一次，不可避免地又做了架构上的调整，首要的目标，是以隔离解耦的方式增加系统稳定性，同时，更便于产品化管理：

• 1、整体采用SOA方式布局，按照功能划分集群，并且每个功能集群定义为一个“服务”，内部采用REST风格的接口访问服务。服务驱动和编制引擎（ESB角色）定时把可以提前生成的静态数据存放到共享存储上。
• 2、清晰化聚合逻辑，静态的数据尽量在服务端聚合完成，减少客户端数据请求的流量。
• 3、引入NOSQL数据库和廉价存储，适当放弃一致性，为海量数据做妥协。
• 4、开发核心业务功能包部署引擎（基于OSGi），对于业务的定制，只需要按照功能包定义的格式开发，完成后可做到不重启应用增加业务功能。

最后要说的是，如你所见，性能因素是一个网站系统发展的其中一个重要推动力，再细致的思考也难以兼容那么多未知的场景，不妨多在扩展性和兼容性上下下功夫，避免网站冷清痛苦，网站大热更痛苦。

---

3、 Where SLOW

前些天翻了翻「Wireshark数据包分析实战」，总结了一下汇聚成本文。

 

所谓慢，通常只是整体的主观感受，我们真正应该关心的是哪个环节最耗时？

判断原则按上图所示：

1. 如果 TCP 握手或 ACK 耗时长，那么说明网络慢。
2. 如果请求耗时长，那么说明客户端慢。
3. 如果响应耗时长，那么说明服务端慢。

实战抓包按下图所示：

Package

对应结果依次是：正常、网络慢、客户端慢、服务端慢，如果使用 Wireshark，那么可能会发现时间显示格式有差异，改成相对时间就好了。此外赞一下 CloudShark。

 

  

4  常见性能优化策略的总结

A 常见性能优化策略分类

代码、数据库、缓存、异步、nosql、JVM调优、多线程与分布式、度量系统等等

代码

之所以把代码放到第一位，是因为这一点最容易引起技术人员的忽视。很多技术人员拿到一个性能优化的需求以后，言必称缓存、异步、JVM等。实际上，第一步就应该是分析相关的代码，找出相应的瓶颈，再来考虑具体的优化策略。有一些性能问题，完全是由于代码写的不合理，通过直接修改一下代码就能解决问题的，比如for循环次数过多、作了很多无谓的条件判断、相同逻辑重复多次等。

 

数据库

数据库的调优，总的来说分为以下三部分：

SQL调优

这是最常用、每一个技术人员都应该掌握基本的SQL调优手段（包括方法、工具、辅助系统等）。这里以MySQL为例，最常见的方式是，由自带的慢查询日志或者开源的慢查询系统定位到具体的出问题的SQL，然后使用explain、profile等工具来逐步调优，最后经过测试达到效果后上线。这方面的细节，可以参考MySQL索引原理及慢查询优化。

架构层面的调优

这一类调优包括读写分离、多从库负载均衡、水平和垂直分库分表等方面，一般需要的改动较大，但是频率没有SQL调优高，而且一般需要DBA来配合参与。那么什么时候需要做这些事情？我们可以通过内部监控报警系统（比如Zabbix），定期跟踪一些指标数据是否达到瓶颈，一旦达到瓶颈或者警戒值，就需要考虑这些事情。通常，DBA也会定期监控这些指标值。

连接池调优

我们的应用为了实现数据库连接的高效获取、对数据库连接的限流等目的，通常会采用连接池类的方案，即每一个应用节点都管理了一个到各个数据库的连接池。随着业务访问量或者数据量的增长，原有的连接池参数可能不能很好地满足需求，这个时候就需要结合当前使用连接池的原理、具体的连接池监控数据和当前的业务量作一个综合的判断，通过反复的几次调试得到最终的调优参数。

 

缓存

分类

本地缓存（HashMap/ConcurrentHashMap、Ehcache、Guava Cache等），缓存服务（Redis/Tair/Memcache等）。

使用场景

什么情况适合用缓存？考虑以下两种场景：

• 短时间内相同数据重复查询多次且数据更新不频繁，这个时候可以选择先从缓存查询，查询不到再从数据库加载并回设到缓存的方式。此种场景较适合用单机缓存。
• 高并发查询热点数据，后端数据库不堪重负，可以用缓存来扛。

选型考虑

• 如果数据量小，并且不会频繁地增长又清空（这会导致频繁地垃圾回收），那么可以选择本地缓存。具体的话，如果需要一些策略的支持（比如缓存满的逐出策略），可以考虑Ehcache；如不需要，可以考虑HashMap；如需要考虑多线程并发的场景，可以考虑ConcurentHashMap。
• 其他情况，可以考虑缓存服务。目前从资源的投入度、可运维性、是否能动态扩容以及配套设施来考虑，我们优先考虑Tair。除非目前Tair还不能支持的场合（比如分布式锁、Hash类型的value），我们考虑用Redis。

设计关键点

什么时候更新缓存？如何保障更新的可靠性和实时性？

更新缓存的策略，需要具体问题具体分析。这里以门店POI的缓存数据为例，来说明一下缓存服务型的缓存更新策略是怎样的？目前约10万个POI数据采用了Tair作为缓存服务，具体更新的策略有两个：

• 接收门店变更的消息，准实时更新。
• 给每一个POI缓存数据设置5分钟的过期时间，过期后从DB加载再回设到DB。这个策略是对第一个策略的有力补充，解决了手动变更DB不发消息、接消息更新程序临时出错等问题导致的第一个策略失效的问题。通过这种双保险机制，有效地保证了POI缓存数据的可靠性和实时性。

缓存是否会满，缓存满了怎么办？

对于一个缓存服务，理论上来说，随着缓存数据的日益增多，在容量有限的情况下，缓存肯定有一天会满的。如何应对？
① 给缓存服务，选择合适的缓存逐出算法，比如最常见的LRU。
② 针对当前设置的容量，设置适当的警戒值，比如10G的缓存，当缓存数据达到8G的时候，就开始发出报警，提前排查问题或者扩容。
③ 给一些没有必要长期保存的key，尽量设置过期时间。

缓存是否允许丢失？丢失了怎么办？

根据业务场景判断，是否允许丢失。如果不允许，就需要带持久化功能的缓存服务来支持，比如Redis或者Tair。更细节的话，可以根据业务对丢失时间的容忍度，还可以选择更具体的持久化策略，比如Redis的RDB或者AOF。

缓存被“击穿”问题

对于一些设置了过期时间的key，如果这些key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑另外一个问题：缓存被“击穿”的问题。

• 概念：缓存在某个时间点过期的时候，恰好在这个时间点对这个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。

• 如何解决：业界比较常用的做法，是使用mutex。简单地来说，就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db，而是先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX或者Memcache的ADD）去set一个mutex key，当操作返回成功时，再进行load db的操作并回设缓存；否则，就重试整个get缓存的方法。类似下面的代码：

    public String get(key) {
        String value = redis.get(key);
        if (value == null) { //代表缓存值过期
            //设置3min的超时，防止del操作失败的时候，下次缓存过期一直不能load db
            if (redis.setnx(key_mutex, 1, 3 * 60) == 1) {  //代表设置成功
                 value = db.get(key);
                        redis.set(key, value, expire_secs);
                        redis.del(key_mutex);
                } else {  //这个时候代表同时候的其他线程已经load db并回设到缓存了，这时候重试获取缓存值即可
                        sleep(50);
                        get(key);  //重试
                }
            } else {
                return value;      
            }
    }
  

 

异步

使用场景

针对某些客户端的请求，在服务端可能需要针对这些请求做一些附属的事情，这些事情其实用户并不关心或者用户不需要立即拿到这些事情的处理结果，这种情况就比较适合用异步的方式处理这些事情。

作用

• 缩短接口响应时间，使用户的请求快速返回，用户体验更好。
• 避免线程长时间处于运行状态，这样会引起服务线程池的可用线程长时间不够用，进而引起线程池任务队列长度增大，从而阻塞更多请求任务，使得更多请求得不到技术处理。
• 线程长时间处于运行状态，可能还会引起系统Load、CPU使用率、机器整体性能下降等一系列问题，甚至引发雪崩。异步的思路可以在不增加机器数和CPU数的情况下，有效解决这个问题。

常见做法

一种做法，是额外开辟线程，这里可以采用额外开辟一个线程或者使用线程池的做法，在IO线程（处理请求响应）之外的线程来处理相应的任务，在IO线程中让response先返回。

如果异步线程处理的任务设计的数据量非常巨大，那么可以引入阻塞队列BlockingQueue作进一步的优化。具体做法是让一批异步线程不断地往阻塞队列里扔数据，然后额外起一个处理线程，循环批量从队列里拿预设大小的一批数据，来进行批处理（比如发一个批量的远程服务请求），这样进一步提高了性能。

另一种做法，是使用消息队列（MQ）中间件服务，MQ天生就是异步的。一些额外的任务，可能不需要我这个系统来处理，但是需要其他系统来处理。这个时候可以先把它封装成一个消息，扔到消息队列里面，通过消息中间件的可靠性保证把消息投递到关心它的系统，然后让这个系统来做相应的处理。

比如C端在完成一个提单动作以后，可能需要其它端做一系列的事情，但是这些事情的结果不会立刻对C端用户产生影响，那么就可以先把C端下单的请求响应先返回给用户，返回之前往MQ中发一个消息即可。而且这些事情理应不是C端的负责范围，所以这个时候用MQ的方式，来解决这个问题最合适。

 

NoSQL

和缓存的区别

先说明一下，这里介绍的和缓存那一节不一样，虽然可能会使用一样的数据存储方案（比如Redis或者Tair），但是使用的方式不一样，这一节介绍的是把它作为DB来用。如果当作DB来用，需要有效保证数据存储方案的可用性、可靠性。

使用场景

需要结合具体的业务场景，看这块业务涉及的数据是否适合用NoSQL来存储，对数据的操作方式是否适合用NoSQL的方式来操作，或者是否需要用到NoSQL的一些额外特性（比如原子加减等）。

如果业务数据不需要和其他数据作关联，不需要事务或者外键之类的支持，而且有可能写入会异常频繁，这个时候就比较适合用NoSQL（比如HBase）。

比如，美团点评内部有一个对exception做的监控系统，如果在应用系统发生严重故障的时候，可能会短时间产生大量exception数据，这个时候如果选用MySQL，会造成MySQL的瞬间写压力飙升，容易导致MySQL服务器的性能急剧恶化以及主从同步延迟之类的问题，这种场景就比较适合用Hbase类似的NoSQL来存储。

 

JVM调优

什么时候调？

通过监控系统（如没有现成的系统，自己做一个简单的上报监控的系统也很容易）上对一些机器关键指标（gc time、gc count、各个分代的内存大小变化、机器的Load值与CPU使用率、JVM的线程数等）的监控报警，也可以看gc log和jstat等命令的输出，再结合线上JVM进程服务的一些关键接口的性能数据和请求体验，基本上就能定位出当前的JVM是否有问题，以及是否需要调优。

怎么调？

1. 如果发现高峰期CPU使用率与Load值偏大，这个时候可以观察一些JVM的thread count以及gc count（可能主要是young gc count），如果这两个值都比以往偏大（也可以和一个历史经验值作对比），基本上可以定位是young gc频率过高导致，这个时候可以通过适当增大young区大小或者占比的方式来解决。
2. 如果发现关键接口响应时间很慢，可以结合gc time以及gc log中的stop the world的时间，看一下整个应用的stop the world的时间是不是比较多。如果是，可能需要减少总的gc time，具体可以从减小gc的次数和减小单次gc的时间这两个维度来考虑，一般来说，这两个因素是一对互斥因素，我们需要根据实际的监控数据来调整相应的参数（比如新生代与老生代比值、eden与survivor比值、MTT值、触发cms回收的old区比率阈值等）来达到一个最优值。
3. 如果发生full gc或者old cms gc非常频繁，通常这种情况会诱发STW的时间相应加长，从而也会导致接口响应时间变慢。这种情况，大概率是出现了“内存泄露”，Java里的内存泄露指的是一些应该释放的对象没有被释放掉（还有引用拉着它）。那么这些对象是如何产生的呢？为啥不会释放呢？对应的代码是不是出问题了？问题的关键是搞明白这个，找到相应的代码，然后对症下药。所以问题的关键是转化成寻找这些对象。怎么找？综合使用jmap和MAT，基本就能定位到具体的代码。

 

多线程与分布式

使用场景

离线任务、异步任务、大数据任务、耗时较长任务的运行**，适当地利用，可达到加速的效果。

注意：线上对响应时间要求较高的场合，尽量少用多线程，尤其是服务线程需要等待任务线程的场合（很多重大事故就是和这个息息相关），如果一定要用，可以对服务线程设置一个最大等待时间。

常见做法

如果单机的处理能力可以满足实际业务的需求，那么尽可能地使用单机多线程的处理方式，减少复杂性；反之，则需要使用多机多线程的方式。

对于单机多线程，可以引入线程池的机制，作用有二：

• 提高性能，节省线程创建和销毁的开销
• 限流，给线程池一个固定的容量，达到这个容量值后再有任务进来，就进入队列进行排队，保障机器极限压力下的稳定处理能力在使用JDK自带的线程池时，一定要仔细理解构造方法的各个参数的含义，如core pool size、max pool size、keepAliveTime、worker queue等，在理解的基础上通过不断地测试调整这些参数值达到最优效果。

如果单机的处理能力不能满足需求，这个时候需要使用多机多线程的方式。这个时候就需要一些分布式系统的知识了。首先就必须引入一个单独的节点，作为调度器，其他的机器节点都作为执行器节点。调度器来负责拆分任务，和分发任务到合适的执行器节点；执行器节点按照多线程的方式（也可能是单线程）来执行任务。这个时候，我们整个任务系统就由单击演变成一个集群的系统，而且不同的机器节点有不同的角色，各司其职，各个节点之间还有交互。这个时候除了有多线程、线程池等机制，像RPC、心跳等网络通信调用的机制也不可少。后续我会出一个简单的分布式调度运行的框架。

 

度量系统（监控、报警、服务依赖管理）

严格来说，度量系统不属于性能优化的范畴，但是这方面和性能优化息息相关，可以说为性能优化提供一个强有力的数据参考和支撑。没有度量系统，基本上就没有办法定位到系统的问题，也没有办法有效衡量优化后的效果。很多人不重视这方面，但我认为它是系统稳定性和性能保障的基石。

关键流程

如果要设计这套系统，总体来说有哪些关键流程需要设计呢？
① 确定指标
② 采集数据
③ 计算数据，存储结果
④ 展现和分析

需要监控和报警哪些指标数据？需要关注哪些？

按照需求出发，主要需要二方面的指标：

1. 接口性能相关，包括单个接口和全部的QPS、响应时间、调用量（统计时间维度越细越好；最好是，既能以节点为维度，也可以以服务集群为维度，来查看相关数据）。其中还涉及到服务依赖关系的管理，这个时候需要用到服务依赖管理系统
2. 单个机器节点相关，包括CPU使用率、Load值、内存占用率、网卡流量等。如果节点是一些特殊类型的服务（比如MySQL、Redis、Tair），还可以监控这些服务特有的一些关键指标。

数据采集方式

通常采用异步上报的方式，具体做法有两种：第一种，发到本地的Flume端口，由Flume进程收集到远程的Hadoop集群或者Storm集群来进行运算；第二种，直接在本地运算好以后，使用异步和本地队列的方式，发送到监控服务器。

数据计算

可以采用离线运算（MapReduce/Hive）或者实时/准实时运算（Storm/Spark）的方式，运算后的结果存入MySQL或者HBase；某些情况，也可以不计算，直接采集发往监控服务器。

展现和分析

提供统一的展现分析平台，需要带报表（列表/图表）监控和报警的功能。

 

B 真实案例分析

案例一：商家与控制区关系的刷新job

背景

这是一个每小时定期运行一次的job，作用是用来刷新商家与控制区的关系。具体规则就是根据商家的配送范围（多个）与控制区是否有交集，如果有交集，就把这个商家划到这个控制区的范围内。

业务需求

需要这个过程越短越好，最好保持在20分钟内。

优化过程

原有代码的主要处理流程是：

1. 拿到所有门店的配送范围列表和控制区列表。
2. 遍历控制区列表，针对每一个控制区：
   a. 遍历商家的配送范围列表，找到和这个控制区相交的配送范围列表。
   b. 遍历上述商家配送范围列表，对里面的商家ID去重，保存到一个集合里。
   c. 批量根据上述商家ID集合，取到对应的商家集合。
   d. 遍历上述商家集合，从中拿到每一个商家对象，进行相应的处理（根据是否已是热门商家、自营、在线支付等条件来判断是否需要插入或者更新之前的商家和控制区的关系）。
   e. 删除这个控制区当前已有的，但是不应该存在的商家关系列表。

分析代码，发现第2步的a步骤和b步骤，找出和某控制区相交的配送范围集合并对商家ID去重，可以采用R树空间索引的方式来优化。具体做法是：

• 任务开始先更新R树，然后利用R树的结构和匹配算法来拿到和控制区相交的配送范围ID列表。
• 再批量根据配送范围ID列表，拿到配送范围列表。
• 然后针对这一批配送范围列表（数量很小），用原始多边形相交匹配的方法做进一步过滤，并且对过滤后的商家ID去重。

这个优化已经在第一期优化中上线，整个过程耗时由40多分钟缩短到20分钟以内。

第一期优化改为R树以后，运行了一段时间，随着数据量增大，性能又开始逐渐恶化，一个月后已经恶化到50多分钟。于是继续深入代码分析，寻找了两个优化点，安排第二期优化并上线。

这两个优化点是：

• 第2步的c步骤，原来是根据门店ID列表从DB批量获取门店，现在可以改成mget的方式从缓存批量获取（此时商家数据已被缓存）；
• 第2步的d步骤，根据是否已是热门商家、自营、在线支付等条件来判断是否需要插入或者更新之前的商家和控制区的关系。

上线后效果

通过日志观察，执行时间由50多分钟缩短到15分钟以内，下图是截取了一天的4台机器的日志时间（单位：毫秒）：

可以看到，效果还是非常明显的。

案例二：POI缓存设计与实现

背景

2014年Q4，数据库中关于POI（这里可以简单理解为外卖的门店）相关的数据的读流量急剧上升，虽然说加入从库节点可以解决一部分问题，但是毕竟节点的增加是会达到极限的，达到极限后主从复制会达到瓶颈，可能会造成数据不一致。所以此时，急需引入一种新的技术方案来分担数据库的压力，降低数据库POI相关数据的读流量。另外，任何场景都考虑加DB从库的做法，会对资源造成一定的浪费。

实现方案

基于已有的经过考验的技术方案，我选择Tair来作为缓存的存储方案，来帮DB分担来自于各应用端的POI数据的读流量的压力。理由主要是从可用性、高性能、可扩展性、是否经过线上大规模数据和高并发流量的考验、是否有专业运维团队、是否有成熟工具等几个方面综合考量决定。

详细设计

第一版设计

缓存的更新策略，根据业务的特点、已有的技术方案和实现成本，选择了用MQ来接收POI改变的消息来触发缓存的更新，但是这个过程有可能失败；同时启用了key的过期策略，并且调用端会先判断是否过期，如过期，会从后端DB加载数据并回设到缓存，再返回。通过两个方面双保险确保了缓存数据的可用。

第二版设计

第一版设计运行到一段时间以后，我们发现了两个问题：

1. 某些情况下不能保证数据的实时一致（比如技术人员手动改动DB数据、利用MQ更新缓存失败），这个时候只能等待5分钟的过期时间，有的业务是不允许的。
2. 加入了过期时间导致另外一个问题：Tair在缓存不命中的那一刻，会尝试从硬盘中Load数据，如果硬盘没有再去DB中Load数据。这无疑会进一步延长Tair的响应时间，这样不仅使得业务的超时比率加大，而且会导致Tair的性能进一步变差。

为了解决上述问题，我们从美团点评负责基础架构的同事那里了解到Databus可以解决缓存数据在某些情况下不一致的问题，并且可以去掉过期时间机制，从而提高查询效率，避免tair在内存不命中时查询硬盘。而且为了防止DataBus单点出现故障影响我们的业务，我们保留了之前接MQ消息更新缓存的方案，作了切换开关，利用这个方案作容错，整体架构如下：

上线后效果

上线后，通过持续地监控数据发现，随着调用量的上升，到DB的流量有了明显地减少，极大地减轻了DB的压力。同时这些数据接口的响应时间也有了明显地减少。缓存更新的双重保障机制，也基本保证了缓存数据的可用。见下图：

案例三：业务运营后台相关页面的性能优化

背景

随着业务的快速发展，带来的访问量和数据量的急剧上升，通过我们相应的监控系统可以发现，系统的某些页面的性能开始出现恶化。 从用户方的反馈，也证明了这点。此时此刻，有必要迅速排期，敏捷开发，对这些页面进行调优。

欢迎页

• 需求背景：欢迎页是地推人员乃至总部各种角色人员进入外卖运营后台的首页，会显示地推人员最想看到最关心的一些核心数据，其重要性不言而喻，所以该页面的性能恶化会严重影响到用户体验。因此，首先需要优化的就是欢迎页。通过相应定位和分析，发现导致性能恶化的主要原因有两个：数据接口层和计算展现层。
• 解决方案：对症下药，分而治之。经过仔细排查、分析定位，数据接口层采用接口调用批量化、异步RPC调用的方式来进行有效优化，计算展现层决定采用预先计算、再把计算好的结果缓存的方式来提高查询速度。其中，缓存方案根据业务场景和技术特点，选用Redis。定好方案后，快速开发上线。
• 上线效果：上线后性能对比图，如下：
  

组织架构页

• 需求背景：组织架构页，采用了四层树形结构图，一起呈现加载，第一版上线后发现性能非常差。用户迫切希望对这个页面的性能进行调优。
• 解决方案：经过分析代码，定位到一个比较经典的问题：里面执行了太多次小数据量的SQL查询。于是采用多个SQL合并成大SQL的方式，然后使用本地缓存来缓存这些数据，合理预估数据量和性能，充分测试后上线。
• 上线效果：上线后性能对比图，如下：
  

订单关联楼宇页

• 需求背景：随着订单量日益增大，订单表积累的数据日益增多，订单关联楼宇页的性能也日益变差（响应时间线性上升）。而这个页面和地推人员的业绩息息相关，所以地推人员使用该页面的频率非常高，性能日益恶化极大地影响了地推人员的用户体验。
• 解决方案：经过分析与设计，决定采用当时已有的订单二级索引月分表来代替原始的订单表来供前端的查询请求；并且限制住筛选的时间条件，使得筛选的开始时间和结束时间不能跨月（事先和用户沟通过，可以接受，能满足用户的基本需求），这样就只需一个月分索引表即可，通过适当的功能限制来达到性能的调优。这样从二级索引月分表中根据各种查询条件查到最终的分页的订单ID集合，然后再根据订单ID从订单库来查出相应的订单数据集合。
• 上线效果：上线后发现在调用量几乎没怎么变的情况下，性能提升明显，如下图：
  

其他

除了上面介绍的之外，优化还涉及前端、分布式文件系统、CDN、全文索引、空间索引等几方面。限于篇幅，我们留到未来再做介绍。

 

 

---

5、蚂蚁金服技术专家总结：性能优化的常见招式

 

摘要： 对于很多开发者而言，性能优化往往成为一个比较棘手的问题。但是为什么大家觉得性能优化难？难又难在哪里呢？当我们知道难在哪里了以后又如何下手去解决呢？本文来自蚂蚁金服的技术专家陈显铭就为大家一一解答。

本文主要会介绍性能评估的一些简单概念以及性能压测/性能瓶颈的识别方法和一些常见的优化方式。虽然内容很多，但是目的在于让大家有个全局的认识；本文虽然深入度上面稍微欠缺，但是足以应对日常的性能分析。

为什么大家觉得性能优化难？

很多人觉得性能优化难的原因，其实主要是不知道怎么去做评估，主要表现在一下几个方面

1、不知道性能是什么？
2、不知性能的评估标准是什么？
3、不知道影响性能的相关元素是什么？
4、不知道性能问题的带来的现象是什么？ 

性能优化，必须知道的几个概念

关于性能的几个基础概念就像一把刀，你需要知道他可以用来削水果，还可以用来杀人。
认知，决定了你能拿它干什么，决定了能否识别到本质。
性能调优，就是一条通过现象看本质的认知之路。

性能优化中必须知道的几个概念诸如：

1、  响应时间（RT）
2、  吐出量（QPS/TPS）

3、  资源（CPU、线程等）

 

下面通过对这几个概念的详细剖析，进行讲解。

 

QPS概念扫盲

概念

QPS：Query Per Second
TPS：Transactions PerSecond

起源：数据库系统中表述性能的重要指标。

现在：对于应用系统而言，现在QPS，TPS的概念有点混淆，泛指系统单位时间的处理能力。

这两个概念是衡量性能很明确的指标，我们用它来泛指单位时间系统的处理能力。但是仅仅知道QPS/TPS的概念，就能做性能分析，性能调优了吗？是哪些因素会影响QPS/TPS？

 

接下来我一层层来剖析：响应时间模型，线程模型，已经线程和资源之间的关系。

深入理解响应时间组成模型

很多人对响应时间的组成是不清晰，导致不能很好的判断，时间消耗在了什么地方。明白时间消耗的节点是很重要的一件事。

不知道响应时间组成的优化就像是乱枪打鸟。需要明白时间消耗在什么地方，是什么原因造成的消耗。 

不要认为只有CPU消耗；更不要认为加CPU核数就可以解决问题。

通常是通过埋点的方式把代码执行切分成一段一段的片段，获取各个节点、各类节点的消耗，用于观察性能情况，定位性能瓶颈点；链路上的埋点，可以配合监控系统统一来看，阿里是自己实现了一个简单的埋点类。 

响应时间是程序（进程、线程）在资源（CPU）运行的一个体现。所以，资源和程序运行的载体会影响这个结果。下面深度理解JAVA的线程模型。

深入理解线程模型

进程/线程是程序运行的载体，所以深入理解线程的机制有助于帮助性能分析。请看下图

 

左上的图，是线程几个状态之间的扭转。

左下的图，是线程在锁的争用时候的运行态。
右上的图讲linux中，java主进程、java线程/LWP轻量级进程和CPU调度，CPU绑定运行的模型：

1、线程/进程是操作系统调度的关键资源。
2、理解器运行机制有利于知道一个请求中的运算是消耗在什么节点。CPU只是一个点，其他资源也是会影响线程的执行。
3、多线程情况下，线程不一定是满转的，遇到共享资源争用的时候，会造成阻塞。

线程和CPU是程序运行的宝贵资源。资源不足会造成性能问题；资源富足优惠造成资源浪费。到底匹配多少资源才是最优的呢？

下一步解释最优线程数，如何最优化资源配比，理解资源之间的关系。

深度剖析最优线程数

最优线程数定义

1. 尽可能保持应用对资源的最大化使用。
2. 当线程数较少的时，有压力情况下，可能造成线程资源不足，请求需要等待线程释放后才能处理。
3. 当线程数较多的时，线程自身也是需要消耗内存资源的，导致资源的浪费，同时，线程较多的时候对于线程的调度和争用也会影响性能。

如何确定或者使用尽量少的线程，就能让当前的资源高效利用呢？

可能大家有个疑问：怎么最优线程数，有毛用啊！我反正给他很多线程，这不就完事了吗？比如最后线程是100，我给你200（好，你是牛人，你是有钱人，哈哈）

 

但是我认为：对资源使用情况的合理理解和分析，是很重要的，尤其是如果你是个老板，你要关心钱用了多少吧，那些钱不该花吧！如果你是个技术人员，你要告诉你的老板这些是啊，毕竟你是一个有追求的程序员（不然老板就开了你。。。）

为了剖析最优线程数和资源之间的关系，下面我讲一步步分解，让大家理解。

深度理解瓶颈资源

为了理解瓶颈资源，假设一个业务场景：

下面通过对程序运行态通过图表的方式是呈现出来，便于大家理解瓶颈资源、多资源情况下的线程调度。

以5ms作为一个时间帧。
第1个5ms如下
cpu同时可以运4个线程，因此请求11，21,31,41执行，其余5个请求，等待CPU资源。

第2个5ms如下
cpu同时可以运4个线程，其余5个请求，等待CPU资源。


第3个5ms如下


第4个5ms如下

第5个5ms如下

 通过快照图，我可以看到什么？
一个多资源的程序中：对资源的争用表现为对瓶颈资源的争用，性能情况会受制于瓶颈资源。

瓶颈资源可以用水桶原理来解释，如下图。


基于上述对线程、瓶颈资源的梳理，我们很容易提炼出QPS的理论公式，大家可以看下面的公式，如果觉得烧脑，可以多看几遍。

深入理解QPS公式

最优线程公式
1、  最优线程数量=线程总时间/瓶颈资源时间 * 瓶颈资源并行数
2、  一个线程1S可以处理的请求数
3、  1000/线程总时间

QPS公式1：QPS =最优线程数量* 1000/线程总时间
QPS公式2：QPS=1000/瓶颈资源时间 * 瓶颈资源并行数

这个公式里隐含了一些有趣的解释，大家可以去揣摩下。

性能压测：从理解瓶颈到如何识别瓶颈

前面讲的都是理论，很多很多理论，下来大家可以花些时间理解。主要目的是让大家对性能有个可量化的指标衡量，知道指标了，那么下一步就是讲如何获得这些指标，如果通过这些指标发现问题。

接下来的章节，如何识别瓶颈资源，常用的方式是压测，下面是压测模型图（没有讲怎么使用jmeter压测等）

压测模型抽象 

性能压测是有方法，有模式，有目标的。如何对压测进行管理，如何创造压力，如何准备被测系统，如何准备压测数据，如何收集压测数据，如何分析压测数据。是要进行稳定压测，还是要进行瓶颈压测等等。

性能压测是一件很专业的事情，对于压测，理解压测的组成环境是很重要的，有的时候，压测的环境就是压测瓶颈。

压测环境组成

这里讲两个环境：

1、压力机环境：不要认为压不上去了就是被测系统的问题，曾经也遇到过jmeter处理压测响应数据的性能瓶颈，导致一致压不上去。
2、依赖系统/数据的影响：举个例子比如集群部署后，线上A调用B应用，A是100台，B是1000台；但是线下性能实验室A和B是1：1关系。1：1压测出来的数据是否就是线上的数据呢，这里是有一个问号的。

压测需要注意的一些事项

•     理解环境
•     压测环境和线上环境的不同
•     避免压测环境的不同造成压测结果的不可行
•     吞吐量和响应时间的取舍和平衡
•     确定合理的性能预期值
•     适可而止
•     不做过度的优化，在性能和其他因素（架构，可维护性）等的平衡
•     选取合适的压测场景设计用例
•     天花板
•     充分利用资源
•     不过度使用资源

从识别瓶颈到如何进行优化

内容可以见下图


如何识别瓶颈？永远也不会废的方法，隔离法和替换法。当你觉得对哪一块怀疑（CPU、IO、线程、压力机、外围系统）的时候，可以快速的使用这些方法识别。

比如你可以使用mock，挡板，更换机器。
这两个方法很简单，比冥思苦想有用多了，所以性能优化，不要把自己逼疯了。

优化手段，可以见图中方式，性能优化有一定招式，但是结合具体场景后，有各种取舍，不要一味生搬硬套。

---

 

Q&A

Q1 什么时候需要优化性能？需要提前考虑么？

我认为性能的问题是一个技术人员、架构师骨子里的东西（需要提前考虑）；但是实施的步骤是根据你的业务场景、业务量、业务增量、系统当前的容量，系统的扩展性等问题来考虑（比如是否可以水平扩展应对等），不用做过渡的超前设计。

Q2 上图中的N+1那个N指什么？

N就是对CPU的核数，这里只是理解了很多人/或者网上提高的一些经验值，这些经验值有可能是在没有考虑多资源的情况下的值，但是有可能你的系统就不是一个CPU密集运算性系统

Q3 比较感兴趣耗时统计工具，是开源的么？有移动端的统计工具么？

耗时统计的这个东西，我觉得主要是看埋点。你用什么东西埋点，对于阿里体系也就是一个简单的类。没有那么复杂；对于链路上的，我认为可以打印各个节点的达到时间，最后监控来看。
移动端的工具，我接触很少，sorry。

Q4 测试性能的机器 怎么选 有的说要高配，有的说要烂机器。

没那么多讲究，不要听很多大公司的忽悠，不要全听咨询师的，黑一把咨询师。举个例子，原来都说我们要用大型机，然后要用小型机，现在大家都用 pcserver。