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

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.

Comment From: bclozel

Thanks for getting in touch, but it feels like this is a question that would be better suited to StackOverflow. As mentioned in the guidelines for contributing, we prefer to use GitHub issues only for bugs and enhancements. Feel free to update this issue with a link to the re-posted question (so that other people can find it) or add some more details if you feel this is a genuine bug.

In this case, the behavior might come from the client itself, the benchmark setup, HTTP protocol and server configuration, etc. We’re running many benchmarks internally and we’re always working on improving the performance. Running the same benchmark in a controlled environment (not the client and server both on the same host) and with a sampling profiler (with flame graphs as a a result) might give you a better idea on where that time is being spent. As a result of that, you might have interesting leads for optimizing your application or a library being used.

Thanks!