springboot Why response time of the restful interface with @RequestParam MulityPartFile is very large sometimes?

Repost #20299

My code below:

@PostMapping("/gets")
    public SomethingResponseVo getSomething(@RequestParam MultipartFile imageData) 

I try to test the interface 100 times. Response time is 30ms at most of the test, but the response time is about 70ms in 10% of the test. I add filter and print log information below when response time is 70ms:

2020-02-23 19:21:52.639  INFO 14434 --- [apr-8848-exec-6] c.s.s.f.SomethingFilter: filter start is--------------------------------------------- 1582456912639
2020-02-23 19:21:52.681 TRACE 14434 --- [apr-8848-exec-6] o.s.w.s.DispatcherServlet                : POST "/verify/something/gets", parameters={}, headers={masked} in DispatcherServlet 'dispatcherServlet'

Time of the first line is "2020-02-23 19:21:52.639 ", this record is print by the filter which before filterChain.doFilter(servletRequest, servletResponse); Time of the second line is "2020-02-23 19:21:52.681", this record is printed by DispatcherServlet. The time gap is 42ms between two lines. The time gap is about 3ms usually but is about 40 ms sometimes. This make the response time is 70ms sometimes. So, I guess this may be caused by the multipartfile or the inputstream related codes. Is there any possible solution to resolve this kind of phenomenon.

Below is a sample link, you could download in your computer and test the response time. The response time is unstable, sometime up to about 40ms, and sometimes down about to 7ms. https://github.com/coco0817/kk.git

Comment From: coco0817

Below is a sample link, you could download in your computer and test the response time. The response time is unstable, sometime up to about 40ms, and sometimes down about to 7ms. https://github.com/coco0817/kk.git @bclozel

Comment From: bclozel

Hello @coco0817 No need to create a new issue for that, we're unfortunately still in the same position. Given your setup, this difference might come from your setup (OS, network), the HTTP client sending data, the HTTP server, GC calls in the JVM.

Performance issues are hard to diagnose and require strict benchmarks and precise profiling. The Spring team is running such benchmarks and we're always working on performance; but in this case, raising such an issue will not help us progress. Assuming the performance inconsistency comes from libraries (it might just be GC pauses), the actual code handling this is partly in the server itself (Tomcat?) and Spring Framework.