Skip to content

JsonProvider.provider method triggers Class loading too often and thus increases CPU usage and final latency #479

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
mgorpenko opened this issue Jan 10, 2023 · 2 comments · Fixed by #485

Comments

@mgorpenko
Copy link

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?

@swallez
Copy link
Member

swallez commented Jan 16, 2023

This is indeed something we overlooked, thanks for pointing it out. It has been fixed in #485.

We're also working on #471

@swallez swallez closed this as completed Jan 16, 2023
@mgorpenko
Copy link
Author

Great news!
Thank you for the quick fix

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants