FAQ - Episerver Search and Navigation 429 (Too Many Requests) Exceptions

  • Updated
Description

In some cases Search and Navigation will relay 429(Too Many Requests) exceptions. This occurs when the QPS limit of an index is exceeded. The purpose is to prevent too many requests on the search backend which would adversely affect search availability.

See the below answers to frequently asked questions on 429 exceptions. 

FAQ
What was the reason for the QPS limit?

To prevent an excessive number of requests to the search backend. Doing this helps prevent load issues which increases the odds of future requests completing.

 

How can 429 errors be prevented?

One way to prevent 429 errors is proper Find caching.

https://world.episerver.com/documentation/developer-guides/find/NET-Client-API/searching/Caching/

 

If 429s occur during indexing, the batch size can be increased.

https://world.episerver.com/blogs/Per-Magne-Skuseth/Dates/2013/5/EPiServer-Find-Bulks-please/
 

Also see

https://world.episerver.com/blogs/K-Khan-/Dates/2015/9/episerver-find-performance-review/

 

Even when caching is implemented there can be issues as identified in this blog.

https://world.episerver.com/blogs/dada/dates/2019/1/common-find-caching-pitfalls/

 

Caching should be verified using Fiddler.

https://support.episerver.com/hc/en-us/articles/360021035391

 

If multiple searches can be combined into one, multisearch can be used. 
https://world.episerver.com/documentation/developer-guides/search-navigation/NET-Client-API/searching/Multiple-searches-in-one-request/

 

What is the criteria for when a 429 exception is returned by Search and Navigation?

In the search backend there is a "window" variable. It is the duration during which the number of requests are counted and the average QPS is decided based off that window. Currently the window is 5 seconds at the time of this writing(3/13/2020) but is subject to change. The QPS limit is typically 50 for DxC customers but may vary and can be confirmed through a request to support@optimizely.com.

Consider the following example.

TIME(s) QPS
1 55
2 52
3 21
4 40
5 45
6 95


So the average QPS for 5 seconds is 42.6 ((55+52+21+40+45)/5). On the 6th second, we remove the 1st "bucket" so the value will be: 50.6 ((52+21+40+45+95)/5), exceeding a QPS limit of 50. 


What types of requests are counted against the QPS limit?

Find requests including but not limited to the following.

  • search
  • msearch
  • config
  • autocomplete
  • bulk

There is caching on search, multisearch and autocomplete which reduces the QPS count on duplicate queries.  "Track" requests no longer count against the limit.

Is the retry-after header used when the QPS limit is hit?

As of this time they are not. 

How can I see what requests are producing the 429 errors?

If you have access to logs (Application Insights > logs) you can do this from the Azure portal. The following query will provide the top 5 requests which produced 429 errors. Replace usea01.find.episerver.net with the hostname in the service URL. 

requests

| project timestamp, operation_Id, name
|join (dependencies
| where resultCode == 429
| where target == 'usea01.find.episerver.net'
) on operation_Id
| summarize opCount = count() by name
| top 5 by opCount desc

If you do not have access, support should be able to provide the results from the query assuming the account is from DxP.