# Bulk request routing **URL:** \ **Category:** Elasticsearch\ **Created:** [March 29, 2014, 10:21pm UTC](https://discuss.elastic.co/t/bulk-request-routing/16697 "2014-03-29T22:21:44Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![slushi](https://avatars.discourse-cdn.com/v4/letter/s/3e96dc/32.png) [@slushi](https://discuss.elastic.co/u/slushi)\ **Post date:** [March 29, 2014, 10:21pm UTC](https://discuss.elastic.co/t/bulk-request-routing/16697/1 "2014-03-29T22:21:44Z")
I have been running some performance tests with some bulk indexing requests. One thing that is puzzling me is that I see pretty similar latency/cluster CPU usage when using the node vs transport client (client is on same network, cluster of 4 nodes). I am not that familiar with the client code, but as far as I can tell, the bulk request tries to divide up the documents per shard and route them using multiple requests. I would think this would lower cluster CPU usage and latency as the documents would be sent to the right node immediately rather than a potential 2 hop operation when using the transport client? My reasoning is that on the initial client -\> node request, may need to parse the request and then re-route the portion of requests that need to go to another node. Those re-routed requests would then need to be re-parsed. -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/f1e1448a-76d3-4e9d-bb3e-a5dff827e241%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/f1e1448a-76d3-4e9d-bb3e-a5dff827e241%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [March 30, 2014, 1:02am UTC](https://discuss.elastic.co/t/bulk-request-routing/16697/2 "2014-03-30T01:02:41Z")
Bulk requests are not parsed before they reach the destination node. They are split by a stream separator character (the line feed) and so the destination node can be found by merely looking at the bulk doc header, without doc parsing. The bulk action sorts the bulk items so all docs for a shard are sent with one network transmission. The difference between TransportClient and NodeClient regarding the hops is true, but it will take enormous load and network latency to see an effect. And there are other tradeoff factors. For example, if expensive code is run at TransportClient machine to build the JSON docs, this takes CPU load from the ES cluster because otherwise it would have to be performed at cluster side. This CPU win has to be balanced against the slightly slower network transmission. Jörg On Sat, Mar 29, 2014 at 11:21 PM, slushi [kireetreddy@gmail.com](mailto:kireetreddy@gmail.com) wrote: > I have been running some performance tests with some bulk indexing > requests. One thing that is puzzling me is that I see pretty similar > latency/cluster CPU usage when using the node vs transport client (client > is on same network, cluster of 4 nodes). I am not that familiar with the > client code, but as far as I can tell, the bulk request tries to divide up > the documents per shard and route them using multiple requests. I would > think this would lower cluster CPU usage and latency as the documents would > be sent to the right node immediately rather than a potential 2 hop > operation when using the transport client? My reasoning is that on the > initial client -\> node request, may need to parse the request and then > re-route the portion of requests that need to go to another node. Those > re-routed requests would then need to be re-parsed. > > -- > You received this message because you are subscribed to the Google Groups > "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > To view this discussion on the web visit > [https://groups.google.com/d/msgid/elasticsearch/f1e1448a-76d3-4e9d-bb3e-a5dff827e241%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/f1e1448a-76d3-4e9d-bb3e-a5dff827e241%40googlegroups.com)[https://groups.google.com/d/msgid/elasticsearch/f1e1448a-76d3-4e9d-bb3e-a5dff827e241%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/f1e1448a-76d3-4e9d-bb3e-a5dff827e241%40googlegroups.com?utm_medium=email&utm_source=footer) > . > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoG1uO9%2BiEqeCN2RkG6bgB2qUDtdWtTvc9aOcdOOQk2KnA%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoG1uO9%2BiEqeCN2RkG6bgB2qUDtdWtTvc9aOcdOOQk2KnA%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 1:39am UTC](https://discuss.elastic.co/t/bulk-request-routing/16697/3 "2017-07-06T01:39:42Z")