性能测试-小项目性能测试准备工作和问题分析（一）

本周产品线内一个中小型项目临时提出性能测试需求，根据相关业务需要，我们对内网、外网核心业务接口进行了压测，主要问题和解决办法记录一下，以便后续的项目避免重复踩坑。

第一部分：测试之前我们需要了解的那些事

为了减少信息了解局限而导致的无效测试，需要提前对以下方面进行了解：

1. 测试目标：外部需要or公司内部需要
2. 测试环境准备&测试数据：是否用户真实线上环境，一般而言线上环境的网络、数据更加真实，更有说服力，但是需要考虑数据构造、压测对用户使用是否会产生影响，产生的数据是否可以清理
3. 测试范围：结合测试目标，确定测试范围。常见情况如：
   1. 如果项目组需要向客户提供性能测试报告：这种情况下，需要考虑测试环境，一般而言，用户希望看到的报告是基于实际环境给出的分析，因而需要在线上进行性能测试，数据和指标可以结合系统中收集到的数据以及根据历史数据进行评估。
   2. 如果内部系统需要优化，需要了解是否是对全系统优化，还是只针对部分模块优化，优化是否有明确的方向，比如链路优化、数据库优化、服务优化等，根据不同的优化目标，确定测试范围。
4. 测试地点：部分程序部署在客户内网，需要考虑在用户现场本地进行测试，需要提前了解：现场网络情况、安全要求、且与客户沟通确认得到允许，并预留出单独时间进行。建议内网测试工作提前进行，以应对现场可能遇到的临时问题。
5. 测试指标：需要与项目组的产品、开发、市场等人员基于对项目的业务情况了解或者项目文档中明确的指标安全，共同确定并发数量、响应时间、错误率、吞吐量等指标，作为性能测试的测试指标。
6. 工具要求：jmeter作为开源工具近2年在业内使用广泛，但是对于一些项目，客户如果有明确指定的工具要求的话，我们需按照工具要求进行相关准备，避免进行无效测试。

第二部分：测试过程中遇到的问题和解决方案

1、错误率高【解决办法：修改http相互调用方式】

报错主要是网络方面的错误，开发排查后，对http之间相互调用方式进行了调整，解决了一部分问题

2、返回时长长【解决办法：链路优化+服务调优】

问题排查和处理过程主要为下面几步：

step1：nginx链路配置优化，优化后部分接口仍然返回时长在1分钟左右，且并发100存在10%左右的报错

step2：排查是否是内外网链路影响

为了排查是否是链路问题影响，对同一接口通过修改不同配置，走内网和走全链路进行对比，发现时长是一样的，说明不是网络损耗的问题。

step3：排查是否是接口返回包大小的影响

对比2个返回时长相差很大的接口，比对它们返回内容的大小，差别10倍，修改其中一个接口返回数据的条数，使它们的返回大小保持基本一致，然后在同一网络条件下进行对比压测，压测结果发现当包大小一致时，它们的返回时长基本一致，因此不是单个接口内部处理逻辑的问题。下一步的优化方向：在返回包比较大情况下，优化公共处理逻辑，缩短处理时间，目前还没有找到可行的解决方案

3、ES查询优化

通过和开发同学了解，ES存储方式由于已经针对文本进行了处理，查询方面的优化空间不大