Last Updated : March 2022
If you’re suffering from poor search performance, you should run Opster’s Search Log Analyzer. With Opster’s Analyzer, you can easily locate slow searches and understand what led to them adding additional load to your system. You’ll receive customized recommendations for how to improve your search performance. The tool is free and takes just 2 minutes to run.
To easily locate the root cause and resolve issues try AutoOps for Elasticsearch. It diagnoses problems by analyzing hundreds of metrics collected by a lightweight agent and offers guidance for resolving them.
14 tips on how to reduce Elasticsearch search latency and optimize search performance:
- Size parameter
Assigning a huge value to size parameter causes Elasticsearch to compute vast amounts of hits, which causes severe performance issues. Instead of setting a huge size, you should batch requests in small sizes.
- Shards and replicas
Optimize necessary index settings that play a crucial role in Elasticsearch performance, like the number of shards and replicas. In many cases having more replicas helps improve search performance. Please refer to Opster’s guide on shards and replicas to learn more.
- Deleted documents
Having a large number of deleted documents in the Elasticsearch index also causes search performance issues, as explained in this official document. Force merge API can be used to remove a large number of deleted documents and optimize the shards.
- Search filters
Effective use of filters in Elasticsearch queries can improve search performance dramatically as the filter clauses are 1) cached, and 2) able to reduce the target documents to be searched in the query clause.
- Wildcard queries
Avoid wildcard, especially leading wildcard queries, which causes the entire Elasticsearch index to be scanned.
- Regex and parent-child
Note that Regex queries and parent-child can cause search latency.
- Implementing features
There are multiple ways to implement a specific feature in Elasticsearch. For example, Autocomplete can be implemented in various styles. Opster’s blog gives a 360-degree view of both functional and non-functional features (especially performance).
- Multitude of small shards
Having many small shards could cause a lot of network calls and threads, which severely impact search performance; please refer to this real-world case study by Opster’s expert on this topic.
- Heavy aggregations
Avoid heavy aggregations that involve unique IDs. Refer to Opster’s slow logs guide to identify such search slow logs effectively.
- Timeout and terminate
Timeout param and terminate after param can be useful when executing heavy searches, or when result data is vast. This official guide can help.
- Search templates
Use search templates to achieve better abstraction, meaning without exposing your query syntax to your users. Search templates also help you transfer less data over the network, which is particularly useful when you have large Elasticsearch queries.
- Multi search API
Use msearch whenever possible. In most of the applications it’s required to query multiple Elasticsearch indices for a single transaction, and sometimes users do so in a serial order even when it’s not required. In both cases, when you need to query multiple indices for the same transaction and when the result of these queries are independent, you should always use msearch to execute the queries in parallel in Elasticsearch.
- Term queries
Use term query when you need an exact match and on keywords fields. By default, Elasticsearch generates both text and keyword fields for every field that consists of a string value if explicit mapping is not supplied. Users tend to use the match query even on keyword data types like product-ids, which is costly as match query goes through an analysis operation. Read the difference between Term vs Match query and always use term query on keyword data types and wherever you need exact searches for better performance.
- Source filtering
_source filtering is a great way to improve the performance of Elasticsearch queries when retrieving a large number of documents or documents of large sizes. By default, Elasticsearch returns the complete source of matching documents. If you don’t need _source at all or need only values of specific fields, you can achieve this with _source filtering.
Say goodbye to search latency and related downtime – Opster’s Search Gateway transforms the way searches are handled in Elasticsearch.
Aside from gaining deep visibility of searches and the option to group data by users and application, the Gateway provides users with the unique ability to block heavy searches and prevent them from degrading performance and breaking clusters. Learn more about the Search Gateway and book a demo to get started.