Several terms for software performance testing

Response time

I identified the concept of "response time" as "the time required to respond to a request" and the response time as the main manifestation of software performance for the user's perspective. The response time is divided into two parts: render time and system response time. Where "render time" depends on the time it takes for the data to render the page after the client receives the response data, and "response time" refers to the time taken by the Java application Server to receive the data from the start of the request to the client. Software performance testing generally does not focus on "rendering time," because the rendering time is largely dependent on the client's performance. Here we do not use many of the concepts in software performance test definitions-"system response time" is defined as "the time that the application system takes from the start of the request to the last byte of data received by the client", and the reason for not using this standard is that Some programming techniques can be used to render when the data is not fully received, to reduce the response time that the user feels, and for the HNDLZCGLXT project, we use the former standard for the C/s system, and we still use the latter standard for B/s.

Number of concurrent users

I distinguish between "concurrent users" and "simultaneous online numbers," The standard of my "concurrent users" is that the number of concurrent users depends on the target business scenario of the test object, so before determining this "number of concurrent users", the user's business must first be decomposed and analyzed in a typical business scenario ( That is, the most frequently used and most concerned business operations), and then obtain "concurrent users" based on the scenario using some methods (mathematical models and formulas that compute the number of concurrent users). The reason for this is: Suppose an application system, the peak of 500 people at the same time online, but these 500 people are not concurrent users, because it is assumed that at a point in time, 50% of the people are filling in complex forms (filling out the form action on the server without any burden, only in "Submit" When the action is the pressure on the server system, 40% of people continue to jump from one page to another page (keep sending requests and responses, generate server pressure), and 10% people hanging online, no operation in a daze:) (no pressure on the server action). So only 40% of the people really pressure the server, from the example here, the number of concurrent users is concerned about not but the number of business concurrent users, but also depends on the business logic, business scenarios. Therefore we need the sixth part of this article software performance test documentation 4, 5, 6.

Throughput

I defined the throughput as "the number of customer requests handled by the system per unit of time", directly embodies the performance carrying capacity of the software system, for the interactive application system, the throughput reflects the pressure of the server, in the capacity planning test, throughput is an important indicator, it is not only reflected in the middleware, database, More on the hardware. We use this indicator in the following areas:

(1) To assist in the design of software performance testing scenarios, to measure whether the software performance test has achieved the expected design goals, such as the connection pool of the Java EE Application System, the frequency of database transactions, the number of transactions.

(2) To assist in the analysis of performance bottlenecks, referring to the second part of the overall RBI method.

Performance counters

Performance counters describe some data metrics for server or operating system performance, such as the number of memory used for Windows, CPU usage, process time, and so on, which are common counters. For performance counters, this metric requires not only hardware counters, Web server counters, WebLogic server counters, servlet performance counters, EJB2 performance counters, JSF performance counters, and JMS performance counters. Finding these metrics is the first step in using performance counters, and the key is to find performance bottlenecks, determine system thresholds, and provide optimization recommendations that are key to performance counter usage. Performance counters are complex and diverse, and are closely related to the code context, system configuration, System architecture, development methods, specification implementations used, tools, and library versions.

Think Time

I set the think time to "sleep time". From the point of view of the business system, this time refers to the user in the wake of the operation, the interval between each request, from the point of view of automated testing, to the real test simulation user action, you must be in the test script to allow for a period of time between the actions, The script is the placement of a think function between the operations, reflected in the interval between the two request statements in the script, and different test tools that provide different functions or methods for thinking time, such as HP Loadruner and IBM Rational performance The way of tester is completely different.

Several terms for software performance testing