Performance Transport vs REST client

Elastic Stack Elasticsearch
1

I'm having trouble with the performance of the Transportclient using the Java API, which is magnitudes slower compared to using the REST client.

If found a similiar thread here:
https://discuss.elastic.co/t/java-transport-client-slower-than-curl-request?source_topic_id=95876

and read the benchmark comparison:

While measuring the execution time I figured out, that the performance on server-side is in both cases the same (looking at the "took" parameter in the SearchResponse).
What seems to take a lot of time (well, its my guess) is the async execution in the Transportclient.

Measuring of the Transportclient:
SearchRequestBuilder srb = ...; srb.execute().actionGet()
I've just enclosed the srb.execute().actionGet() by time measuring.

Measuring of the REST client:
restClient.performRequest("GET", "/...", Collections.<String, String>emptyMap(), new NStringEntity(..)
I've filled NStringEntity(...) with the JSON-output of SearchRequestBuilder used with the TransportClient.

Performance:
REST client: about 35-40ms
Transport client: about 1200ms ("took" parameter in the SearchResponse is low, about 5-10ms)

I'm just measuring the time of sending to receiving the data. No building the query etc.

Is that explainable or is there any misconfiguration possible when initializing the Transportclient that leads to this behaviour?

2

Hi @Tobsucht,

hmm, it's really hard to tell what's going on so I can just give a few pointers:

  • Maybe it's network related. If you did this comparison now via Ethernet, run it on localhost (i.e. client and Elasticsearch on the same machine) and observe the differences or vice versa. You can also capture network packets of request / response with Wireshark and check the timestamps (when did the request leave your machine, when did the response arrive?).
  • Run our REST / transport client benchmark from the blog post (see instructions in the README). I am the author of the benchmarks and the blog post and did not experience any such difference back then (otherwise I would have investigated).
  • In case the network analysis shows that the network is fast and time is actually spent either sending the request or processing the response, attach a profiler to your client process to find out where time is spent. If you don't already have a profiler like Yourkit handy you can use e.g. VisualVM or Java Flight Recorder or JFR for short (which comes with Oracle JDK). Generally I prefer JFR for development but please note that it is a commercial extension of the Oracle JDK and you need to be careful to comply with the licensing terms. For a few pointers on how to use JFR, see a talk I've given on JFR.

Daniel

1 Like
4

Hi, @danielmitterdorfer

thanks for your reply and hints.
We solved the problem: it was an issue with netty, as we also use netty in our environment, we set the ressource leak detector to paranoid level on dev-systems ... as this option is global, the transport client uses this options and slows down.

Thanks!

1 Like
5

Hi @Tobsucht,

thanks for the follow-up. Interesting cause. I imagine it was a bit tricky to find.

Daniel

6

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.