Tracking Usage and Performance in the Dashboard
The Dashboard presents key information about performance and usage activity. You can use it to get a good understanding of the activity on your Algolia account—like knowing what your users are doing, and how fast, and what sort of API operations are being performed. All this provides an open window into your application’s API usage.
This information helps you in two significant ways. First, to help you tweak your data and index configurations to achieve greater relevance, speed, and efficiency. Secondly, to offer you a simple way to monitor the billable activity of your account.
This tutorial will focus on the API Monitoring Dashboard Section. If you aren’t familiar with the Dashboard, please take a look at the Dashboard Overview tutorial.
As you go through this tutorial, you may want to experiment with different searches and indexing operations to help make these metrics concrete and meaningful. You can do this with your API or within the Indexing section of the Dashboard. Ultimately, the goal is to give you more control over the Algolia search engine.
Performance metrics
Performance is a good place to start—click on the API Monitoring section in the sidebar, then the Performance section.
On this page you’ll see a full view of the number and speeds of your search operations. These figures are broken into 90% and 99% percentiles. You can also view graphs over a day, divided into hours, over the past month, and over the past year. Note that the speeds measured here are the times it takes the Algolia server to process a search request.
The Queries per Second view can be used to check whether large user search activity has any impact on performance.
Measuring speed
Algolia measures performance in milliseconds. Larger values might indicate a performance problem. Additionally, since processing time only measures the speed of the Algolia servers, you need to add network latency and front-end display times to measure the full user experience. Delivering the best UX means that the total time, from keystroke to displaying search results, should be less than 100 ms, as this delivers a real search as you type experience. Thus, with this 100 ms benchmark, and an average latency of 70 ms, the engine’s processing time should be no greater than 30 ms, and ideally a lot lower.
Usage activity
You can see your total number of records, as well as the number of search and indexing operations performed during the current billing cycle, under the Usage tab. The Records graph shows your total number of records. Whether you have a monthly or annual subscription, these figures will always reflect your application’s monthly usage. which will be used to generate an invoice at the end of your billing cycle.
In this section, you have as well a variety of timelines that trace your API usage. These too are broken down by hour, day, and month, for up to a year. The first of these displays the fluctuations of your total indices size over a fixed period of time. The remaining timelines display the execution count of nearly every operation within the API. These latter timelines are divided into seven kinds of operations - Search, Indexing, Record, ACL, Synonyms, Rules and Recommend - each of which are further divided into their associated API function calls.
As an example, look at the “Records Operations” graph. On the top left, you see 7 record-based operations: Get, Add, Batch, Delete, Partial update, Update and Delete by Query.
To make things easier, you can also hover your mouse over the timeline to get a tooltip snapshot of all related operations for that particular hour, day, or month.
Note that usage statistics don’t include indexing operations on replicas, because keeping replicas in sync is done internally by the Algolia engine.
Status section
Up to this point, this guide has described the performance and activity of your API usage. The next sections discuss infrastructure, specifically the latency and processing speeds of your servers, clusters, and DSNs.
Latency averages
The first page provides a graphical view of average latency times, with a coloring system to immediately alert you to the working state of your clusters and servers. If you have more than one cluster, or any DSNs, these will be viewable as separate graphs. To see clusters or Distributed Search Network (DSN) node statistics independently, click on the corresponding tab under the Your Server section.
The latency figures on this first page are a total average of the individual averages described below. You can hover over the graph’s timeline and trace the average latency, calculated every 10-minutes.
Colors
Algolia uses clusters to process every indexing and search operation. This is primarily done for redundancy reasons: if one server goes down, there is no impact on search and indexing operations, the cluster remains at 100% availability (green). Furthermore, if a second server goes down, the remaining server still processes search requests (100%), but no indexing operations (yellow). In this situation, indexing operations are queued, to be executed only after the cluster returns to its green state. Finally, if all 3 servers are down, the cluster is down and the indicator turns red.
As previously mentioned, measures are done in 10-minute intervals, so a cluster’s availability (color) can change every 10 minutes.
This map displays the worldwide location of Algolia’s probes. To understand the latency calculations, you’ll need to understand what these probes do. Algolia currently has 30 computers (probes) strategically positioned all over the world to measure regional latency speeds. How this works is as follows. Each probe performs the following 2 operations.
- Sends a signal to every server in every cluster, and measures how long it takes to receive a response. This is the Ping test.
- Makes a simple API request and also waits for a response. This is called the API test.
The ping test is designed to test simple computer-to-computer speeds. The API test goes a step further and tests not only the response time but also the functioning state of the server. For example, if a server can’t perform a simple indexing operation, or if the processing time slows down the response, there is a problem.
Other features
Latest operations
In the Search API Logs section, you can watch as operations are being executed on Algolia’s servers, in a continuous, real-time scroll.
Alerts
There are several types of alerts to be aware of.
Status, where you set up either an email or a phone number to receive incident reports as they occur. The kinds of incidents reported are discussed in the API Status section.
Capacity, where you set up one or more Capacity Alerts to warn you before your servers overflow on memory and CPU usage. As you can see, the threshold for each metric can be configured. Take a look at the tutorial on How to set up capacity alerts.
Only plans with dedicated servers can receive capacity alerts.
