Thanks for your suggestions. I'll check if the filter queries or the
main query tokenizers/filters might have anything to do with this, but
I'm afraid query optimization can only get us so far. Since we will have
to add facets later, the queries will only become heavier, and there has
to be a way to scale this setup and deal with both higher load and more
complex queries.
On 08.11.18 10:53, Toke Eskildsen wrote:
On Tue, 2018-11-06 at 16:38 +0200, Sofiya Strochyk wrote:
I have tested all of the suggested changes none of these seem to make
a noticeable difference (usually response time and other metrics
fluctuate over time, and the changes caused by different parameters
are smaller than the fluctuations). What this probably means is that
the heaviest task is retrieving IDs by query and not fields by ID.
Barring anything overlooked, I agree on the query thing.
Were I to sit at the machine, I would try removing part of the query
until performance were satisfactory. Hopefully that would unearth very
few problematic parts, such as regexp, function or prefix-wildcard
queries. There might be ways to replace or tune those.
- Toke Eskildsen, Royal Danish Library
--
Email Signature
*Sofiia Strochyk
*
s...@interlogic.com.ua <mailto:s...@interlogic.com.ua>
InterLogic
www.interlogic.com.ua <https://www.interlogic.com.ua>
Facebook icon <https://www.facebook.com/InterLogicOfficial> LinkedIn
icon <https://www.linkedin.com/company/interlogic>
