Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[FEATURE] Add JMH Benchmark Module

Aperta
  • Qualcosa non va?
#2,110 6 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
55/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
java
Ambito
performance

Direzione di ricerca

Inizia con il modulo proposto benchmarks/build.gradle.kts e src/jmh/java/org/opensearch/client/benchmarks/BulkIngesterBenchmark.java, quindi esamina la struttura esistente del progetto Gradle e l'API BulkIngester. Esegui ./gradlew :benchmarks:jmh -Pbenchmark=BulkIngesterBenchmark su un cluster locale. Il lavoro è completato quando il benchmark JMH supporta i parametri richiesti, misura il throughput e pulisce il proprio indice con timestamp.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement untriaged
Is your feature request related to a problem?

The opensearch-java client has no performance benchmarking infrastructure. There is currently no way to:

  • Measure the throughput or latency of BulkIngester under different configurations
  • Detect performance regressions introduced by code changes
  • Compare the cost of different serialization strategies (e.g. raw POJO vs BinaryData)
  • Validate that optimizations like increased maxConcurrentRequests or batch sizing actually improve end-to-end throughput

Without a benchmark module, performance work relies entirely on ad-hoc scripts written outside the repository, making results hard to reproduce and compare across contributors.

What solution would you like?

A benchmarks/ submodule using JMH (Java Microbenchmark Harness) (https://github.com/openjdk/jmh) via the me.champeau.jmh(https://github.com/melix/jmh-gradle-plugin) Gradle plugin.

Proposed module structure

benchmarks/
├── build.gradle.kts # JMH plugin + dependencies
└── src/jmh/java/org/opensearch/client/benchmarks/
└── BulkIngesterBenchmark.java # end-to-end throughput benchmark

BulkIngesterBenchmark — initial benchmark

Measures end-to-end BulkIngester throughput (ops/s) against a live OpenSearch cluster, parameterized on:

  • maxOperations — operations per bulk flush (e.g. 1000, 5000, 10000)
  • maxSize — max bytes size per bulk flush (e.g. 5MB, 10MB)
  • maxConcurrentRequests — in-flight bulk request limit (e.g. 1, 2, 4, 8)

Key design decisions:

  • Uses @Threads(Threads.MAX) to simulate concurrent producers and reach steady-state throughput
  • Pre-serializes documents to BinaryData once at @Setup to isolate transport cost from serialization cost
  • Creates a fresh timestamped index per trial and deletes it in @TearDown
  • Supports HTTPS + basic auth via system properties for testing against remote clusters
Run against a local cluster

./gradlew :benchmarks:jmh -Pbenchmark=BulkIngesterBenchmark

Run against a remote cluster with HTTPS + basic auth

./gradlew :benchmarks:jmh -Pbenchmark=BulkIngesterBenchmark
-Dbenchmark.scheme=https
-Dbenchmark.host=my-cluster.example.com
-Dbenchmark.port=443
-Dbenchmark.user=admin
-Dbenchmark.password=secret

Sample output:

Benchmark (batchSize) (maxConcurrentRequests) Mode Cnt Score Error Units
BulkIngesterBenchmark.bulkIndexThroughput 1000 1 thrpt 10 28,776 ± 1,839 ops/s
BulkIngesterBenchmark.bulkIndexThroughput 5000 1 thrpt 10 35,395 ± 1,423 ops/s
BulkIngesterBenchmark.bulkIndexThroughput 10000 1 thrpt 10 35,507 ± 2,873 ops/s
BulkIngesterBenchmark.bulkIndexThroughput N/A 1 thrpt 10 35,241 ± 1,102 ops/s

What alternatives have you considered?

OpenSearch Benchmark (OSB) maybe an option, but OSB drives OpenSearch directly using its own internal HTTP client. It measures what the cluster can handle — indexing throughput, query latency, segment merge cost. It has no knowledge of the Java client's internal architecture: BulkIngester's buffer management, the maxConcurrentRequests semaphore, the ReentrantLock contention, serialization cost, or connection pool behavior.

If a code change in BulkIngester introduces a lock contention bug that halves throughput, OSB would never detect it — because OSB never calls BulkIngester.

Lingua principale
Java
Stelle
165
Fork
257
Merge medio
1g 1h
PR unite (30g)
44

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di opensearch-project/opensearch-java

Tutte le issue di opensearch-project/opensearch-java

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.