_msearch vs _search


(Venkata Sreekanth Bhagavatula) #1

Lets say a bunch of users/applications are sending bulk search request and an another bunch single search queries. How would elastic search behave in this situation? Which queries would get priority ? Would response time differ by a large margin or would they be unnoticeable?


(Zachary Tong) #2

There's no real "prioritization" of search requests in ES, they are simply handled as soon as they are received. So the main difference between the two is that the single-search scenario will have a bit more network overhead due to initiating a new connection for each search, while the connection cost is amortized over the full MSearch request.

There will also be a bit more memory overhead in the MSearch, as the coordinating node will have to accumulate the various search responses in memory before sending back the final response.

Lastly, MSearch could potentially have a higher latency. It has to wait for all search requests to finish before sending back the final response, so if one of the searches is particularly slow (expensive query, nodes involved are slow, etc), the whole MSearch will block while that query finishes. In contrast, individual search requests will return as soon as they finish so they may have a lower individual latency (except for the slow query, obviously).

Internally, the actual execution of the searches is basically identical, so nothing different there. MSearch is internally dispatched as a bunch of single searches to the relevant nodes.


(Venkata Sreekanth Bhagavatula) #3

My scenario is like _msearch will have almost 40K query strings and this usually takes around 5 minutes to complete and uses all available search threads. While this process is running if 100 users issue single search queries will elastic search start additional threads or will the existing threads multiplex -- in short I am trying to understand what sort of behavior to expect.


(Zachary Tong) #4

That's a lot of queries :slight_smile:

A single search -- whether it comes from one of the MSearch items, or a regular single search -- will grab a thread from the search threadpool. The search threadpool defaults to the num_processors * 3. If all those threads are busy, any other search (single or msearch items) will pend until a thread is busy.

So basically, if you're hitting your cluster with 40k searches, it's entirely likely that users will see increased latency, as all search requests have the same "priority" in Elasticsearch, and they may end up waiting for a free thread.


(Venkata Sreekanth Bhagavatula) #5

Thank you for the explanation. We can actually have multiple users submit 40K queries.


(system) #6

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.