Solr 9.0 – Rate Limits

The newest Solr version that is on its road to being released at the time when this blog post is published will bring many new features, changes, improvements, and bug fixes. Among one of the new additions to this search engine is search limiting. It allows us to limit the number of requests per given request type – for each search on a per JVM basis. Let’s quickly look into the functionality that we will soon have at our disposal.

The Basics

The idea behind this functionality is to provide a limit to a given type of request, that will be enforced on Apache Solr level. For example, we may want to limit the number of queries that are allowed to be run concurrently or the number of updates. This will help us protect the Solr cluster from being overloaded with requests of a given type. For example a flood of queries from the application itself and abusing Solr in a way that the indexing may suffer or vice versa – overloading Solr with indexing requests such that the queries are executed for a longer period of time affecting the users. 

Those limits are enforced on the JVM level, so they will be applied to all the collections running on a single Solr instance. This is pretty important and you should account for that when planning the rate-limiting configuration.  

At the moment, the default rate limiter is dedicated to queries.

Configuration – the API

There are two options on how you can configure rate limiting in Solr 9.0. First is the Cluster API. You can use it to set the query rate limits. This is something to keep in mind, the Cluster API allows only query rate limiting to be changed on the fly. This is how you could use it:

curl -X POST -H 'Content-type:application/json' 'http://localhost:8983/api/cluster' -d '{
  "set-ratelimiter": {
    "enabled": true,
    "allowedRequests": 20,
    "guaranteedSlots": 5,
    "slotBorrowingEnabled": true,
    "slotAcquisitionTimeoutInMS": 50

We send the POST request to the /api/cluster endpoint and use the set-ratelimiter command to provide information on the desired behavior. 

Let’s discuss the parameters for a second:

  • enabled – is the rate-limiting enabled or disabled (keep in mind this is only for query related limiting) 
  • allowedRequests – the number of allowed concurrent request
  • guaranteedSlots – the number of slots that are reserved beyond the allowed requests and works only with slots borrowing enabled
  • slotBorrowingEnabled – when set to true the given request may be able to borrow slots from other limiters
  • slotAcquisitionTimeoutInMS – the timeout in milliseconds that the thread will wait for execution until the request will be rejected and the 429 response code will be returned by Solr.

Configuration – web.xml

If we would like to keep the configuration more static or define the rate limits for more than the queries only we need to prepare the changes in the web.xml. Yes, in the web.xml, not in the solrconfig.xml file. You can add one or more options to the init-params of the SolrRequestFilter, for example, the query related ones are as follows:

  • isQueryRateLimiterEnabled – when set to true enabled query rate limiting
  • maxQueryRequests – the maximum number of query requests that can be run concurrently
  • queryWaitForSlotAllocationInMS – the time in milliseconds that the thread will be waiting when there are no slots available. After the time Solr will reject the execution of the request and return 429 status code
  • queryAllowSlotBorrowing – boolean value indicating slot borrowing functionality enabled or disabled
  • queryGuaranteedSlots – number of guaranteed slots for query execution (work only when slots borrowing is enabled)


Even though limited, starting with Solr 9.0 we have the option to potentially limit the number of search requests so that an enormous amount of searches will not affect other functionalities, such as indexing or even queries themselves. Fail fast as they say, so the sooner we see that we are rejecting requests, the sooner we will be able to react – for example, bring more processing power and save the day.

Leave a Reply

Your email address will not be published. Required fields are marked *