性能调优是一个非常大的议题，更多的是开发人员进行，对于测试人员，可以了解一些通用的调优方法，并根据性能分析过程中发现的问题，给出一些建议。
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一个，则只会影响一个索引表。