Additional Solr index request, when optimal number of sidekiq threads are busy

Skip to first unread message

Gourav Tiwari

Mar 31, 2015, 10:34:25 AM3/31/15
Hello Everyone!

We are using Solr heavily with Sidekiq jobs to index records in background for search feature in our Ruby on Rails application. 

We recently saw that Solr is very stable when we have four-sidekiq process to index records as we have four-CPU cores, we are using WebSolr.

The problem:

When we index records in background through sidekiq, it's all good, but sometimes there are indexing requests, which 'should' to happen inline, so that user don't wait to see the changes being reflected.

If we send another requests it in parallel to the sidekiq processes with 'Sunspot.session.original_session' object:
1. is it feasible?
2. Is there any known downside to it?

Please share your thoughts.

Reply all
Reply to author
0 new messages