1、背景

开放平台新对接并对外提供智能认证的服务，服务提供方应该提供的相关的性能能力，但由于涉及到开放平台接入方服务器对外的能力及本身通道处理能力，我们仍需得出开放平台本身对于智能认证服务的性能能力。

2、方案分析

由于智能核身接口的特殊性，每个接口基本都包含图片的上传，且是将图片base64编码后和接口请求同步上传，每通过分析，至少要支持每张图片500K左右。因为目前手机摄像头像素都比较高，拍照质量也越来越高，导致手机端图片变大，摄像头随意拍摄一张图片2-3M左右，甚至更大。所以前端在取到图片数据后直接做有损压缩，压缩标准可以可采用标准的jpeg有损压缩方案，压缩比可以根据需要设置，通过处理一张图片可以压缩至200K左右（也可以更小，但不能质量损失太多，影响后面的识别），再通过标准的base64编码处理后传到后端。这样前端用户上传所需时间也降低为1/10，显著提高用户体验。

虽然前端已对图片做了基本的压缩处理，但实际在性能测试过程中，大量的并发数据和请求数都会给执行机服务器和网络带宽带来大量的压力。所以要解决两个问题：

1、压测执行机本身的性能能力。

解决方案：申请服务器作为测试执行机，通过执行机下发集群任务的方式达到真正有效并发下发，解决本身性能任颈。

2、网络带宽要求。比如一个请求含两个200K图片，基本的带宽需满足400*吞时量。比如1G的上下行网络带宽可以承受多少并发？粗略计算。1Gbps/8bit=125MB，125MB*1024/400K=320，可以满足320TPS数。所以如果带宽达到1G可以解决网络本上的上行请求限制。

解决方案：通过执行机直接需测试服务器（路由映射），通过内网直连服务器，解决网络限制问题。

3、测试方案架构图

 

测试方案架构图

 

4、实施过程

4.1 实施策略

1、对相关接口展开单交易并发测试，获得单交易并发支持能力

2、获取相关接口的处理能力

3、获取相关接口的平均响应时间

4.2 测试类型-单交易并发测试

本次使用apacher 的开源测试工具jmeter，采用本地动态拼装请求数据并通过http协议post方式发起请求，持续增加并发用户量，并发用户数及变更幅度根据测试过程中的实际情况进行调整。通过聚合报告、每秒响应分布图、响应时间分析系统性能情况。

由于敏感性，暂不贴出测试数据。

5、问题分析

在各单交易接口测试过程中发现，当并发量上升，响应时间明显增加，CPU占用飙升，且部分接口达到一定并发数，错误率上升，请求数无法增加，甚至服务异常情况。

请求的接口数据含两张图片，或者使用更大图片时，测试数据比对明显性能能力更弱，甚至测试结果达不到基准要求最低标准。

综合以上评估，问题的根本原因在于对大数据的处理方式。

6、改进方案

通过对以上问题的分析，提出的两种整改方案：

1、分析发现服务器的数据处理使用的是流式处理模式。使用流式处理，过来的大量数据会占用服务器网卡资源和缓存资源，当并发的数据加大，过来的请求太多，会导致内存不足，内存不足就会溢出，就会造成数据丢失，请求过去超时没有响应或者服务器处理任务失败，造成服务器异常。如果使用spring原始方法接口，基于硬盘的存储模式处理，则是拿硬盘做过度缓存，数据进来，如果量比较大或者暂时处理不过来，则先放硬盘保存，则不会造成CPU异常飙升等异常情况。但是这种方式处理效率低，响应速度慢慢。而结合我们的业务场景，智能认证相关需求具备较高的实时性和高效率，处理方案则是对应生产环境高性能多台服务器集群，提高配置，同时保证网络带宽。

2、对于图片上传接口另外剥离，接口请求和图片分开请求。将图片放在接口报文里按String请求处理。这种方案还是采用的存储模式，且涉及到服务方架构变更，比较难以撼动。不予建议。