Performance test-response vs latency vs throughput vs Load vs scalability vs stress vs robustness

This article is translated from Niraj Bhatt performance Testing-response vs. Latency vs. Throughput vs. Load vs. Scalability vs. Stress vs. Stres S vs. robustness. Original address: https://nirajrules.wordpress.com/2009/09/17/ measuring-performance-response-vs-latency-vs-throughput-vs-load-vs-scalability-vs-stress-vs-robustness/

Usually I find that when people talk about performance tests, they are always vague and confusing. Some people just limit performance testing to response time, whereas others try to use performance tests to cover all aspects of the test activity. In this blog post, I will explain some of my own views on the difference between these two views. In the field of performance testing, you will often hear some nouns that have-response time, delay time, throughput, load, scalability, stress, robustness, and so on. In the following article, I'll try to explain these nouns at the same time and briefly describe how to measure and evaluate them.

Response times (Response time)-The time it takes for the system to process this request after it has received a request. For example, if you have an API, you want to know how much time it takes for the API to execute a call, and you are actually measuring the response time. So how exactly does the response time measure? Simply put, use a code table (system.diagnostics)--start it before the call, and stop after the response is received. The interval will be very small, so the recommended practice is to loop through the API, say 1000 times. Or, if possible, pass in the load parameter at the time of invocation (input/output has KBS/MBS/GBS. For example, returns an array of users of different lengths)

Delay Time (Latency)-The simplest explanation is that it is the response time of a remote call, such as a Web service or a Web page you want to access. In addition to the time that the server needs to process the response, it will take some time to upload the request from the client to the server. So when it comes to delay time, it's just the time of delay. This is a big problem for remote data centers that host Web services/Web pages. Imagine your visit to a data center in the United States from India. Although the delay time is difficult to improve and shorten, but it is very important to measure it. How do we measure the delay time? Some tools for simulating network conditions can help you, and here is one of the tools.

Throughput (Thoughput)-The number of transactions that your app/system can handle per second. A typical enterprise application will have many users performing a variety of different transactions. Before the system is formally put into use, you should ensure that your system meets the capabilities required by your enterprise applications. In this case, the load test (testing) can be considered a solution. The strategy is to pick some transactions (often occurring, important, intensive) to look at a service level contract between SLAs (service levels agreement-provider and end users). is used to define the pass rate within the time frame that is expected to be obtained from the service provider. How to measure it? You usually need a high-end professional tool such as visual Studio Team System (load Test feature). Of course, you can use some custom applications/code to simulate the load. But my experience is that the custom code is more suitable for testing response times (Response time). Given the amount of work required to write custom code, a good load test tool, such as VSTS, allows you to select a range of transactions, simulate network latency, add user think time (real user response time), test iterations, and so on. I also strongly recommend that the load test use real data to be infinitely close to real-world usage scenarios.

Extensibility (Scalability)--Extensibility represents how your system will react after adding additional hardware. Can the system use the newly added resources to handle the increased load? This is extremely important for your system, given the potential for future growth. Here we have two options-scaling up/vertical (with better machines), or scaling outward/horizontally (using more machines). Generally speaking, the latter is more popular. One of the challenges of horizontal scaling is that your design cannot include some closely related (coupled) servers so that the load balancer can adjust the load between different servers. With the help of the load Balancer tool with built-in software or hardware NLB (Network Load balancer), you can measure the scalability of the system and ensure that the system is able to assume the additional load without any problems. One tool can monitor performance counters to check if real requests have been dispatched and shared between servers (I plan to talk about NLB in a future post).

Stress testing (Stress testing)--Many people are confused about stress testing, or confuse it with load testing. The simple explanation is that if you find yourself running tests for more than 24 hours, what you're doing is stress testing (more precisely the actual working time/online time of the system before you stop the system in order to hit a patch). The motivation of a load test is to measure your system's ability to return to normal under overload conditions. Can the system be restored to normal or completely collapsed? Robustness can be seen as part of a stress test for long-running, virtually non-downtime systems. A simple example is a memory leak. Does your system release memory after processing the peak load? Another example is what happens if a disk fails due to a heavy I/O (input/output) load. Will your system lose data? Finding and locating these potential risks is the motivation behind the stress tests.

Performance test-response vs latency vs throughput vs Load vs scalability vs stress vs robustness