一次业务接口性能评估的总结

一次业务接口性能评估的总结本篇文章是我在项目中对一个业务接口做性能评估时对一些问题的思考和相关知识点系统性回顾拾遗的一个总结。业务背景我们项目中的一个文件上传接口主要业务功能是接收第三方渠道端上传的base64编码影像文件和相关业务数据用户的业务属性数据入库影像文件的base64编码数据通过调下游服务中台服务最终上传至影像平台。外部一直以来对该接口上传的影像文件都有1MB的大小限制但近期发现由于存在该限制阻拦了很多用户的请求为避免客损需要放宽文件大小的规则限制至5MB那么是否会对该服务的可用性产生影响在不影响存量业务和服务可用性的情况下该接口能够支持多少的并发数和多大的文件大小限制对接口现状的思考为什么使用base64传输在此之前要先弄清一个问题为什么要通过接口来传输影像的base64而不是通过文件服务器或文件流的方式传输文件服务器传输需要异步定时从文件服务器拉取影像无法做到实时同步响应。且将影像文件通过base64编码传输可以作为application/json类型接口请求体的一个业务字段随其他业务字段一起传输更加方便灵活虽然增加了一定的接口报文的数据容量但是在一些业务的便利性上还是普遍采用的。报文长度是否有限制base64编码后的数据容量大约是原数据容量的1.3倍post接口是否能容纳这么长的报文长度呢这里衍生两个问题http网络传输本身是否会对报文大小有所限制http协议本身对Post请求的json报文大小几乎是没有限制的非分块传输编码所支持的报文长度受限于请求头中的content_length所能表达的最大长度这它支持的长度远远超过日常应用场景所以几乎不用考虑协议本身对报文大小的限制。而更多的应该从网络带宽、服务器内存、请求经过的中间节点如nginx或tomcat服务器等相关报文大小配置等方面考虑。接口接收到请求反序列化时将该base64编码数据赋值给字符串字段的时候是否会因超长导致赋值失败这就涉及到java中String类型能够支持的数据长度最大是多少编译期在Java中我们要探讨String的最大长度需区分是字面量和运行时传参两种情况如果是字面量那么字段大小受限于JVM虚拟机在编译期生成字节码文件时常量池中CONSTANT_Utf8_info常量表的length所能表示的最大长度u2类型2字节为2^16-16553564KB的大小运行期而若是运行时动态传值由于String类型的底层为char数组实现而char数组的长度是用int类型表示所以String能接受的最大长度为int类型的最大值即2^32-1约为4GB除此之外由于需要在堆中分配空间还需考虑堆的空间限制。探究接口和系统瓶颈在搞清楚了以上问题后可以明确当前场景下不会受上述先决条件的限制。那么就可以开始对该业务请求进行分析和评估。整个过程分为以下几步预估能支撑的并发量和QPS压测性能监控定位耗时和代码优化通过限流和隔离保证系统容错后续分几篇文章做系统性总结。