You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Similar to the issue: #471 I found that the new library consumes more CPU than the deprecated high-level rest client.
We use ElasticsearchAsyncClient.search method
In profiling, I see, that a significant part of the load is due to JsonProvider.provider method that is called in many cases.
It is a heavy method that triggers JarLoader.getResources. In JsonProvider.provider comments, I see: "Users are recommended to cache the result of this method." However, no cache is used by Elasticsearch-java lib. For example, every new JacksonJsonpParser (created for every response) calls this method from scratch.
As a result, the response deserialization takes significantly more CPU. The old RestHighLevelClient.parseEntity takes 3% of CPU, while RestClientTransport.decoreResponse needs 5.9% for exactly the same load. And 65% of this is because of JsonProvider.provider call.
And if we want to print SearchRequest to log sometimes, it requires even more CPU (JsonProvider.provider is called for every Query.toString method).
This is very significant for our services. The described issue increased our service latency by 8-15%. And that raises the question if it is a good decision to migrate to a new lib.
What is the reason for loading JsonProvider every time? Couldn't JsonValueParser.provider field be static? Or can it be configurable at least?
The text was updated successfully, but these errors were encountered:
Java API client version
7.17.7
Java version
17
Elasticsearch Version
7.17.5
Problem description
Similar to the issue: #471 I found that the new library consumes more CPU than the deprecated high-level rest client.
We use ElasticsearchAsyncClient.search method
In profiling, I see, that a significant part of the load is due to JsonProvider.provider method that is called in many cases.
It is a heavy method that triggers JarLoader.getResources. In JsonProvider.provider comments, I see: "Users are recommended to cache the result of this method." However, no cache is used by Elasticsearch-java lib. For example, every new JacksonJsonpParser (created for every response) calls this method from scratch.
As a result, the response deserialization takes significantly more CPU. The old RestHighLevelClient.parseEntity takes 3% of CPU, while RestClientTransport.decoreResponse needs 5.9% for exactly the same load. And 65% of this is because of JsonProvider.provider call.
And if we want to print SearchRequest to log sometimes, it requires even more CPU (JsonProvider.provider is called for every Query.toString method).
This is very significant for our services. The described issue increased our service latency by 8-15%. And that raises the question if it is a good decision to migrate to a new lib.
What is the reason for loading JsonProvider every time? Couldn't JsonValueParser.provider field be static? Or can it be configurable at least?
The text was updated successfully, but these errors were encountered: