Hi Team, Any suggestion or recommendation for the above approach which we are
doing to have better search performance.
--
Sent from: https://lucene.472066.n3.nabble.com/Solr-User-f472068.html
Thanks a lot for your time to respond for my clarifications.
We are having two environment,
ENV A and ENV B ( Both same capacity of RAM ( r5.2xlarge and same number of
shards and replicas type (NRT) for the collection)
ENV A - it is having a collection which is optimized ( segment count 1 and
n
That seems high. It can be tricky to get tests. Are you running with
some kind of test runner? Do you have, say, 3-4 thousand queries
you run? Are you running the tests after warming the searchers?
Also, if you have indexed down to one segment, _then_ tried
adding docs and measuring you are not ge
Thanks Erick for the details and reference to understand better about merging
segment stuff.
When I compare performance of uninterrupted/optimized ( segment count 1)
collection for search request vs (indexing + search) in parallel going on
collection performance is 3 times higher,
for example
Updated documents are marked as deleted in the
old segment and added to a new segment. When
commits happen, merges occur and only then is the
space occupied by the deleted document reclaimed.
Which segments are merged on commit depends
on a number of factors.
Unless you can prove the extra space
Even though same document indexed over and over again due to incremental
update. Index size is being increased.
Do I miss any configuration to make optimization occur by internally ?
--
Sent from: https://lucene.472066.n3.nabble.com/Solr-User-f472068.html
