ServiceComb框架相比于SpringMvc在处理MultipartFile表单文件有什么优化

代码本来使用了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 で示されている 2 つのエントリポイント、Tomcat の MultipartStreamItemInputStream.findSeparator と Netty の HttpPostMultipartRequestDecoder.findMultipartDelimiter を比較します。flame graph の証拠と MultipartFile のアップロードパスを確認し、ServiceComb が最適化を追加しているのか、それとも差異が基盤となるサーバーに起因するのかを判断します。原因と、サポートされる最適化または設定変更を文書化できれば完了です。

索引モデルが issue の本文から書いたものです。