On 5/10/2018 8:28 PM, Shivam Omar wrote:
Thanks Shawn, So there are cases when soft commit will not be faster than the hard commit with openSearcher=true. We have a case where we have to do bulk deletions in that case will soft commit be faster than hard commits.
I actually have no idea whether deletions get put in memory by the NRTCachingDirectory or not. If they don't, then soft commits with deletes would have no performance advantages over hard commits. Somebody who knows the Lucene code REALLY well will need to comment here.
Does it mean post crossing the memory threshold soft commits will lead lucene to flush data to disk as in hard commit. Also does a soft commit has a query time performance cost than doing a hard commit.
If the machine has enough memory to effectively cache the index, then a query after a hard commit should be just as fast as a query after a soft commit. When Solr must actually read the disk to process a query, that's when things get slow. If the machine has enough memory (not assigned to any program) for effective disk caching, then the data it needs to process a query will be in memory regardless of what kind of commit is done.
Thanks, Shawn
