上周六是我们TestOps性能进阶课程第六天——性能瓶颈与分析的学习。这一天的课程依旧是干货满满，云层老师从构建性能测试分析思路、性能瓶颈定位、常见性能分析模型、性能调优方案、性能测试报告等几个方面进行讲解。这里芒果一如既往的抽出其中一部分内容跟大家介绍~
第一个芒果要给大家分享的是云层老师用通俗易懂的例子，带我们一起分析案例，并设计调优方案。我们在对性能做调优方案的最关键的一步就是构建分析思路，在这构建分析的过程中，我们需要注意到以下三点：第一，分析是基于已知事务进行的；第二，使用已知知识对事务进行揣摩；第三，给出自己的理解。分析的前提是了解，当有了好的分析，调优方案自然就慢慢凸显了。在课堂上云层老师以从家到公司上班的路程为例（案例1）讲解了如何进行分析，如何进行调优：我们首先应该列出完整事务的多个步骤，并列出分别的资源消耗跟时间，对于案例1而已，我们可以拆分为以下几步，对应的时间消耗为：
如何优化呢？
第一，我们可以选用最易调优法（找最容易解决问题的方法来执行）。针对案例1，我们可针对从到公交站（A）不选择步行，采用跑步或者是骑车的方式进行，等公交的过程（B）使用“车来了”之类APP减少等车时间，公交到达站到公司（D）也选用跑步或者骑车的方式而非之前的走。而对于我们的软件系统优化来说，最熟悉最容易的调优方式就是资源问题了，发现CPU使用率太高就升级CPU，发现内存不够用就加内存等方式。
第二，我们可以选用影响最大调优法（什么最浪费时间，调优什么）。针对案例1，我们可以看出时间最长为公交车从出发站到到达站，我们可以由公交车改乘地铁或者打车出行，具体如下图，可以优化约20分钟时间。而对于我们的软件系统优化而言，当我们发现某个模块占用时间最长时，我们就要考虑对这个模块进行修改，有时候就是调整/更换架构了。但是更改架构也是一般比较难做到的。
第三，综合调优法（根据各个方面进行综合调优），针对案例1，我们可以把从家到地铁站的方式改为骑车，而非乘坐公交车，再乘地铁到达公司，这样能大大的节约时间。而针对我们的软件系统则是平衡考虑ROI（投资回报率），在配置参数调整、增加资源、改变架构等方面进行平衡调优。
第二个芒果要给大家分享的就是手工探针。我们在使用Loadrunner、Jmeter等性能工具时，这些工具可以提供各种性能监控，其实我们自己手工也可以做到，这就是手工探针。比如我们可以发现很多web页面的底部有执行时间，这个时间是我们的请求发给后台，后台开始计时，处理完毕发回给前台，数据进入APP到出APP的时间差（ptime）。我们可以使用lr_user_data_point来获取这个值，以获取负载的时候的响应时间，如果ptime与响应时间变化趋势类似时，我们可以判定性能瓶颈是在于后台的；如果ptime曲线与响应时间曲线垂直距离较远时，可以判定，带宽也可能是影响系统性能的原因。如果判定性能瓶颈是出于后台的，我们可以再让开发提供更细致的响应时间数据，以帮助判断瓶颈是出于数据库还是APP。从绝对大多数系统来说最容易出性能问题是数据库，而解决数据库性能瓶颈最好的处理方式就是提升IO；如果不是IO问题，我们可以考虑读写分离，使用Redis等方式；再考虑SQL优化问题。
第三个芒果要跟大家分享的是性能调优的四大层次。对于系统的性能分析调优可以分为以下四个层次：第一，通过性能测试找到性能测试结果最好的版本（结果最好不代表用户最需要，性能测试结果最好的未必是系统用户要的最好的）。第二，通过性能测试找到各个版本的优缺点和瓶颈（应该有多次性能测试，通过多次去评估各个版本的特点，给用户最需要的版本。实际情况是用户在线2w，我拿5w的设计去套，未必合理）。第三，通过性能测试整合各个版本的优点，最终得到包含所有优点的版本(整合优点)。第四，通过各个阶段的调试，获得预估的最好的版本，反复调优接近该目标（理论最优值）。其实一般情况下我们能够做到第二点就已经很好了。
在课堂上云层老师还花了很多心思跟时间给大家介绍了理发师模型，根据理发师模型变换引申出的其他响应时间、TPS图，然后根据理发师模型进行调优等，因为篇幅原因就不在这里给大家介绍，希望同学们在看录播视频复习的时候，仔细注意这一段哟~
在介绍完性能调优之后，云层老师还以自己编写的性能测试报告为例带大家学习了性能测试报告的编写；性能测试的整个执行流程；TestOps下的性能测试应该如何执行；如何应对性能测试的面试等等等知识点，这里芒果就不一一给大家介绍了，希望同学们能在课堂上跟着云层老师一起好好学习哟~
