The reason for the development requires an understanding of the concepts of throughput (TPS), QPS, concurrency, and response time (RT). It is checked from Baidu Encyclopedia, and the records are as follows:
1. Response Time (RT)
Response time is the time it takes for the system to respond to a request. Intuitively, this indicator is very consistent with people's subjective perception of software performance, because it completely records the time taken by the entire computer system to process requests. Because a system usually provides many functions, and the processing logic of different functions is also very different, the response time of different functions is also different, and even the response time of the same function is different under the condition of different input data. Therefore, when discussing the response time of a system, people usually refer to the average time of all functions of the system or the maximum response time of all functions. Of course, it is often necessary to discuss the average and maximum response times for each function or group of functions.
For a single-machine application system without concurrent operations, it is generally believed that response time is a reasonable and accurate performance indicator. It should be pointed out that the absolute value of the response time does not directly reflect the performance of the software, and the performance of the software actually depends on the user's acceptance of the response time. For a game software, a response time of less than 100 milliseconds should be good, and a response time of about 1 second may be barely acceptable. If the response time reaches 3 seconds, it is completely unacceptable. For a compilation system, it may take tens of minutes or even longer to fully compile the source code of a large-scale software, but these response times are acceptable to users.
2. Throughput Throughput
refers to the number of requests processed by the system per unit time. For a non-concurrent application system, throughput and response time are strictly inversely proportional. In fact, throughput is the reciprocal of response time at this time. As mentioned earlier, for single-user systems, response time (or system response time and application delay time) can be a good measure of system performance, but for concurrent systems, throughput is usually used as a performance indicator.
For a multi-user system, if there is only one user, the average response time of the system is t. When there are n users, the response time seen by each user is usually not n×t, but is often faster than n×t. t is much smaller (of course, it may be larger than n×t, or even much larger in some special cases). This is because a lot of resources are required to process each request, and because many of the processing processes of each request are difficult to execute concurrently, as a result, at a specific point in time, the occupied resources are often not many. That is to say, when processing a single request, many resources may be idle at each point in time. When processing multiple requests, if the resource allocation is reasonable, the average response time seen by each user does not increase with the number of users. Linear increase. In fact, the average response time of different systems grows at different rates with the number of users, which is the main reason why throughput is used to measure the performance of concurrent systems. Generally speaking, throughput is a relatively common indicator. If the maximum throughputs of two systems with different numbers of users and user usage patterns are basically the same, it can be judged that the processing capabilities of the two systems are basically the same.
3. The number of concurrent users The number of
concurrent users refers to the number of users who can normally use the system functions at the same time. Concurrent users is a more intuitive but also more general performance metric than throughput. In fact, the number of concurrent users is a very inaccurate indicator, because different usage patterns of users will cause different users to issue different numbers of requests per unit time. Take a website system as an example, assuming that users can only use the website after registration, but registered users are not using the website all the time, so only some registered users are online at a specific time, and online users will spend a lot of money when browsing the website. It takes time to read the information on the website, so only some online users make requests to the system at the same time at a specific time. In this way, for the website system, we will have three statistics about the number of users: the number of registered users, the number of online users, and the number of simultaneous requesting users. Since registered users may not log in to the website for a long time, using the number of registered users as a performance indicator will cause great errors. The number of online users and the number of users who send requests from colleagues can be used as performance indicators. In contrast, it is more intuitive to use online users as a performance indicator, and it is more accurate to use the number of simultaneous requesting users as a performance indicator.
4. QPS Query Per Second
The query rate per second (QPS) is a measure of how much traffic a specific query server handles within a specified time. On the Internet, the performance of a machine serving as a domain name system server is often measured by the query rate per second. Corresponding to fetches/sec, that is, the number of response requests per second, that is, the maximum throughput. (It seems to be similar to TPS, but only applied to the throughput of specific scenarios)