No best practices as such, "whatever works" about covers it. That's not a huge query rate, especially if you have replicas per shard so I wouldn't worry too much about it. If you rack 100 clients all driving Solr as hard as possible and people complain that query responses are bad you'll know where to look first.
About batching, see: https://lucidworks.com/2015/10/05/really-batch-updates-solr-2/ YMMV of course. If I were going to give you a starting point for batching it would be on the order of at least 100 per shard. So a 5 shard collection would have at least 500 Solr documents per call to cloudSolrClient.add(doclist). Best, Erick On Wed, Oct 24, 2018 at 2:20 PM shamik <sham...@gmail.com> wrote: > > Thanks Erick, that's extremely insightful. I'm not using batching and that's > the reason I was exploring ConcurrentUpdateSolrClient. Currently, N threads > are reusing the same CloudSolrClient to send data to Solr. Ofcourse, the > single point of failure was my biggest concern with > ConcurrentUpdateSolrClient, thanks for clarifying my doubt. > > "You also want to be a little careful how hard you drive Solr if you're also > serving queries at the same time, the more cycles you use for indexing the > fewer are available to serve queries." > > Our solr servers are also used to serve queries (50-100/minute). Our hard > commit set at 10 minutes while soft commit is disabled. Are there any best > practices (I know it's too generic, but specifically around indexing) that I > should follow? > > > > > > -- > Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
