We noticed that for timing in ES RestClient "System.nanoTime()" is being used. We've been bitten by it when we used it in a multi-threaded application hitting this code. Our performance actually degraded. This pushed us back to the usage of "System.currentTimeInMillis()". There are several threads on SFO stating this. One of such links is this.
Is there a particular reason that "System.nanoTime()" is being used for measuring the time? We are currently having troubles related to the ES Rest client performance and our network team is sure that there is no issue between our server and ES cluster. We were wondering if there is a way to turn-off / toggle away the call to "System.nanoTime()"?
That's a good question, as you can see from the code its used to measure timeouts amongs other things, so maybe the millis resolution wasn't good enough for this. But it would be a good question to ask on Github again I think. I can open an issue if you like, but maybe you prefer doing so yourself.
Does this lead you to believe System.nanoTime() is part of it? If so, how do you currently measure your performance? There's no easy way to switch this off currently since as I mentioned it is used for measuring timeouts. I doubt it is having such a big effect on the client performance though.
System.nanoTime() is guaranteed by the JVM to be monotonic increasing value, whereas System.currentTimeInMillies() can go backwards when the OS clock changes. Because of this, when we are timing the duration of things, we use nanoTime so endTime - startTime doesn't end up negative.
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.