【Spark】性能测试以及调优思路
背景
本文站在开发视角，如何在整个测试过程中引导，协助测试进行性能测试。
测试前
指的是在测试过程前，开发和测试要对齐的一些事情，要提前做的一些准备。
- 如果有对比的产品/功能。比如升级前后对比。割接前后对比。与竞品对比。可以要求测试进行一次基准测试，作为性能进行比较。
- 基准测试具体要测什么，开发要站在测本次新功能/产品来考虑，找到共同可比较的点，对相应的关键数据，截图进行保存。方便对比。
- 端到端的workload（工作负载、工况）。我这个产品在xx时间内，在xx资源下，能够处理xx数据。比如每小时在256G内存，56vcore中可以处理130MB/s的数据。（注意：对比测试尽可能用同样的规格和数据进行计算处理，因为数据规模和资源规格不一定成线性变化，尽可能还是完全一样去测试，对比更有说服力）
- 具体环节的workload。把端到端流程打开来看，大致可以分成几个环节，每个环节对应的耗时是多少，做的是什么事情（这点很重要，方便后面性能优化时对比分析优/劣化点，分得越细，越容易进行对比）
- 如果时间充裕，可以大中小规格都测一遍，方便看在不同workload下性能变化效果。
- 如果资源充裕，可以保留老环境，方便对比分析性能问题瓶颈。
PS. 性能测试一定是有对比的，无论是横向比还是纵向比。有对比才能证明自己的产品功能的优秀，才能在领导，客户那里体现商业价值。而不是自说自话，是想办法自己工作能力，产品好在哪的一个重要途径。
测试中
测试过程中，包括如果没有达标要分析，修改，继续测试。是一个螺旋上升的过程。
- 测试按照测试前对齐的测试手法进行测试，并留存关键数据和截图。
- 如果发现性能没有达标/需要优化。可以按照以下流程来排查优化：
- 检查资源是否充分利用，比如Spark的executor，内存vcore是否跑满，是否充分利用了服务器资源。具体调整参数可以看我这一篇博客：【Spark性能调优】Spark Application启动资源规格调优
- 任务是否有运行失败的，如果有失败的
- 测试达标后，要求测试同样出一份测试报告，可以作为下次性能测试的输入/测试基线。也可以作为发邮件证明性能优异的一份材料。
3. 找耗时长的Job/Stage，通过DAG图看该操作在做什么，这个操作必做不可吗？可以如何优化业务逻辑。
4. 如果分析不出来。可以通过arthas取driver进程的火焰图/JFR。分析热点方法和耗时。是否有不必要的操作，比如打印无用日志。比如UDF耗时长，看看是否可以优化UDF实现。
5. 和测试再次确认测试方法，
1. 比如workload和之前约定的是否一致？有没有私自调整，如果调整了评估一下调整是否合理。
2. 数据量是不是不够大，预热时间太长，调大数据量或者去掉预热时间再次统计。
测试后
形成测试报告
- 首先需要说明workload，对比后性能是原来的百分之多少。
- 如果能够打开具体阶段进行对比，说明具体哪些阶段分别是原来的百分之多少。
- 以上对比最好有表格（方便下次用原始统计数据计算其他指标）有折线图（直观，一目了然）
AAR
- 和各方人员一起讨论&回忆测试过程中有哪些优缺点，优点要保留，缺点要改正。预期是什么，为什么没达成预期，下次怎样改进可以尽快达成预期。这次的经验如何可以传递给下次类似的性能测试。