-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Benchmark JVMs for OpenSearch #1276
Comments
There's also an issue requesting distributions of OpenSearch that don't include a JDK (opensearch-project/opensearch-build#99). So this benchmarking should be done in a way that's reproducible & automated, so that anybody who wants to use a different JDK can understand objective performance gains and tradeoffs for it. |
Pre-requisites for this issue:
|
Moving to Infra for prereqs. |
@minalsha @saratvemulapalli Hey -- pondering on this. If we're thinking of this as a one time (or infrequent) activity, do we need to wait for automation? Isn't this something we could do just using rally and different configs? Thanks! |
Let's start with an exploration using existing tools, and tie this into the build infrastructure at the end of the project. As long as the benchmarking uses Rally, and everything is scripted, it'll be straightforward enough to automate this when the time comes. Let's also remove the dependency on opensearch-project/opensearch-build#74 by focusing on the runtime JVM, not the build JVM. |
We should start with benchmarking min/core with Perf test suite and then pick the right JVM version. |
Benchmarking needs to be done against jdk8, jdk11, jdk14, jdk16 and jdk17 |
A team account has been created for testing |
OpenSearch cluster instances have been launched but there is still an error when performing testing |
Tests have begun and the results are being compiled. Metrics being recorded are Latency (ms), Throughput (req/s), and Operation Counts. |
Interesting findings [1] for Apache Solr deployments (which could be quite relevant to OpenSearch as well), quoting for completeness:
I think benchmarking against GraalVM distributions could be an interesting experiment. [1] https://twitter.com/karlstoney/status/1456616777325158405 |
Results for min distribution of OpenSearch 1.2: |
Java 8: x64 Latency (ms)
Throughput (req/s)
|
Java 8: arm64 Latency (ms)
Throughput (req/s)
|
Java 14: x64 Latency (ms)
Throughput (req/s)
|
Java 15: x64 Latency (ms)
Throughput (req/s)
|
Java 17: x64 Latency (ms)
Throughput (req/s)
|
Java 17: arm64 Latency (ms)
Throughput (req/s)
|
Java 11: x64 Latency (ms)
Throughput (req/s)
|
Java 11: arm64 Latency (ms)
Throughput (req/s)
|
What's the hardware configuration for this test (OS, processor, RAM)? Can you run the benchmarks across different Operating Systems that may have variations in default glibc installations? |
Just want to clarify, by "JVM versions" mentioned in the task description does it refer to finding the best distribution (i.e. Oracle vs Adopt vs Corretto, etc)? The test results posted above are for Java versions, and unless I missed, I don't see the distribution specified. As for Java versions, I think the obsolete non-LTS versions (14, 15) would be non starters for a runtime JVM due to the lack of security updates. The same reasoning might apply for Java 8 as well since it will be approaching end-of-life relatively soon and there are two more recent LTS versions now. As for the automated benchmarks that I think is ultimately the goal, in #1647 we found a change in performance of the fetch phase that was not detected in the existing nyc_taxis benchmarks, so we should ensure that the workloads we develop use here have some coverage of the fetch phase to close that gap. |
|
Bingo. The output is to choose a jdk distribution based on available data. Performance is one of the data points, and maintenance/patching policy is going to be another big one. I think @CEHENKLE is going to continue that conversation in a new issue in January. |
Hey @ryanbogan, your benchmark results indicate arm64 has better performance than x64. Do you have specific JVM options for arm64? I am benchmarking OpenSearch 1.2.4 & Corretto JDK 17 in arm64 vs x64(r5.2xlarge vs r6g.2xlarge) using |
@Cai-Chen I just used the base version found on the Oracle website for each JVM. The x64 version performs better than arm64 with JDK 17 based on my testing (4.53 vs. 9.295 millisecond latency), so I do not believe that you are missing any special configuration options. |
Thanks @ryanbogan , thats bad news for me 😢 |
I used m5.xlarge for x64 and m6g.xlarge for arm64 @Cai-Chen |
@ryanbogan whats tasks are pending to prevent closing this issue? |
@minalsha I don't think there are any tasks left for this issue |
The JVM we're using is the one that we inherited, but we haven't validated that it's actually the best one to use.
The request is to benchmark different JVM versions with OpenSearch & make a plan to move to the highest-performing one. Please also consider support & terms when making a recommendation. For example, Oracle JDK has short LTS support for free users, longer LTS support for paid users. Adopt has very short support. AWS corretto offers longer support for select versions, etc.
Expected output: Benchmark information for OpenSearch on different available JVMs (similar to: https://www.optaplanner.org/blog/2021/09/15/HowMuchFasterIsJava17.html)
Once we've done our homework, we can move the project to the best JVM (if necessary).
The text was updated successfully, but these errors were encountered: