In production we are seeing that ES updates and real time holds queue can overwhelm the background worker and fall behind from "real time" If we had a dedicated worker for each of these jobs we could batch the operations, e.g. Fetch ES jobs until we hit 100 records or run out of queue, then index 100 at a time Indexing 1 record at a time takes a long time for each record
(In reply to Nick Clemens from comment #0) > Fetch ES jobs until we hit 100 records or run out of queue, then index 100 > at a time > Indexing 1 record at a time takes a long time for each record Isn't the problem koha-side actually, where we should batch update the index instead of call index_records for each record?
(In reply to Jonathan Druart from comment #1) > (In reply to Nick Clemens from comment #0) > > Fetch ES jobs until we hit 100 records or run out of queue, then index 100 > > at a time > > Indexing 1 record at a time takes a long time for each record > > Isn't the problem koha-side actually, where we should batch update the index > instead of call index_records for each record? The problem is not for a batch action, but for a series of individual actions i.e. 10 checkins happening one after another, then scale that to a site with 50 branches, all checking in their dropbox - 500 single index actions enqueued
I'm upping the severity of this bug as well as bug 32558, because being limited to 2 background worker processes is causing us some pretty significant issues with the volume of background jobs we generate - we've had to turn the real time holds queue off because the workers couldn't keep up.
*** Bug 34596 has been marked as a duplicate of this bug. ***
So bug 32594 introduced an "elastic_index" queue and a worker that could batch together indexing jobs. Bug 32558 added forking so that workers could process more jobs. The idea here is that we'd have a "real_time_holds_queue" so that a worker could just be devoted to that instead of competing with other jobs? -- We do need to work on a better way of setting up workers, because a smaller library will have more limited computing power, and probably will need fewer workers to handle all the jobs, while larger libraries with more computing power will want to have more workers for more separate queues...
+1