In order for your customers to have the optimal search experience, you should aim for your search response time to be below 100 milliseconds (ms) (100 ms is 1 tenth of a second). If you are seeing search response times above this value then there are a number of different ways you can investigate.
Understanding the source of the Issue
Whilst there are a number of eventual sources for search latency there are three main areas that they can originate from, and so the first step is to identify which of these three is the source.
- 1. Latency within your environment(for example time spent generating or processing a search request response)
- 2. Latency between your server and the Algolia server (essentially a problem in the network linking your application to Algolia and other servers)
- 3. Latency in the Algolia server processing your search request and returning results
The Second Latency source (the network) can be the hardest to diagnose when the issue is infrequent, and so the fastest way to find the source of the issue is to rule out latency on your environment and within the Algolia server.
How to rule out latency within your environment
Latency within your own environment can be the first place to check and the easiest to resolve. The first step depends heavily on how you use Algolia:
If you are calling Algolia from your own back end
You can rule out latency before the search request is made by logging the time taken from the moment the request is made from your server to Algolia, this is known as the Round-trip time (RTT). Note, a high RTT means that the issue is not on your application, but is either in the network between your cluster and Algolia or on the Algolia cluster itself.
If you are calling Algolia from your front end (for example using InstantSearch)
Google has their own tool you can use to find issues on your site here: https://pagespeed.web.dev once you have ruled these out, you can then check the time taken to make the request to Algolia in the network tab of your browser developer tools.
Here is an example, where we can see that the search request took 27 Milliseconds (which is well below 100 ms).
If you see that the request here is taking more than 100ms then the issue is either in the network between your cluster and Algolia or on the Algolia cluster itself.
How to rule out latency on the Algolia server
You have access to performance statistics in the Algolia dashboard in API Monitoring -> Performance link. The Search response time metric measures:
“...time spent, in milliseconds, in the engine from receiving the search query to sending the search results back through the API. This does not take into account the network latency.”
The graph here will show you the latency for three different groups of your searches:
Average - This will be the total average for all of your searches, as such it is the most important metric of course because this is an average it does not tell the whole story, it can be skewed by some very slow or very fast searches and so we have two additional metrics.
90th Percentile - This is the slowest speed for 90% of your searches, which means that 90% of your searches are faster then this speed. This allows us to remove small groups of extremely slow searches that might otherwise skew the average and make things look worse than they actually are for the majority of searches. If this value is below 100ms then you can be confident that most searches are being processed quickly.
99th Percentile - This is the slowest speed for 99% of searches, so as for the above metric, 99% of your searches are faster then this speed. For example, if your 99% percentile was 100ms, and the 90% percentile was 37ms then 9% of your searches are taking between 37 and 100 Milliseconds to process. So while the majority of your search is fast there is a small group of searches taking longer (and 1% of searches would be taking longer than 100 milliseconds.
Why might the percentiles be high if the average is low? - If the percentiles are high but the average is low, then this means that you have some searches taking longer to process. The best way to find these searches is to check for search requests that might be exceeding the limits documented here.
How can I find the processing speed for a specific search? - Every search request returns a value called processingTimeMS which is the time that the server took to process the search request. If this value is low, it means that the Algolia cluster processed the search quickly. Additionally, processingTimingsMS values provide a breakdown of the latency.
How to find the cause of the issue in the network
Run our diagnostics script - If you are calling Algolia from your own back end
To get more details on the cause of connectivity issues, you can run our diagnostic script from the server being impacted.
- Ensure that you replace YourAlgoliaApplicationId with your actual Algolia application ID.
- For Linux or macOS servers run: curl -sL https://algolia.com/downloads/diag.sh > ./diag.sh && sudo ./diag.sh YourAlgoliaApplicationId
- For Windows servers download the Powershell version of the diag script from here and then in Powershell run .\diag.ps1 -appid YourAlgoliaApplicationId
- The script will take a few minutes to run
- When it's completed it will give you a name of the output file.
- Send the output file to us through a support ticket so we can analyse the output.
Run our diagnostics script - If you are calling Algolia from your front end
If the issue is isolated to the browser front end, head over to community.algolia.com/diag/ and send us this output instead (run from the same browser seeing the issue) -- make sure you use the “advanced options” to include your specific app ID, search API key and index name instead.
On MacOS, Linux and Windows client environments (meaning non-mobile clients), it is also recommended to run the diagnostic script - the output captures more details than the browser diagnostic tool, which is helpful for us to diagnose the issue.
You can reach out to the support team if you have any questions or need help running the script. Once you have sent the Support Team the results we can advise on if there is an issue in the network.