性能调优
性能调优是一个非常大的议题,更多的是开发人员进行,对于测试人员,可以了解一些通用的调优方法,并根据性能分析过程中发现的问题,给出一些建议。
1. 性能调优目标与策略
性能优化的目标不外乎两个:时间性能:减小系统执行的时间;空间性能:减小系统占用的空间。
一般来说,性能优化也就是下面的几个策略:
用空间换时间。各种cache如CPU L1/L2/RAM到硬盘,都是用空间来换时间的策略。这样策略基本上是把计算的过程一步一步的保存或缓存下来,这样就不用每次用的时候都要再计算一遍,比如数据缓冲,CDN,等。这样的策略还表现为冗余数据,比如数据镜象,负载均衡什么的。
用时间换空间。有时候,少量的空间可能性能会更好,比如网络传输,如果有一些压缩数据的算法,这样的算法其实很耗时,但是因为瓶颈在网络传输,所以用时间来换空间反而能省时间。
简化代码。最高效的程序就是不执行任何代码的程序,所以,代码越少性能就越高。如:减少循环的层数,减少递归,在循环中少声明变量,少做分配和释放内存的操作,尽量把循环体内的表达式抽到循环外,条件表达的中的多个条件判断的次序,尽量在程序启动时把一些东西准备好,注意函数调用的开销(栈上开销),注意面向对象语言中临时对象的开销,小心使用异常,等等,这连东西需要我们非常了解编程语言和常用的库。
并行处理。如果CPU只有一个核,你要玩多进程,多线程,对于计算密集型的软件会反而更慢(因为操作系统调度和切换开销很大),CPU的核多了才能真正体现出多进程多线程的优势。并行处理需要我们的程序有Scalability,不能水平或垂直扩展的程序无法进行并行处理。从架构上来说,是否可以做到不改代码只是加加机器就可以完成性能提升?总之,根据2:8原则来说,20%的代码耗了你80%的性能,找到那20%的代码,你就可以优化那80%的性能。
2. 调优原则
- 在应用系统的设计、开发过程中,应始终把性能放在考虑的范围内。
- 确定清晰明确的性能目标是关键。
- 必须保证调优后的程序运行正确。
- 性能更大程度是取决于良好的设计,调优技巧只是一个辅助手段。
- 调优过程是叠代渐进的过程,每次调优的结果要反馈到后续的代码开发中去。
- 性能调优不能以牺牲代码的可读性和维护性为代价。
3. 调优的基本步骤
确定清晰的性能目标,并按优先级排列;
利用科学的测试工具对应用程序进行测试,并记录测试结果;
把分布式系统拆分成组件:Web层、业务层、集成层、以及网络传输时间,分别进行调优。
有系统的科学调优:
遵循一定的程序:测试性能→找出瓶颈→假设造成瓶颈的因素→测试假设是否成立→修改应用→再次测试性能
确定影响性能的因素:CPU、内存还是IO。
找出主要的瓶颈,首先解决最容易的,再重复测试。
一次修改一个瓶颈,不要对不需要的地方进行调优
提高CPU性能:更快的代码,更好的算法,减少短期生存的对象。
提高内存性能:减少或减小长期生存的对象。
提高IO性能:重新设计应用,减少IO的交互。
优化完成之后,进行QA测试。
在代码中记录优化的地方,并对旧代码进行注释。
4. 性能调优的层次
为了提升系统性能,开发人员可以从系统的各个角度和层次对系统进行优化。除了最常见的代码优化外,在软件架构上、JVM虚拟机层、数据库以及操作系统层面都可以通过各种手段进行调优,从而在整体上提升系统的性能。
4.1 设计调优
设计调优处于所有调优手段的上层,它往往需要在软件开发之前进行。在软件开发之初,架构师就应该评估系统可能存在的各种潜在问题,并给出合理的设计方案。由于软件设计和架构对软件整体质量有决定性的影响,所以,设计调优对系统性能的影响也是最大的。如果说,代码优化、JVM优化都是对系统微观层面上"量"的优化,那么设计优化就是对系统在宏观层面上"质"的优化。
设计优化的一大显著特点是,它可以规避某一个组件的性能问题,而非改良该组件的实现。比如,系统中组件A需要等待某事件E才能触发一个行为。如果组件A通过循环监控不断监测事件E是否发生,其监测行为必然会占用部分系统资源,因此,开发人员必须在监测频率和资源消耗间取得平衡。如果监测频率太低,虽然减少了资源消耗,但是系统实时反应性就会降低。如果进行代码层的调优,就需要优化监测方法的实现以及求得一个最为恰当的监测频率。
而若将此问题预留在设计层解决,便可以使用事件通知的方式将系统行为进行倒置。如使用第2章中提到的观察者模式,在事件E发生的时刻,由事件E通知组件A,从而触发组件A的行为。这种设计方法弃用了存在性能隐患的循环监控,从根本上解决了这一问题。
从某种程度上说,设计优化直接决定了系统的整体品质。如果在设计层考虑不周,留下太多问题隐患,那么这些"质"上的问题,也许无法再通过代码层的优化进行弥补。因此,开发人员必须在软件设计之初,认真仔细考虑软件系统的性能问题。
进行设计优化时,设计人员必须熟悉常用的软件设计方法、设计模式、基本性能组件和常用优化思想,并将其有机地集成在软件系统中。
注意:一个良好的系统设计可以规避很多潜在的性能问题。因此,尽可能多花些时间在系统设计上,是创建高性能程序的关键。
4.2 算法调优
算法非常重要,好的算法会有更好的性能。举几个例子,大家可以感觉一下。
一个是过滤算法。系统需要对收到的请求做过滤,我们把可以被filter in/out的东西配置在了一个文件中,原有的过滤算法是遍历过滤配置,后来,我们找到了一种方法可以对这个过滤配置进行排序,这样就可以用二分折半的方法来过滤,系统性能增加了50%。
一个是哈希算法。计算哈希算法的函数并不高效,一方面是计算太费时,另一方面是碰撞太高,碰撞高了就跟单向链表一个性能(可参看Hash Collision DoS 问题)。我们知道,算法都是和需要处理的数据很有关系的,就算是被大家所嘲笑的“冒泡排序”在某些情况下(大多数数据是排好序的)其效率会高于所有的排序算法。哈希算法也一样,广为人知的哈希算法都是用英文字典做测试,但是我们的业务在数据有其特殊性,所以,对于还需要根据自己的数据来挑选适合的哈希算法。
分而治之和预处理。如某程序为了生成月报表,每次都需要计算很长的时间,有时候需要花将近一整天的时间。于是我们把我们找到了一种方法可以把这个算法发成增量式的,也就是说我每天都把当天的数据计算好了后和前一天的报表合并,这样可以大大的节省计算时间,每天的数据计算量只需要20分钟,但是如果我要算整个月的,系统则需要10个小时以上(SQL语句在大数据量面前性能成级数性下降)。这种分而治之的思路在大数据面前对性能有很帮助,就像merge排序一样。SQL语句和数据库的性能优化也是这一策略,如:使用嵌套式的Select而不是笛卡尔积的Select,使用视图,等等。
4.3 代码调优
代码调优是在软件开发过程中,或者在软件开发完成后,软件维护过程中进行的对程序代码的改进和优化。代码优化涉及诸多编码技巧,需要开发人员熟悉相关语言的API,并在合适的场景中正确使用相关API或类库。同时,对算法、数据结构的灵活使用,也是代码优化的重要内容。
虽然代码优化是从微观上对性能进行调整,但是一个"好"的实现和一个"坏"的实现对系统的影响也是非常大的。比如,同样作为List的实现,LinkedList和ArrayList在随机访问上的性能却可以相差几个数量级;又如,同样是文件读写的实现,使用Stream方式与Java NIO的方式,其性能可能又会相差一个数量级。
因此,虽然与设计优化相比,这里将代码优化称为在微观层面上的优化,但是它却是对系统性能产生最直接影响的优化方法。
4.4 JVM调优
由于Java软件总是运行在JVM虚拟机之上,对JVM虚拟机进行优化也能在一定程度上提升Java程序的性能。JVM调优通常可以在软件开发后期进行,如在软件开发完成,或者在软件开发的某一里程碑阶段。
作为Java软件的运行平台,JVM的各项参数将会直接影响Java程序的性能。比如,JVM的堆大小、垃圾回收策略等。要进行JVM层面的调优,需要开发人员对JVM的运行原理和基本内存结构有一定了解。如,堆内存的结构、GC的种类等。然后,依据应用程序的特点,设置合理的JVM启动参数。
4.5 网络调优
关于网络调优,尤其是TCP Tuning,这里面有很多很多东西可以说。看看Linux下TCP/IP的那么多参数就知道了。强烈建议大家看看《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 SegmentLifetime),默认为4分钟,TIME_WAIT状态下的资源不能回收。有大量的TIME_WAIT链接的情况一般是在HTTP服务器上。对此,有两个参数需要注意,
net.ipv4.tcp_tw_reuse=1
net.ipv4.tcp_tw_recycle=1
前者表示重用TIME_WAIT,后者表示回收TIME_WAIT的资源。
TCP还有一个重要的概念叫RWIN(TCPReceive 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,到了目标端又会帮你做重组,这就不需要你在程序中处理了)
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处发生阻塞,这个比较变态,要小心。这种到网上找信息的东西很多,比如,如果你的Linux使用了NIS,或是NFS,某些用户或文件相关的系统调用就很慢,所以要小心。
4.6数据库调优
对绝大部分应用系统而言,数据库是必不可少的一部分。Java程序可以使用JDBC的方式连接数据库。对数据库的调优可以分为3个部分:在应用层对SQL语句进行优化;对数据库进行优化;对数据库软件进行优化。
数据库调优是一个很大的话题,下面的这些东西并不一定正确,因为在不同的业务场景,不同的数据库设计下可能会得到完全相反的结论,所以,在这里做一些一般性的说明,具体问题还要具体分析。
A)数据库引擎调优
数据库的锁的方式。这个非常非常地重要。并发情况下,锁是非常非常影响性能的。各种隔离级别,行锁,表锁,页锁,读写锁,事务锁,以及各种写优先还是读优先机制。性能最高的是不要锁,所以,分库分表,冗余数据,减少一致性事务处理,可以有效地提高性能。NoSQL就是牺牲了一致性和事务处理,并冗余数据,从而达到了分布式和高性能。
数据库的存储机制。不但要搞清楚各种类型字段是怎么存储的,更重要的是数据库的数据存储方式,是怎么分区的,是怎么管理的,比如Oracle的数据文件,表空间,段,等等。了解清楚这个机制可以减轻很多的I/O负载。比如:MySQL下使用show engines;可以看到各种存储引擎的支持。不同的存储引擎有不同的侧重点,针对不同的业务或数据库设计会让你有不同的性能。
数据库的分布式策略。最简单的就是复制或镜像,需要了解分布式的一致性算法,或是主主同步,主从同步。通过了解这种技术的机理可以做到数据库级别的水平扩展。
B)SQL语句优化
关于SQL语句的优化,首先也是要使用工具,比如:MySQL SQL Query Analyzer,Oracle SQLPerformance Analyzer,或是微软SQL Query Analyzer,基本上来说,所有的RMDB都会有这样的工具,来让你查看你的应用中的SQL的性能问题。 还可以使用explain来看看SQL语句最终ExecutionPlan会是什么样的。
还有一点很重要,数据库的各种操作需要大量的内存,所以服务器的内存要够,优其应对那些多表查询的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。基本来说,现代的数据引擎对SQL语句优化得都挺好的,JOIN和IN/EXISTS在结果上有些不同,但性能基本上都差不多。有人说,EXISTS的性能要好于IN,IN的性能要好于JOIN,我各人觉得,这个还要看你的数据、schema和SQL语句的复杂度,对于一般的简单的情况来说,都差不多,所以千万不要使用过多的嵌套,千万不要让你的SQL太复杂,宁可使用几个简单的SQL也不要使用一个巨大无比的嵌套N级的SQL。还有人说,如果两个表的数据量差不多,Exists的性能可能会高于In,In可能会高于Join,如果这两个表一大一小,那么子查询中,Exists用大表,In则用小表。这个,我没有验证过,放在这里让大家讨论吧。
JOIN操作。有人说,Join表的顺序会影响性能,只要Join的结果集是一样,性能和join的次序无关。因为后台的数据库引擎会帮我们优化的。Join有三种实现算法,嵌套循环,排序归并,和Hash式的Join。(MySQL只支持第一种)
(1)嵌套循环,就好像是我们常见的多重嵌套循环。注意,前面的索引说过,数据库的索引查找算法用的是B-Tree,这是O(log(n))的算法,所以,整个算法复法度应该是O(log(n)) * O(log(m))这样的。
(2)Hash式的Join,主要解决嵌套循环的O(log(n))的复杂,使用一个临时的hash表来标记。
(3)排序归并,意思 是两个表按照查询字段排好序,然后再合并。当然,索引字段一般是排好序的。
部分结果集。我们知道MySQL里的Limit关键字,Oracle里的rownum,SQL Server里的Top都是在限制前几条的返回结果。这给了我们数据库引擎很多可以调优的空间。一般来说,返回top n的记录数据需要我们使用orderby,注意在这里我们需要为order by的字段建立索引。有了被建索引的order by后,会让我们的select语句的性能不会被记录数的所影响。使用这个技术,一般来说我们前台会以分页方式来显现数据,Mysql用的是OFFSET,SQL Server用的是FETCH NEXT,这种Fetch的方式其实并不好是线性复杂度,所以,如果我们能够知道order by字段的第二页的起始值,我们就可以在where语句里直接使用>=的表达式来select,这种技术叫seek,而不是fetch,seek的性能比fetch要高很多。
字符串。正如我前面所说的,字符串操作对性能上有非常大的恶梦,所以,能用数据的情况就用数字,比如:时间,工号,等。全文检索。千万不要用Like之类的东西来做全文检索,如果要玩全文检索,可以尝试使用Sphinx。
其它。
(1)不要select *,而是明确指出各个字段,如果有多个表,一定要在字段名前加上表名,不要让引擎去算。
(2)不要用Having,因为其要遍历所有的记录。性能差得不能再差。
(3)尽可能地使用UNION ALL 取代UNION。
(4)索引过多,insert和delete就会越慢。而update如果update多数索引,也会慢,但是如果只update一个,则只会影响一个索引表。