[
https://issues.apache.org/jira/browse/SOLR-9592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15545623#comment-15545623
]
Takahiro Ishikawa commented on SOLR-9592:
-----------------------------------------
Thanks for comments, Yonik!
I'm glad to resolve your concern!
bq. The method name change might help a little
Are you disagree with renaming(-1) or weakly agree with(+0)?
I agree with renaming(Varun suggested). Because, at first glance, getLeafReader
does not imply internally calling SlowCompositeLeafReader and this make people
find performance bottlenecks difficult.
{quote}
but the real issue is knowing how to use things like MultiDocValues (i.e. you
generally want to use them for the ord mapping, but not the other stuff!)
We should really cache the MultiDocValues created as well... but that can be a
different JIRA.
{quote}
I may not catch the meaning here. If my understanding is clear, we should use
MultiDocValues in cases where you essencially need global view and
decorateDocValues usage is not the case right?
How to handle things like MultiDocValues in those cases(caching) is interesting
problem and might be other JIRA.
> decorateDocValues cause serious performance issue because of using
> slowCompositeReaderWrapper
> ---------------------------------------------------------------------------------------------
>
> Key: SOLR-9592
> URL: https://issues.apache.org/jira/browse/SOLR-9592
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Response Writers, search
> Affects Versions: 6.0, 6.1, 6.2
> Reporter: Takahiro Ishikawa
> Labels: performance
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-9592.patch, SOLR-9592.patch, SOLR-9592_6x.patch
>
>
> I have serious performance issue using AtomicUpdate (and RealtimeGet) with
> non stored docValues.
> Because decorateDocValues try to merge each leafLeader on the fly via
> slowCompositeReaderWrapper and it’s extremely slow (> 10sec).
> Simply access docValues via nonCompositeReader could resolve this
> issue.(patch)
> AtomicUpdate performance(or RealtimeGet performance)
> * Environment
> ** solr version : 6.0.0
> ** schema ~ 100 fields(90% docValues, some of those are multi valued)
> ** index : 5,000,000
> * Performance
> ** original : > 10sec per query
> ** patched : at least 100msec per query
> This patch will also enhance search performance, because DocStreamer also
> fetch docValues via decorateDocValues.
> Though it depends on each environment, I could take 20% search performance
> gain.
> (This patch originally written for solr 6.0.0, and now rewritten for master)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
