性能测试常用的性能调优的方式

性能调优是一个非常大的议题’更多的是由开发人员来进行°测试人员可以了解一些通用的调优方法’并根据性能分析过程中发现的问题’给出—些建议°当然’随着性能测试经验的积累,测试人员也会知道很多开发人员不知道的调优方法

（1）设计优化。

设计优化处于所有调优手段的上层’它往往需要在软件开发之前进行°在软件开发之初,架构师就应该评估软件可能存在的各种潜在问题, 并给出合理的设计方案.由于软件设计和架构对软件
整体质量有决定性的影响’因此设计优化对软件性能的影响也是最大的。从某种程度上说,设计优化直接决定了软件的整体品质。如果在设计层考虑不周,留下太多隐那么这些“质′’的问题’也许无法通过代码层的优化进行弥补。因此，开发人员必须在软件设初’认真仔细考虑软件系统的性能问题。进行设计优化时’设计人员必须熟悉常用的软件设计万法、设计模式、基本性能组件和常用优想，并将这些有机地集成在软件系统中。
注意个良好的软件设计可以规避很多潜在的性能问题。因此’尽可能多花些时间在系统设患计之化思计上是创建高性能程序的关键。

（2）算法优化

算法非常重要’好的算法会使系统有更好的性能°例如’分而治之和预处理的思路°某程序为
了生成月报表每次都需要计算很长的时间,有时候需要花费将近一整天的时间°于是我们找到了1种方法将这个算法改成增量式的’也就是说我们每天都把当天的数据计算好之后和前一天的报表数据合并,这样就大大节省了计算时间°调整之后’每天的数据计算时间需要大约20mm,但是如果
我—次性计算筷个月的数据’系统需要｜（）h以上（SQIˉ语句在大数据量面前性能成级数下降）。这种分而治之的思路对大数据应用的性能有很大的帮助。

（3）代码优化

代码优化是在软件开发过程中或者在软件开发完成后的软件维护过程中进行的’对程序代码的改进和优化。代码优化涉及诸多编码技巧’需要开发人员熟悉朴｜关语言的API,并在合适的场景中正确使附相关API或类库°｜司时,对算法、数据结构的灵活使用’也是实现代码优化的必备技能。
虽然代码优化是从微观上对性能进行调整’但是1个好的实现和—个“坏’’的实现对系统影响的差异也是非常大的。例如 同样作为Llst的实现’LinkList和ArrayList在随机访问上的性能可以相差几个数量级;同样是文件读写的实现’使用Stream万式与JavaNIO方式’其性能可能又
会相差—个数量级。因此虽然与设计优化相比,这里将代码优化称为在微观层面上的优化’但是它却是对系统性能产生最直接影响的调优方法.
（4）JVM优化
由于Java程序总是运行在JVM之上’因此对JVM进行优化也能在—定程度上提升Java程序的性能。JVM优化通常可以在软件开发后期进行’如在软件开发完成时或者在软件开发的某一里程碑阶段。
作为Java程序的运行平台’JVM的各项参数将会百接影响Java程序的性能例如JVM的堆大小和GC策略等。要进行JVM层面的优化,需要开发人员对ⅣM的运行原理和基本内存结构有—定的了解,如堆的结构和GC的种类等°进而’依据应用程序的特点,设置合理的JVM启动参数。

（5）参数优化

中间件参数。互联网产品的系统架构总是会涉及各种中间件’常见的有Ngjnx、ZooKeeper、Tomcat、Redjs、RabbltMQ等°这些组件和性能息息相关的参数的默认值有时候是不满足要求的，因此需要优化。系统参数。Linux系统本身的一些连接数、网络、读写内存分配大小的参数。

（6）数据库优化

对绝大部分应用系统而言’数据库是必不可少的—部分°Java程序可以使用JDBC的方式连接数据库°对数据库的优化，可以分为3个部分:在应附层对SQL语句进行优化、对数据库进行优化和对数据库软件进行优化。
数据库优化是＿个很人的话题下面是作者总结的一些经验。
数据库引擎调优。数据库的锁的万式非常的里要’因为在并发情况下，锁是非常影响性能的。它包括各种隅离级别’行锁、表锁、页锁、读写锁、事务锁’以及各种写优先和读优先机制。要想达到最高的性能最好是不要锁’所以’分库分表、冗余数据、减少—致性事务处理,可以有效地提高性能°NoSQL就是牺牲了—致性事务处理,并冗余数据从而达到了分布式和
高性能。数据库的存储机制°不但耍搞清楚各种类型字段是怎么存储的’更重要的足了解数据库的数据存储万式’即它是怎么分区、怎么管理的°了解滔楚这个机制叮以减轻很多的IO负载°例如’在MySQL下使用showcngines’可以看至｜｜各种存储引擎的支持°不｜司的存储弓｜擎有不同的侧重点’针对不同的业务或数据库设计会有不问的性能。数据库的分布式策略。最简单的就是复制或镜像’需要了解分布式的一致性算法’或是主主同步、主从同步°通过了解这种技术的机理可以做到数据库级别的水平扩展°SQL涪句优化°关于SQL语句的优化’首先是要使用工具例如MySQL的SQLQuclyAnalyzer可以用于查看应用中的SQL的性能问题’还可以使用explaln来查看SQL语句最终的ExecutjonPlan是什么样的°
还有一点很重要’数据库的各种操作需要大量的内存’所以服务器的内存要够’尤其应对那些多表查询的SQL语句’是相当耗内存的。·全表检索°例如SELECT＊FROMuserWHERElastname＝“xxxx’,’这样的SQL语句基本上是全表查找’线性复杂度O（〃）越高、记录数越多’性能也越差（如查找100条记录要50ms,而查找＿百万条记录需要5mln）。对于这种情况’我们可以有两种方法来提高性能:—种方法是分表’把记录数降下来;另一种方法是建索弓｜（为lastname建索弓｜）°索引就像是键值
对的数据结构＿样’键就是WHERE后面的字段’值就是物理行号’对索引的搜索复杂度基本上是O（log（′!））—用BˉTree实现索弓｜（如查找l00条记录要50ms,而查找—百万条记录需要l00ms）。索引。对于索引字段’最好不要在字段上做计算、类型转换、函数调用、空值判断和字段连
接等操作’这些操作都会破坏索引原本的性能。当然’索引＿般都出现在WHERE或是ORDERBY子句中’所以在WHERE和ORDERBγ子句中的字段上最好不要进行计算操作’或是加上NOT之类的关键字’或是使用函数。· 多表查询·对关系型数据库做的最多的操作就是多表查询’多表查询主要有3个关键字’EⅪSTS、IN和JOIN°基本上’现代的数据库引擎对SQL语句优化得都挺好的’这3个关键字的运用在结果上有些不同’但在性能上基本都差不多°有人说’EXISTS的性能要好于IN’IN的性能要好于JOIN°作者个人觉得’这个还要看数据、模式和SQL语句的复杂度的情况°对＿
般的简单的情况来说性能都差不多,所以千万不要使用过多的嵌套,千万不要让SQL语句太复杂。宁可使用几个简单的SQL语句也不要使用—个巨大无比的嵌套Ⅳ级的SQL语句。还有人说,如果两个表的数据量差不多’EXlSTS的性能可能会高于IN’IN可能会高于JOlN。以作者的经验来看’如果这两个表-大—小’那么子查询中’EXISTS用于大表’IN则用于小表。 JOIN操作。有人说’JOIN表的）｜｜顶序会影响性能°实际上只要JOIN的结果集是＿样的’性能和JOIN表的）｜顶序无关,因为后台的数据库引擎会帮我们优化的。JOIN有3种实现算法’嵌套循环、Hash式的JOIN和排序归并（MySQL只支持第一种）°嵌套循环与我们常见的
多重嵌套循环基本—样。注意,前面的索′J｜部分说过’数据库的索引查找算法用的是BˉTree°这是O（log（′j））的算法’所以整个算法复杂度应该是O（log（″））＊O（log（′′′））。Hash式的JOlN’ 主要解决嵌套循环的O（log（′!））复杂度的问题’使用一个临时的hash表来标记°
排序归并,意思是两个表按照查询字段排好序’然后再合并°当然’索引字段一般是排好序的.·部分结果集°我们知道MySQlˉ里的L［MIT关键字、Oracle里的ROWNUM、SQLServer里的TOP都是在限制前几条的返回结果°这给」′我们很多对数据库弓｜擎调优的空间·一般
米说,返回前″条的｜已录数据需要我们使用ORl〕ERBY』注怠任这里找们需要为ORDERBY的字段建立索引。有了索引后’会｝｜:我们的SELECT语句的性能个会被记录数所影响.字符串°如前文所述’字符串操作对性能的影‖问很大,所以,能用数字的情况下就用数
宇’例如用时间和工号等.·全文检索。千万不要用LIKE之类的关键字来做全文检索’如果要做全文检索’可以尝试使用Sphinx.
其他—些建议°不要用SELECT＊’而是要明确指出各个字段:如果有多个表’一定要在宇段名前加k表名’不要让数据库弓｜擎去算。不要用∏AVING’因为其要遍历所有的记录’性能差得不能再差.尽可能地使用UNIONALL取代UNlON。索引过多’INSERT和DELETE就会变慢°而如果UPDAIE多数索弓｜,速度也会变慢;但是如果只UPDATE—个索弓｜’则只会影响—个索弓｜表。以上是性能｜〕‖题的定位分析的所有内容’知识点比较多,大家需要好好消化吸收,并在实战中多应用实践°另外在此引入—个分析问题的方法论,套用5W2∏方法’可以提出性能分析的几
个问题。
Who:发生了什么现象?
What:现象是什么样的?
When:什么时候发生?
Why:为（｜ˉ么会发生?
Where:哪个地方发生的问题?
Howmuch:耗费了多少资源?
Howtodo:怎么解决问题?
提示
面对流量洪峰的策咯如下。
（ l ）服务降级°服务降级是指在特定情况下,例如“双十一’,‘‘双十二’’期间’ 当流量超过系统服务能力时’跳过特定的处理流程。比如在一个买家下单后’我们可能需要迸行风险评估、数据校验等一系列流程’当发生服务降级时’就跳过了数据校验逻辑, 以避免用户长时间等待’降低对下游链路的冲击’保证服务的稳定性°服务降级是面对流量洪峰保证用户体验和预防系统崩溃的有效于段。
（2）服务限流。服务限流是指根据服务的处理能力提前预估一个闽值, 当流量大于该｜刻值时放弃处理直接返回错误°服务限流是应对流量达到峰值时, 系统进行自我保护的重妥措施。例如“双十一’零点下单峰值、余额宝九点抢购峰值以及活动结束商品信息编辑峰值,都需要进行相应的限
流来保护系统°
（3）故障容灾°单机系统的容灾能力几乎为零,一旦服务崩溃就马上变成不可用°分布式系统通过并地多活’可以不间断地提供服务.同时,借助于Nginx、Apache进行负载均衡可以进一步提
高可用性.
实际上,即便进行了负载均衡和服务分布式部署’系统仍然面｜｜岳容灾问题°现在的大型服务’例如淘宝、天猫、微信｀京东都进行了异地多活的部署°并地多活部署的主妥目的是’通过多机房提供服务来降低单机房故障带来的影,向提高容灾能力。