In large application projects, the pressure test of the core business system is an important part. Before the system is online, or in the development process of the application is required. This paper combines an actual large project, analyzes and studies some of its considerations and problems in the design and specific implementation of the pressure test scheme, and proposes a relatively universal system-based real data test method, and detailed Discuss implementation methods, and then discuss issues related to the relevant attention.
TUXEDO is a mature transaction processing middleware, generally used for business processing of large systems. In such a system, the general client request has a large number of days, and the real-time requirements are high, and one transaction is required in the specified time, and the result is returned to the user. Moreover, the stability requirements of the system are also high, and 7x24 is required to operate. In order to meet the above requirements, in addition to the various parts of the system, it is necessary to test and evaluate the system's processing capabilities, limit capacity, and the like before the online, in order to obtain a more real performance of the system. This test is from the outside to observe the overall situation of the system, which is more practical than the performance ratings of some part, and makes project developers and subsequent operating maintenance personnel have a specific understanding of the overall performance of the system. Adjustment and future maintenance.
Next, the author is based on a large telecommunications project that has been developed, and combines some of the methods and processes in the pressure test in combination with the Tuxedo server pressure test tools you designed and implemented, and the questions you should pay attention to.
The pressure test must have a certain number of concurrent clients. In order to test, prepare a large amount of PC, and it is unrealistic, and it is difficult to do real concurrency, which is not conducive to a large number of tests that the client is constantly changing, so we use software simulation clients. method. For Tuxedo servers, each client is a process of communicating with it, so how much client is simple to say is how much the process of calling services, this is easy to implement in OS. There is a problem with a problem to discuss, which generally wants to do with an off-the-shelf pressure test software. In practice, this approach is problematic. The general pressure test tool is to intercept a CLIENT to Server calling packet, analyzing the data, then parameterize some data, such as some ID, then generate a script that can generate a large number of concurrent similar packets, run This script can perform a pressure test, of course, which includes a lot of metrics. This method can work well for some applications, such as new account, etc., which is difficult to achieve for services that require high data authenticity. For example, the main Tuxedo service involved in the pressure test made - the query and pin processing of the user bill. Since the user's phone number or account, etc., there is a lot of cavities, and the service is based on the return result of the query, if not the database, a real-footed bill is Find a successful completion of the project. This brings a lot of difficulty for constructing, and that constructed data and practical situations will have a big gap, as it may be optimized by buffering of the database, and cannot reflect the real performance, and the best The way is of course real data in the actual database. Of course, this kind of truth can also have a certain expansion, and the following will involve preparation questions about pressure test data. Through the discussion above, we know that in some actual systems, let the people who understand the system apply themselves to do pressure tests. Many times they are a better choice. Don't worry about the complexity of this job, let's take a detailed analysis of the relevant questions.
1. Simulate the specified number of clients.
On the multi-process requires OS support, the following is given as an example as an example of Unix. It is necessary to pay special attention to the line of code with *, the meaning of the row is in the child process (PID = 0, the Fork has different returns to the parent process and the sub-process, and the cycle will no longer perform this loop in the reference [1]). In UNIX, the child process starts from the next sentence of fork (). If there is no mention, the newly opened child process finds the conditions that meet the for loop will continue to perform a loop, open its own child process, which will generate a complex process tree, which can calculate the child process The number is. In order to better control the number of clients and the conciseness of the relationship between the process, we pass the relationship between the above, and the number of processes is equal to P_NUM.
For (i = 0; i { IF ((pID = fork ()) == 0) Break; // * IF (PID <0) exit (0); } IF (PID == 0) // Sub Process Code { Child_process (); } IF (PID) // Parent Process Code { ... } With the above code, we have a clear understanding of the generation of the client. After the process is created, the parent, child process is bleed, and the respective pressure test is started. 2. The acquisition and delivery of system real data Above we discussed the importance of real data on the credibility of the pressure test results, the current problem is how to design a data flow that gets data in the database and passes the client to the calling service. This premise is that we are more familiar with the tested services, understanding its approximate process and the data involved. Take the bill of bills as an example, it requires a sales method, operates the employee number, part of the information involved, which can be obtained by the user's input and bill query services. User input We can set in the test program, the billing information We can get the query service before you call, because the bill is always done after the bill query, so this process is also in line with the actual situation. The next question is that the billing query is also a valid input parameter. How do we get these data? The answer is naturally still from the database. In the real system, the bill query is the reception of the user request. According to the user's phone number, the bill is queried, where we can take a batch of information (telephone numbers, etc.) with bills in the database (phone number, etc.) Input conditions. Because this taking the number of operations is not overhead of the real system, we can do before the simulation client starts running. At this point, we have a probably aware of the process of data. Below is the specific implementation problem. The number is taken one-time, and the number of tests is required according to the test, and we can save it in a large array, and we can see the benefits of this data structure. Get the most basic input, we can start the design of the data stream inside the pressure test program. 3. Father, child process work and data communication To ensure concurrency, each Client process should be independent, and itself runs must last for a while, so that a large amount of stable connection is generated at one end of the Tuxedo server, and thereby generates call to form a pressure. Each client process works to get a number, call the service to obtain the billing of the corresponding user, then finalize the result, join the operator information, then call the bill service, get the return result. Each client repeats the above process, the number of repetitions is used as a parameter n, which is configurable, p_num * n is the number of numbers that need to be prepared, the two parameters need to be selected by combining the requirements of the test, by changing them can do Multiple different tests. The work of the parent process is to get the number to the array, then generate P_NU a simulated client, which will be distributed to these clients so that each Client can operate continuously. The number array mentioned above is equivalent to a grain warehouse, and the parent process is to supply the sub-process stable food supply to cause a pause because of "hunger". Analysis of the data here, there is still a feature that each data is one-time and cannot be used again. The parent process can be easily guaranteed by the subscript of the array to ensure that the data is not repeated, which also reflects the concise efficiency of the array in this case. In the process of parent process delivery data to the child process, we have considered a queue to implement because the data to be guaranteed is unique, and each sub-process is best to obtain data from a known location. This makes it easy for the number of sub-processes to scale, and the queue can meet these requirements. Since the queue is controlled, a large number of child processes may be waiting, but in the actual test, we find that this impact is small. When the number of clients is about 1000, it is still not obvious, so we can think The queue is efficient. Of course, the problems here may also have a better solution, and the queue is relatively simple and clear. The pressure test program must return the corresponding result, such as the time consumption of each call, etc., which will not be described in detail herein, and can be implemented according to the actual needs. 4. Schematic diagram of the test system Through the above discussion, we have aware of the processes of the main body and data of the pressure test procedure. The above is also a place where the pressure test scheme is different from the general pressure test tool. Below we give a sense of understanding through a schematic. 5. Tuxedo parameters adjustment In order to match the pressure test, some parameters of the Tuxedo server need to be adjusted. The main parameters involved are the following: Maxaccessers The maximum number of visitors, this contains multiple clients, greater than p_num * 1.2 (reference value). Maxwsclients The maximum number of WorkStation Client, requires greater than p_num. WSL-M 2 -M 30 -X 10 The number of WSHs and each of the concurrent processing capabilities. M is the initial number of WSH, M is the maximum number of WSH, and X is the number of ws clients acceptable for each WSH. Require M * x> p_num. The above is a few major parameters, because the number of connections is subject to License, users are not very large, so further testing can find a large number of Trial License with a large number of users. About Tuxedo's configuration can refer to the appropriate documentation, which will not be described in detail here. 6. Test data generation Since the pressure test is to run for a long time, and if it is tested many times, including different configurations, the real data is often insufficient, and the above test method requires that the data is in the database. . For this problem, we can generate some data that meet the requirements according to real data. Now general DBMS support INSERT ... SELECT statement, which can generate a large amount of available data by the following method. Assuming a record of a table with the record_id as the primary key, max (record_id) = m; through the following SQL statement: INSERT INTO TABLE_NAME (Record_ID, ...) SELECT RECORD_ID M, ... from Table_Name, you can make the number of records in the table Double. According to this type, you can increase the data volume index level, and these data is different from some identified IDs, others are more blueprints, which is better than purely data manufactured by test programs. Tuxedo service. The requirements of the program, the actual test also proves this. Moreover, through this method, combined with the prediction of business growth, we can simulate the performance of the system after a certain period of time. 7. Extension of the test The above is mainly tested for Tuxedo service programs, in fact, the above test methods can be used to perform other tests. Here is the two main aspects: First, some load balancing mechanisms of tuxedo, by concurrent operation of a large number of Clinets, the configuration is the most appropriate for specific hard software configurations. The second is to analyze the ways of connecting Tuxedo and databases. At present, Tuxedo connects the databases mainly have two ways of XA and Server. The above methods can also be evaluated to evaluate the actual effects of these two ways. 8. I have to pay attention to the problem that can be improved In order to make the results of the pressure test, there are some questions to be aware of the problems. First of all, the pressure test and real cases have a big difference, all clients are on a machine, rather than distributed in a real environment in a very much PC, so that the performance of the machine where the test program is located. A certain requirement. In the actual test, we adopted a Unix small machine close to host performance, which can still meet the requirements when simulating the number of clients. If there is no high-performance test machine, it can be distributed on several machines and run the test program. In addition, some of the core parameters of the operating system also need to consider and do corresponding adjustments. For example, the capacity of the queue in the general UNIX system is 16KB, not very large, and some IPC values have a certain impact on Tuxedo performance, because tuxedo uses Q , SEM, SHM and other IPC communication mechanisms, there is a detailed explanation of this, Tuxedo official documentation. These can be adjusted with the system administrator. The internal data stream mentioned above can also be implemented in other ways. Some of the relevant parameters of the database server can also be adjusted, so that the main pressure is concentrated in the Tuxedo server, which is convenient to observe their performance under different loads, and the stability and fault tolerance in the case of load is very heavy, including self-recovery. ability. summary: According to the idea and method mentioned above, the author made a long-term pressure test as the project, and submitted the project manager and system administrator to formally stressful test reports, making everyone some overall performance of the system. Objective Understanding and evaluating, in order to meet the design requirements and successfully pass the acceptance, it has achieved better results. This test program is used for other service modules such as reports by simple configuration and modification. This article is that the author summarizes some methods and ideas summarized according to the above practice, and points out the problems that need attention, hoping to provide some reference to other systems design and developers in the face of relevant issues. bibliography: [1] John Shapley Gray, Unix Process Communication, Electronic Industry Press, 2001. [2] W. Richard Stevens, UNIX Environment Advanced Programming, Machinery Industry Press, 2000. [3] BEA, edocs for tuxedo 2004.4 HUST, Wuhan
