# Java Bulk Request advantage over individual Request

**URL:** <https://discuss.elastic.co/t/java-bulk-request-advantage-over-individual-request/48355>\
**Category:** Elasticsearch\
**Created:** [April 25, 2016, 9:58pm UTC](https://discuss.elastic.co/t/java-bulk-request-advantage-over-individual-request/48355 "2016-04-25T21:58:24Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![smartyalgo](https://avatars.discourse-cdn.com/v4/letter/s/5fc32e/32.png) [@smartyalgo](https://discuss.elastic.co/u/smartyalgo)\
**Post date:** [April 25, 2016, 9:58pm UTC](https://discuss.elastic.co/t/java-bulk-request-advantage-over-individual-request/48355/1 "2016-04-25T21:58:24Z")

</div>

TL;DR  
Is Java Bulk api useful when I'm already implementing Java's Transport client?

For REST, I understand bulk can reduce load by saving on rest request overhead.  
For Java, the transport client already maintains an open connection to the ES node, so what is the advantage of using java's bulk api over individual requests?

My cluster is on v2.1, I don't see Java bulk api documentation for version beyond 1.5, are we moving away from it as it's indifferent to individual requests?

If anything, it actually bundles up ES tasks to be queued, hence increasing the volatility(S.D) on # of tasks queued/second and thus more likely to get EsRejectionException because queue is filled.

---

<div class="post-metadata">

**Author:** ![jasontedor](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jasontedor/32/66992_2.png) [@jasontedor](https://discuss.elastic.co/u/jasontedor)\
**Post date:** [April 26, 2016, 1:26am UTC](https://discuss.elastic.co/t/java-bulk-request-advantage-over-individual-request/48355/2 "2016-04-26T01:26:00Z")

</div>

> [@smartyalgo](#):
>
> Is Java Bulk api useful when I'm already implementing Java's Transport client?

Yes.

> For Java, the transport client already maintains an open connection to the ES node, so what is the advantage of using java's bulk api over individual requests?

Networking requests are cheap.

That's not the biggest gain though. In 2.x, by default Elasticsearch does an `fsync` per request. Of course, these `fsync`s hurt performance. But if you bundle a bunch of indexing operations into a single bulk request, you only pay the cost of the `fsync` once and thus amortize the cost of the `fsync` over multiple operations. This does make a tremendous difference to performance.

What is more, multiple in-flight bulk requests can share an `fsync`. That is, if request A and request B arrive and complete and then a call to `fsync` is made from the completion of A, the `fsync` that would have been executed because of the completion of B is skipped.

> [@smartyalgo](#):
>
> My cluster is on v2.1, I don't see Java bulk api documentation for version beyond 1.5, are we moving away from it as it's indifferent to individual requests?

The docs are [available](https://www.elastic.co/guide/en/elasticsearch/reference/2.1/docs-bulk.html).

> [@smartyalgo](#):
>
> If anything, it actually bundles up ES tasks to be queued, hence increasing the volatility(S.D) on # of tasks queued/second and thus more likely to get EsRejectionException because queue is filled.

Indexing requests get queued too, and I'm really not sure what you're trying to say about volatility?

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [July 5, 2017, 10:56pm UTC](https://discuss.elastic.co/t/java-bulk-request-advantage-over-individual-request/48355/3 "2017-07-05T22:56:23Z")

</div>

Closed on July 5, 2017, 10:56pm UTC