Statistics Dashboard
Basic statistics for your project
Last updated
Was this helpful?
Basic statistics for your project
Last updated
Was this helpful?
As you use the endpoint, you may be curious about your usage stats . For example, you might be interested in the usage trend of your endpoints over the past week or want to know the count of successful and failed requests.
In the statistics dashboard, you can find basic usage statistics to address your curiosities and provide insights into your usage patterns.
You can get instant metrics about overall health of your project in one place. This part consist of filters and statistics summary.
You can select the protocol and network in the filter to refine the data displayed on the statistics page.
Response Latency (Median, 5 min)
This is a value that refers to the middle value of latency observed over a specific period, which in this case, 5 min. Median latency helps provide insights into the central tendency of latency and can be useful in understanding the typical or representative latency experienced during that specific time interval. (FYI, “Latency” is a metric used to measure the amount of time it takes for a server to respond to requests.)
Requests per second (1 min)
Requests per second (RPS) is a metric used to measure the number of requests sent to a server per second. The RPS on the statistics dashboard is calculated based on usage within the last 60 seconds. If you send a large number of requests at the same time, your request may fail due to the throughput limit. The throughput limit varies depending on the plan you are subscribed to.
Response Success Rate( %, 24 hour)
“Response success rate” refers to the percentage of times that a request is sent and received response successfully. This includes both valid and invalid requests, but excludes failed or throughput-limit-touched requests. The distinction is made because successful and invalid requests have received a proper response, consuming your daily request quota. On the other hand, failed or throughput-limit-touched requests either failed to send a request or did not receive a response, thus not consuming your daily request quota.
Throughput limited Rate (%, 24 hour)
"Throughput limited rate" refers to the percentage of requests that are restricted due to the throughput specified in your subscribed plan. These blocked requests do not count towards your daily usage quota. The throughput limit varies depending on your subscription plan. To find the throughput limit for each subscription plan, please check here.
Total Usage represents the overall usage of your project. It includes all the successful and invalid requests that sent up to the current point in time. The total usage graph represents the trend over a period of either 7 days or 24 hours, and each time unit also displays the value from the previous cycle. For example, in a graph showing the usage trend over 7 days, it also includes the values from the previous week. In the case of 24 hours, it includes the value from yesterday as well.
Today's Usage displays the usage data from UTC 0:00 until the current time. It provides information about the usage, activity, or consumption of a project during this period, allowing users to track and monitor their usage.
Success Rate includes successful and invalid request. The reason why the success rate includes both successful and invalid requests is that both types can receive a proper response and consume the usage quota. Although invalid requests may not have achieved the desired outcome, they still receive a response and utilize the allocated usage quota. Hence, including both successful and invalid requests in the success rate provides a comprehensive measure of the overall request performance and resource consumption. The success rate is calculated by dividing the number of both successful and invalid requests that receive proper "responses" by the total number of requests made.
Your requests can return various types of responses. Here are detailed explanations of the response types:
Successful: This response indicates a successful request. It means that the client received the desired results successfully. Successful responses signify normal service operations.
Invalid: This response corresponds to an invalid request. It occurs when the client sends an invalid or malformed request. Invalid responses indicate errors in the client's request.
Throughput Limited: This response is generated when the request is restricted due to throughput limitations. It indicates that your service sent too many request in a certain time period. Throughput Limited responses has "429" response code and do not consume the daily usage quita.
Failed: This response indicates a request that couldn't be sent. It occurs when the All That Node's server encounters an internal error or an unexpected issue, resulting in the failure to handle the request. Failed responses signify errors or issues within the service. Failed responses has "500" response code and do not consume the daily usage quita.
The throughput graph displays the request processing amount over a 24-hour period, categorized by time intervals. It visually represents the trends in request volumes during specific time periods. The graph shows the number of requests over time, enabling the analysis of peak times and variations in daily user usage pattern.
The "Max Throughput" indicates the highest number of requests per second (RPS) recorded during a 24-hour period.
In the "Command" section, you can find the top 5 most frequently used commands based on a 24-hour period. It shows the number of times each command was used and their respective median latency. This information helps identify the most commonly utilized commands so that provides insights into the service's core functionalities and user usage patterns. Also this section provides insights into their performance based on the median latency, allowing for further analysis and performance optimization if needed.
The whisker chart, used to visualize the median latency, represents a distribution of response times for that particular command.
The chart displays a box that represents the distribution of response times. The box's boundaries represent the lower quartile (Q1) and upper quartile (Q3), indicating the range within which the majority of response times fall. The line inside the box represents the median latency, which is the middle value of the response times.
Additionally, "whiskers" extend from the box to show the minimum(1%) and maximum(99%) response times, the chart does not show the outliers unlike the standard box plot. These whiskers provide insights into the fastest and slowest response times observed for the command.
Overall, the whisker chart helps analyze the distribution of response times for a specific command, showcasing the range, median, and outliers to gain a better understanding of the performance characteristics and variability of the command's response times.
For more details about box-whisker plot, check out here.
Node uptime is a crucial metric in blockchain networks as it indicates the reliability and availability of the node. It measures the continuous period during which the All That Node's node is connected to the blockchain network and functioning properly.
99.9% node uptime means that the node has operated without any interruptions or issues for 99.9% of the total operating time. The percentage is calculated by dividing the total uptime (time without interruptions) by the total operating time and then multiplying by 100.
The "General Uptime" refers to the uptime for all protocols in this project over the past 90 days. It represents the total amount of time the protocols have been operational without any interruptions or downtime during the specified 90-day period.
