Performance discussion about default openfeign client
raizoor opened this issue · 7 comments
Resume
Discussion about default client performance of spring-cloud-openfeign
Versions
Java 17
Springboot 2.7.18
spring-cloud-dependencies 2021.0.8
Scenario
During a performance tests in a microservice that contain a 3 feign clients, it was possible to saw a high GC usage (i.e. high cpu utilization as well) in two methods, as we can see at profiler image bellow
We have a high tps scenario here - 110tps. The situation was absolutely unstable and we has too much resources to handle with that.
After studying the issue I decided to use lib {io.github.openfeign:feign-httpclient:11.8} and do a new evaluation. To my surprise, we had a significant improvement in resource usage, as feign started using other classes and no longer generated as many objects, as shown bellow
So, my question: Is this the expected behavior of the default implementation or is there something I did incorrectly, because we've a big difference here.
Code
I don't have a high customization clients, only a custom decoder and base64 auth, as bellow
@FeignClient(value = "...", url = "...",
configuration = ClientConfig.class)
public interface .. {
@PostMapping("..")
SpecificObject post(
@RequestHeader("..") Boolean ..,
@RequestBody SpecificObject ..
);
}
@raizoor are you willing to run flame charts on your project? That would help identify the issue
@velo I've some detailed information about cpu / memory local profiler (visualVM) that I can share too. If I can help with other actions, please let me know.
A flame chart would show where the problem is.
Bit tough to read this, specially in 2 separated images....
https://github.com/aragozin/jvm-tools/
Can you generate the SVG and send it to me?
java -jar sjk.jar stcap --pid $PID --timeout 1M --output /tmp/stcap.out
java -jar sjk.jar flame --file /tmp/stcap.out --output /tmp/flame.html
You probably want to email me https://github.com/OpenFeign/feign/blob/master/pom.xml#L145
The current default Client is the JDK provided, notoriously slow HttpURLConnection
. We don't recommend using the Default
Client implementation except for development and prototyping. It lack most of the benefits provided by the more robust solutions like Apache and OkHttp. This is almost certainly the reason for the disparity.