apache / apache/servicecomb-java-chassis
ServiceComb框架相比于SpringMvc在处理MultipartFile表单文件有什么优化
- 主要语言
- Java
- 星标
- 1.9k
- 派生
- 814
- 平均合并
- 8 天 23 小时
- 30 天内合并 PR
- 1
描述
代码本来使用了ServiceComb版本2.8.6,切换为SpringMVC 版本5.3.31后,发现有一个上传文件的接口效率下降了
业务代码如下
```java
@ResponseBody
@PostMapping(value = "/uploadFile", produces = MediaType.MULTIPART_FORM_DATA)
public Response upload1File(@NotNull MultipartFile file, HttpServletRequest request) {
try (InputStream inputStream = file.getInputStream();) {
// 具体业务
}
}
```
分析了火焰图,发现使用了MVC框架后,主要在这部分消耗比较多时间
[40]48.31% 9,101 self: 0.02% 3 orglapache/tomcat/util/http/fileupload/MultipartStreamSItemInputStream.makeAvailable
.. [41]30.95% 5,830 self 0.02% 3 org/apache/tomcat/util/http/fileupload/MultipartStreamSItemInputStream.findSeparator
[42]30.93% 5,827 self: 30.93% 5,827 org/apache/tomcat/util/http/fileupload/MultipartStream.findSeparator
serviceComb 处理表单的方法
io.netty.handler.codec.http.multipart.HttpPostMultipartRequestDecoder#findMultipartDelimiter
想问下ServiceComb在对于MultipartFile文件接口有没有做什么优化,还是说可能只是底层一个是tomcat,一个是netty的原因
贡献指南
这个仓库没有索引到贡献指南
调研方向
首先比较 issue 中提到的两个入口点:Tomcat 的 MultipartStreamItemInputStream.findSeparator 和 Netty 的 HttpPostMultipartRequestDecoder.findMultipartDelimiter。检查 flame graph 证据和 MultipartFile 上传路径,以确定 ServiceComb 是否添加了优化,或者差异是否可归因于底层服务器。完成的标准是记录原因以及任何受支持的优化或配置更改。
由索引模型根据 Issue 内容生成。
评估
- 技术栈
- java, spring
- 领域
- api, backend, performance
- Issue 类型
- 缺陷
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 活跃度
- 停滞
- 描述清晰度
- 需要澄清
- 新手友好度
- 28/100