性能优化概要
性能测试的含义：
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试，负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试
周期：1.项目启动是关注点：性能需求是否明确、合理、可测，2.关注系统架构的设计，设计中是否很好的考虑了性能需求。3.性能测试之后关注性能调优，产品上线后进一步监控系统性能的实际表现。4.根据开发性能调优后或者产品上线后的日志分析，开始新的循环，5.性能就是在不断测试，分析，调优，监控的过程中持续优化。
常见性能问题：
1.资源泄露（内存泄露。系统占用的资源（内存，cpu）随着运行时间的不断增长，而降低了系统性能。系统响应越来越慢，甚至系统出现混乱。只有重启系统才能恢复到最初水平。这类问题的产生主要原因是有些对象（如GDI使用，JDBC连接）没有及时被销毁，内存没有释放干净，缓冲区没有回收）
2.资源瓶颈（内部资源（线程，放入池的对象）变得稀缺。随着负载增加，系统越来越慢甚至系统挂起或出现异常错误。这类问题产生的主要原因是线程过度使用或资源分配不足）
3.Cpu使用率达到100%，系统被锁定（代码中可能存在无限循环，缺乏保护（如对失败请求不断的重试）等问题，对网络应用系统，问题常常出现在数据库的服务器上，如频繁对数据库存取，未使用连接池或连接池配置参数不当，单个sql请求的数据量过多，没有使用高速缓存等）
4.线程死锁，线程阻塞（造成系统越来越慢，甚至系统挂起或出现异常错误，系统混乱局面等。这可能是由程序对事务并发处理上的错误，资源争用引起锁阻塞和死锁等引起的，例如线程获得顺序的算法不对而造成死锁，线程同步点上备份过多而造成通信阻塞等）
5.查询速度慢或列表效率低（主要原因是列表查询未使用索引，过于复杂的sql语句，分页算法效率低等；也可能是查询结果集过大或不规范的查询，如查询全部字段而不是所需字段，返回全部的数据等）
6.受外部系统影响越来越大（最终造成应用系统越来越慢。主要原因有向后端系统发出太多请求，页面内容过多，经第三方系统认证比较复杂，网络连接不稳定或延迟等）
性能测试目标：
1.获取系统性能指标，作为性能指标的基准（性能基准测试）
2.验证系统性能指标是否达到要求（性能验证测试）
3.发现系统的性能瓶颈，内存泄露等问题（渗入测试，峰谷测试）
4.系统正常工作情况下的最大容量（容量测试）
5.帮助系统运维部门更好地规划硬件配置（系统性能规划测试）
6. 验证系统是否具有良好的可伸缩性
可伸缩指一是功能的可扩展性，主要是针对平台框架，是否设计并预留了足够的扩展点，后续可以很方便的增加各种功能或有第三方实现各种插件。另一种是性能的可扩展性，系统的弹性扩容能力，即随着系统用户量、并发的增加是否可实现弹性扩容，通过增加硬件设备就能提供更强的处理能力
7. 借助大负载，极限负载，完成系统稳定性测试（压力测试）
从哪些方面去定义性能指标：
2.最终的用户体验（用户需要系统的响应时间，不同的响应时间决定用户的体验好不好，例：2s（感觉系统速度非常快），2s-5s（还不错），5s-10s（速度慢，但是还可以接受），10s以后（感觉不好，不能接受））
2.商业需求（软件产品的性能“比竞争对手的产品好，至少不比它差”从这个需求出发，了解对手产品的处理能力，等待时间，响应速度，容量，从而定义自己产品的相应性能指标预期值。如果从经济成本考虑，性能只要比竞品高10%-30%就可以，不用高太多如50%以上，除非对手竞品性能很差）
3.技术需求（从技术角度看系统性能，如当服务器CPU使用率达到80%时，客户端的请求就不能及时处理，需要排队等待，自然会影响用户的体验。所以，从技术角度看，需要定义一个性能指标，级CPU使用率不超过70%）
4.标准要求（国家标准或行业标准定义了某些类别的软件的性能指标，相应的软件须遵守这些标准）
从哪些点去确定数据项的值
1.时间（客户端连接时间，系统响应时间，单笔业务处理时间，页面下载时间）
2.容量（系统正常工作是能承受的最大负载，访问系统的最大并发在线用户数，数据库系统中最大记录数，一个远程会议系统可以接受的最多与会人数等，重点强调正常工作时的负载量，不是指在无法正常运行或运行速度低于客户预期时的最大负载，那种情况下最大负载是没有多大意义）
3.数据吞吐量（系统单位时间内处理的数据量，如每秒处理的请求数，每分钟打开的页面数，每秒传递的数据包量）
4.系统资源占用率（如内存占用必须少于50M，CPU不能超过70%等）
1、支持用户数最大容量，最大并发数（容量的1%），2、常用时间的数据吞吐量折算成每秒，高峰期数据吞吐量x3，3、响应时间体验好，高峰期响应时间也在用户可接受范围内，4、成功率100%，高峰期成功率也不低于99.9%。
所给予系统的负载被定义为并发用户数
并发用户数=并发连接数+请求数据量+思考时间
并发连接数（虚拟用户数）
请求数据量（客户端向服务器发送的数据包）请求数据量越大，系统测试负载越大即服务器压力
思考时间（用户的操作时间，老人和年轻人操作所需要的时间不同，1s发出一个请求跟10s发出一个请求，给予系统负载程度不同）
使用jmeter进行模拟一定数量用户加载给予系统负载达成不同的测试目的
1.一次加载（一次性加载某个数量的用户，在预定时间段内持续运行。特定时间段大量用户访问网站的时间集中，属于扁平负载模式。获取某种确定负载下的性能指标数据，一般也用这种加载模式）
2.递增，递减加载（用户有规律的逐渐增加，每秒或几秒增加一些新用户，交错上升，这种方法被称为ramp-up模式，容量测试，破坏性压力测试（发现性能拐点，确定负载极限）中选择此模式）
3.高低突变加载（某个时间用户数很大，突然降低，过段时间突然加高，往复多次容易发现资源释放，内存泄露等问题，属于压力测试中的峰谷测试）
4.随机加载方式（由随机算法自动生成某个数量范围内变化的，动态的负载，属于与实际情况最接近的负载方式，虽然不容易模拟系统运行出现的瞬时高峰期，但可以模拟处在比较长时间的高位运行过程）
Micro focus silk performer中具有6中加载模式（一次加载，递增递减）
1.动态模式（在预设最大用户数情况下，随时可以手动改变用户数量，测试不同的负载水平，比较灵活）
2.全天模式（测试的任何时间指定不同数量的虚拟用户，且每个用户类型有着不同的负载分布，类似随机加载模式，这是最灵活的方式，支持复杂的长时间运行的测试场景，更贴近实际情况）
3.队列模式（分析事务活动的时间，以平均时间为基础，按照指定的到达率调度相关负载。服务器之间的负载测试可以采用这种模式）
4.验证模式（回归测试中，运行单个用户，进行功能组合的验证测试）
性能测试模式可根据业务模式变化，时间段变化来进行不同的设置，如分别为登录，搜索，订单提交，支付设计不同的负载模式，也可以在长时间的压力测试中，不同时段采用多种模式如先用递增加载模式，在采取随机加载，最后高低突变等等。
同步点：用设置同步点（集合点）的方法来准确的控制加载，以达到更理想的负载模拟效果
LoadRunner软件的三种设置同步点的选项
- 按所有虚拟用户的百分比
- 按所有正在运行的虚拟用户的百分比（最常用）
- 绝对数
服务器端操作系统命令监视Web服务器，应用服务器和数据库服务器的运行状态，收集有关数据
Linux系统下
Top、htop：系统进程监控
Vmstat：虚拟内存监控
Tcpdump：网络数据包分析
Netstat：监控网络数据包的传入和传出的统计
命令还不够方便，可以借助一些轻量级工具获得Linux的系统资源使用、网络传输等全面的信息，自动收集、存储下来，如Tecmint Monit、Monitorix、Collectl、Nmon等。还有一些命令、工具是专门服务Java应用的，具体如下：
Jstat（Java Virtual Machine statistics montioring tool）：可以监控Java类加载行为、进程GC回收等信息
JConsole：监控Java内存、CPU使用率、线程执行情况等
JMap：监控Java程序是否有内存泄漏，配合MemoryAnalyzer来使用
JProfiler：全面监控每个节点的CPU使用率、内存使用率、响应时间累计值、线程执行情况等，需要在JVM参数中进行配置
C/C++ 借助（Valgrind、Vmmap、Application Verifer）等工具来检测内存是否泄露
性能测试执行中，全程实时监控和详细的日志记录是十分重要的。性能测试过程，往往是一个不断调试的过程。由于刚开始设定的负载量、持续时间、间隔时间甚至加载方式等不一定合理，有时需要几个往复，不断调整这些输入参数，如增加虚拟用户、缩短启动的时间等。
性能拐点
1、X轴代表并发用户数，Y轴代表资源利用率、吞吐量、响应时间。X轴与Y轴区域从左往右分别是轻压力区、重压力区、拐点区。
2、随着并发用户数的增加，在轻压力区的响应时间变化不大，比较平缓，进入重压力区后呈现增长的趋势，最后进入拐点区后倾斜率增大，响应时间急剧增加。
3、随着并发用户数的增加，吞吐量增加，进入重压力区后逐步平稳，到达拐点区后急剧下降，说明系统已经达到了处理极限，有点扛不住。资源利用率逐步上升，最后达到饱和状态。
4、随着并发用户数增加，吞吐量与资源利用率增加，说明系统在积极处理，所以响应时间增加得并不明显，处于比较好的状态，但是随着并发用户数的持续增加，压力也在持续加大，吞吐量与资源利用率都达到了饱和，随后吞吐量急剧下降，造成响应时间急剧增长。轻压力区和重压力区的交界点是系统的最佳并发用户数，因为各种资源都利用的充分，响应也很快；而重压力区与拐点区的交界点就是系统的最大并发用户数，因为超过这个点，系统性能将会急剧下降甚至崩溃。
在负载接近极限的情况下，不仅响应时间急剧增大，而且事务处理的错误率越来越高。如出现服务器失败或超时错误。造成这些问题的原因可能如下：
1 . 系统资源使用率很高，如长时间CPU使用率在100%，从而导致请求操作超时
2.因为连接过多，服务器端口太忙，不能及时提供服务器数据包的传输
3.当前页面数据流太大，可能是因为页面内容多、还是数据库存取太频繁？
4.客户端连接请求被服务器拒绝，可能因为服务器的一些参数设置不合适？
分析负载测试中系统容易出现瓶颈的地方，从而有目的地调整测试策略或测试环境，使压力测试结果真实地反映出软件的性能。如服务器的硬件限制、数据库的访问性能设置等常常会成为制约软件性能的重要因素。对于Web服务器的测试，可以重点分析3项参数：
1.页面性能报告显示每个页面的平均响应时间
2.响应时间总结报告显示所有页面和页面元素的平均响应时间在测试运行过程中的变化情况
3.响应时间详细报告则详细显示每个页面的响应在测试运行过程中的变化情况
总结
性能测试结果分析和评估之后，并不代表性能测试结束。针对性能测试过程中发现的问题，需要进行优化，然后在进行测试。如果优化的是某个特定组件，可以在调优之前先针对这个组件进行性能测试（单元性能测试），记载相关数据（如资源使用效率、运行时间等），然后再优化，再进行组件性能测试，和之前的数据进行比较，是否有改进。只有得到改善，才构建新的版本，再进行系统的性能测试，直到符合性能要求。
上线以后，还可以借助监控工具，监控系统性能的实际表现数据，真实数据比性能测试的结果更有价值。但如果不在研发环境下进行性能测试就直接上线，可能会导致严重后果。还有一种观点是，当我们开发一个新系统，其实刚上线时它的用户还很少，没必要进行性能测试（这时价值不大），而且用户是慢慢增加起来的，所以可以通过在线的性能测试（监控），及时发现问题，及时优化。这种观点可以让软件公司节省一大笔开支，不需要搭建性能测试环境，再考虑灰度发布。这种观点是正确的，只有对那些非知名的互联网产品，观点是正确的。以下情况，观点不成立：
- 知名的互联网企业，上线一个产品，其用户迅速增长起来
- 如果系统不是部署在自己的数据中心，而是部署到用户环境下
- 如果开发人员能力弱，系统的基本性能都得不到保证
概括起来，性能测试也是全程的，覆盖整个生命周期的如下图：
|
需求与计划 |
静态测试 |
研发环境动态的性能测试 |
在线测试 |
|
|
定位问题并调优 新的需求及其建模 持续测试 脚本开发执行监控 业务场景负载设计 |
容量规划 性能监控 持续测试 性能优化 健康检查 |
腾讯有perfdog、网易有Airperf、字节有Gameperf、华为有System Profiler
三个目的：1、让玩家有更好的游戏体验，提高游戏的流畅度跟稳定性，2、游戏画质得到更好的提升，3、提供配置参考，优化性能覆盖更多机型
