Chapter 10. Improving performance

This chapter covers

Bulk, multiget, and multisearch APIs

Refresh, flush, merge, and store

Filter caches and tuning filters

Tuning scripts

Query warmers

Balancing JVM heap size and OS caches

Elasticsearch is commonly referred to as fast when it comes to indexing, searching, and extracting statistics through aggregations. Fast is a vague concept, making the “How fast?” question inevitable. As with everything, “how fast” depends on the particular use case, hardware, and configuration.

In this chapter, our aim is to show you the best practices for configuring Elasticsearch so you can make it perform well for your use case. In every situation, you need to trade something for speed, so you need to pick your battles:

Application complexity— In the first part of the chapter, we’ll show how you can group multiple requests, such as index, update, delete, get, and search, in a single HTTP call. This grouping is something your application needs to be aware of, but it can speed up your overall performance by a huge margin. Think 20 or 30 times better indexing because you’ll have fewer network trips.

Indexing speed for search speed or the other way around— In the second section of the chapter, we’ll take a deeper look at how Elasticsearch deals with Lucene segments: how refreshes, flushes, merge policies, and store settings work and how they influence index and search performance. Often, tuning for index performance has a negative impact on searches and vice versa.

Memory— A big factor in Elasticsearch’s speed is caching. Here’s we’ll dive into the details of the filter cache and how to use filters to make the best use of it. We’ll also look at the shard query cache and how to leave enough room for the operating system to cache your indices, while still leaving enough heap size for Elasticsearch. If running a search on cold caches gets unacceptably slow, you’ll be able to keep caches warm by running queries in the background with index warmers.

All of the above— Depending on the use case, the way you analyze the text at index time and the kind of queries you use can be more complicated, slow down other operations, or use more memory. In the last part of the chapter, we’ll explore the typical tradeoffs you’ll have while modeling your data and your queries: should you generate more terms when you index or look through more terms when you search? Should you take advantage of scripts or try to avoid them? How should you handle deep paging?

We’ll discuss all these points and answer these questions in this chapter. By the end, you’ll have learned how to make Elasticsearch fast for your use case, and you’ll get a deeper understanding of how it works along the way. Grouping multiple operations in a single HTTP request is often the easiest way to improve performance, and it gives the biggest performance gain. Let’s start by looking at how you can do that through the bulk, multiget, and multisearch APIs.