之前的小项目里提供了一个 REST 接口,接口一堆参数,其中包含一个 image 图片,用的是 base64 传递。这个接口主要逻辑是处理一段业务后,将 base64 图片会存到本地。

就这样一个接口,发布之后每隔一段时间就会出现几次请求超时的情况,正常情况接口再 100ms 以内响应的,但是运行一段时间后,有时会超过 10s 以上才给响应,甚至超时的情况。

现在想解决这个问题,做了如下处理:

1. 用 apifox 开多个线程调用接口,问题可以复现
2. 把 base64 去掉,不传,问题不再复现
3. 传 base64 ,但是接口里面所有的逻辑都注释掉,问题也可以复现

那是不是意味着 REST 请求数据包就不能太大,能通过配置的方式缓解/解决这个问题吗?

求教~
举报· 218 次点击
登录 注册 站外分享
17 条回复  
xhatt510 小成 2024-8-1 11:41:43
不会导致越来越慢
cppc 小成 2024-8-1 11:30:36
用这个去定位问题 https://arthas.aliyun.com/ 你可以稳定重现就好说
musi 小成 2024-8-1 07:44:52
io 被阻塞了?你用 form 传试试要是还慢就是阻塞了
artiga033 小成 2024-7-31 17:25:16
曾经有个项目就是一大堆高清图片作为 base64 文本嵌入,一个接口响应有 7MB 多,但是主要也是网络传输时间,接口响应速度还是微秒级
nevermoreluo 小成 2024-7-31 17:05:05
我有个问题  
把 base64 去掉的时候,对程序做额外处理了吧,如果还用 string 传包体,图片还完整吗?怎么处理的,直接存到 string 然后\0 就不管了吗?   
有没有部分图片小了很多很多?
所以有没有可能问题一直有 只是把 base64 去掉的时候,搞错东西了
wws2023 小成 2024-7-31 16:42:36
哪里 io 占用了吧
ssgooglg 初学 2024-7-31 15:13:13
我们是图片存 oss ,api 只返回图片 uri
CHTuring 小成 2024-7-31 15:04:56
理论上来说传一个数据比较多的 base64 会影响,但是不会有你说的 10s 那么大。和上面说的那样,你应该主要测试写入的代码。
evan1 小成 2024-7-31 14:57:10
图片 base64 太长了吧。

换一个短一点的,然后再换一个超长的复现看看。
cnzjl 小成 2024-7-31 14:48:53
感觉是不是写入图片那部分导致的,加点 log 看看?
12下一页
返回顶部