Thread Pools and Queues


(Paweł Młynarczyk) #1

There are many users working with the application. Some of them are online
users, that should have their requests served in real time and some of them
are workers that are preparing reports and their requests can wait. At the
moment, all the requests arriving to elasticsearch are queued at the same
queue and that sometimes results in online users not getting their request
served as soon as possible or even getting rejected when the queue is full
of workers' requests. That could be solved by adding separate Thread Pool
and Queue for 'low priority search'. Same would apply for other operations
(get, bulk etc).

Are there any plans or any chance for this kind of feature being
implemented in Elasticsearch?

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/14bb9a8c-5d74-4a0e-a155-1178ce2be25b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


(Jörg Prante) #2

You could set up a special node for "low priority" search, with "slim"
thread pool settings, and forward client calls to it respectively.

Jörg

On Mon, Mar 24, 2014 at 3:08 PM, Paweł Młynarczyk zwarios@gmail.com wrote:

There are many users working with the application. Some of them are online
users, that should have their requests served in real time and some of them
are workers that are preparing reports and their requests can wait. At the
moment, all the requests arriving to elasticsearch are queued at the same
queue and that sometimes results in online users not getting their request
served as soon as possible or even getting rejected when the queue is full
of workers' requests. That could be solved by adding separate Thread Pool
and Queue for 'low priority search'. Same would apply for other operations
(get, bulk etc).

Are there any plans or any chance for this kind of feature being
implemented in Elasticsearch?

--

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAKdsXoGbX3rQ6HEU2pzSKYpQhkm6Pe%3Dke%2B7qDAj%3DL-DfyMfyDg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


(Paweł Młynarczyk) #3

Thank you for your answer.

I did some tests and it appears that the lowest queue size between the data
nodes is the effective one (as far as I am concerned the search requests
are spread across all nodes with data) and queue sizes in non data nodes
are ignored (I guess that it is not ignored but redirecting search requests
to data nodes omits storing them in queue). So the given solution is not
working. Or am I missing something?

Paweł Młynarczyk

W dniu poniedziałek, 24 marca 2014 15:17:22 UTC+1 użytkownik Jörg Prante
napisał:

You could set up a special node for "low priority" search, with "slim"
thread pool settings, and forward client calls to it respectively.

Jörg

On Mon, Mar 24, 2014 at 3:08 PM, Paweł Młynarczyk <zwa...@gmail.com<javascript:>

wrote:

There are many users working with the application. Some of them are
online users, that should have their requests served in real time and some
of them are workers that are preparing reports and their requests can wait.
At the moment, all the requests arriving to elasticsearch are queued at the
same queue and that sometimes results in online users not getting their
request served as soon as possible or even getting rejected when the queue
is full of workers' requests. That could be solved by adding separate
Thread Pool and Queue for 'low priority search'. Same would apply for other
operations (get, bulk etc).

Are there any plans or any chance for this kind of feature being
implemented in Elasticsearch?

--

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/3bdf14af-b2c0-4153-9f49-c7f5ad737e11%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


(system) #4