Scripts, caching, and search speed

Elasticsearch performs a number of optimizations to make using scripts as fast as possible. One important optimization is a script cache. The compiled script is placed in a cache so that requests that reference the script do not incur a compilation penalty.

Cache sizing is important. Your script cache should be large enough to hold all of the scripts that users need to be accessed concurrently.

If you see a large number of script cache evictions and a rising number of compilations in node stats, your cache might be too small.

All scripts are cached by default so that they only need to be recompiled when updates occur. By default, scripts do not have a time-based expiration. You can change this behavior by using the script.context.$CONTEXT.cache_expire setting. Use the script.context.$CONTEXT.cache_max_size setting to configure the size of the cache.

Scripts are incredibly useful, but can’t use Elasticsearch’s index structures or related optimizations. This relationship can sometimes result in slower search speeds.

If you often use scripts to transform indexed data, you can make search faster by transforming data during ingest instead. However, that often means slower index speeds. Let’s look at a practical example to illustrate how you can increase search speed.

When running searches, it’s common to sort results by the sum of two values. For example, consider an index named my_test_scores that contains test score data. This index includes two fields of type long:

You can run a query with a script that adds these values together. There’s nothing wrong with this approach, but the query will be slower because the script valuation occurs as part of the request. The following request returns documents where grad_year equals 2099, and sorts by the results by the valuation of the script.

GET /my_test_scores/_search
{
  "query": {
    "term": {
      "grad_year": "2099"
    }
  },
  "sort": [
    {
      "_script": {
        "type": "number",
        "script": {
          "source": "doc['math_score'].value + doc['verbal_score'].value"
        },
        "order": "desc"
      }
    }
  ]
}

If you’re searching a small index, then including the script as part of your search query can be a good solution. If you want to make search faster, you can perform this calculation during ingest and index the sum to a field instead.

First, we’ll add a new field to the index named total_score, which will contain sum of the math_score and verbal_score field values.

PUT /my_test_scores/_mapping
{
  "properties": {
    "total_score": {
      "type": "long"
    }
  }
}

Next, use an ingest pipeline containing the script processor to calculate the sum of math_score and verbal_score and index it in the total_score field.

PUT _ingest/pipeline/my_test_scores_pipeline
{
  "description": "Calculates the total test score",
  "processors": [
    {
      "script": {
        "source": "ctx.total_score = (ctx.math_score + ctx.verbal_score)"
      }
    }
  ]
}

To update existing data, use this pipeline to reindex any documents from my_test_scores to a new index named my_test_scores_2.

POST /_reindex
{
  "source": {
    "index": "my_test_scores"
  },
  "dest": {
    "index": "my_test_scores_2",
    "pipeline": "my_test_scores_pipeline"
  }
}

Continue using the pipeline to index any new documents to my_test_scores_2.

POST /my_test_scores_2/_doc/?pipeline=my_test_scores_pipeline
{
  "student": "kimchy",
  "grad_year": "2099",
  "math_score": 1200,
  "verbal_score": 800
}

These changes slow the index process, but allow for faster searches. Instead of using a script, you can sort searches made on my_test_scores_2 using the total_score field. The response is near real-time! Though this process slows ingest time, it greatly increases queries at search time.

GET /my_test_scores_2/_search
{
  "query": {
    "term": {
      "grad_year": "2099"
    }
  },
  "sort": [
    {
      "total_score": {
        "order": "desc"
      }
    }
  ]
}