Rate limiting in Enterprise Search
Rate limiting is a measure put in place to protect a site’s search services from spikes in requests that can cause instability. Rate limiting is likely to occur if many pages are making the same queries directly to Elasticsearch (ES) rather than making use of caching.
When Elasticsearch queries are rate limited, a portion of the requests will go to the database instead. Depending on the type of queries and the volume of queries made, they could overload the primary database and lead to an increase in responses with a 503
HTTP status code.
In addition to Elasticsearch queries, rate limiting can also be applied to the indexing process.
Determine if rate limiting is in effect
Two methods are available to determine if rate limiting is in effect for a site. These methods will also indicate if rate limiting is in effect for search
or indexing
:
- WordPress Admin toolbar: Refer to the Enterprise Search Dev Tools panel.
- VIP-CLI: Run the command:
wp vip-search health rate-limits
.
Prevent rate limiting
A site’s normal peak traffic load should be less than the per-application default rate limit for Enterprise Search. If a site is being rate limited, it indicates that the queries being made to Elasticsearch need to be reduced in number and optimized.
- Review opportunities to reduce the frequency of the queries. Ensure that each page is being cached in page cache at the edge, or normalization and object caching of the search results themselves.
- Implement caching layers. Use the WordPress object cache to store successful results for a period of time, and use those instead of making repeated requests to Enterprise Search.
WP_Query cache
Because WP_Query works with object cache to cache the results of each query, and Enterprise Search is intercepting just the MySQL portion, repeated queries within a short period of time should be hitting Memcached rather than Elasticsearch. This is normal, supports scaling, and avoids repeated Elasticsearch calls that trigger rate limiting.
Query parameters that are constantly changing—especially date or time parameters—result in excess resource use, contribute to poor site performance, and can trigger rate limits. Because query parameters are combined together in a hash to access the cache, changing times will miss the cache and result in a new query every time. Use Enterprise Search Dev Tools to determine which parameters are being sent to Elasticsearch, and if they are constantly changing.
Last updated: December 22, 2023