Why Elasticsearch Can Be Slow and How to Supercharge Its Performance

Interviewer Psychology Analysis

This question is often asked in interviews to see whether you have real hands‑on experience with Elasticsearch (ES). In practice, ES performance is not as magically fast as many assume; with billions of records the first search can take 5–10 seconds, then subsequent searches drop to a few hundred milliseconds.

Interview Question Analysis

There is no silver bullet for ES performance optimization. You cannot expect a single parameter tweak to solve all slow‑performance scenarios. Some cases can be fixed by adjusting a setting or query, but not all.

Performance Optimization Killer: Filesystem Cache

Data written to ES is stored on disk. When querying, the operating system automatically caches these files in the filesystem cache.

ES heavily relies on the underlying filesystem cache. Allocating more memory to the cache so it can hold the index segment files allows most searches to be served from memory, delivering millisecond‑level performance.

When searches go to disk, response times are measured in seconds (1 s, 5 s, 10 s). When the cache is used, performance improves by an order of magnitude, typically ranging from a few milliseconds to a few hundred milliseconds.

Real‑world case: a three‑node ES cluster with 64 GB RAM per node, 32 GB JVM heap, leaving 32 GB per node for the filesystem cache (96 GB total). The index data occupies 1 TB on disk (≈300 GB per node), so only about 10 % of the data fits in cache, resulting in poor performance.

Bottom line: to achieve good ES performance, the memory available for the cache should be at least half of the total data size.

Best practice: store only the fields needed for search (e.g., id, name, age) in ES and keep the rest in a separate store such as MySQL or HBase, using an ES + HBase architecture.

HBase excels at massive online storage and simple lookups (by ID or range). Search hot data in ES, retrieve the matching document IDs, then fetch the full records from HBase.

Write to ES only data that fits within the cache size. A typical query can then complete in ~20 ms, plus ~30 ms to fetch the full records from HBase, dramatically reducing the 5–10 s latency seen when all data resides in ES.

Data Pre‑heating

Periodically query hot data (e.g., popular users on Weibo or frequently viewed products on an e‑commerce site) to keep it resident in the filesystem cache. This proactive access ensures subsequent user requests are served from memory.

Cold‑Hot Separation

Create separate indices for cold and hot data. Store rarely accessed data in a cold index and frequently accessed data in a hot index, ensuring the hot index stays in the filesystem cache while cold data does not evict it.

For example, with six nodes and two indices (cold and hot), each index has three shards. Hot data occupies only ~10 % of total data, allowing it to remain mostly in cache and deliver fast responses, while cold data may be slower but is accessed infrequently.

Document Model Design

Avoid complex joins in ES. Perform necessary joins in the application layer before indexing, and keep the document model simple. Complex nested or parent‑child queries degrade performance.

Pagination Performance Optimization

Deep pagination in ES is costly because each shard must return a large number of documents (e.g., 1 000 per shard for page 100) to the coordinating node, which then merges and sorts them. This leads to seconds‑level latency for deep pages.

Solutions:

Disallow Deep Pagination

Limit the UI to sequential scrolling rather than arbitrary page jumps.

Use Scroll API

Scroll creates a snapshot of the entire result set and returns subsequent pages via a scroll_id. This provides millisecond‑level performance but only works for forward‑only navigation.

Use search_after

Leverage the last hit of the previous page as a cursor to fetch the next page. This also requires a unique sort field and does not support random page access.