Tipsearch engine testing experience

ArticleThe blog from the old Chai Development Team is original. The author Lucifer is the testing engineer of the current department.

 

The performance test of the tipsearch engine has just ended. In this test, we have been struggling for a long time, mainly due to two problems:
1. added multiple requests to a transaction.
Incorrect understanding of the test items. When editing the script, multiple requests are placed in one transaction, which leads to a large difference in the test results. The corresponding performance indicators are not reflected according to the number of concurrent sets.
Summary:
Things: a collection of operations performed by a user in one or more steps. When we need to measure the server performance through one or more operations, we will set these operations as a transaction.
This test should set a request in a transaction, instead of placing multiple requests in a transaction.
2. Too many failures occurred during the test.
During the LR test, there are too many errors and the error messages are:
Action. C (7): continuing after error-27796: failed to connect to server "192.168.18.250: 80": [10048] address already in use
Try changing the registry value
HKEY_LOCAL_MACHINE/system/CurrentControlSet/services/TCPIP/parameters/tcptimedwaitdelay to 30
And HKEY_LOCAL_MACHINE/system/CurrentControlSet/services/TCPIP/parameters/maxuserport to 65534
And rebooting the machine
See the readme.doc file for more information
The client settings are all set according to the value given in the error prompt, and there are still a large number of errors.
The reason is: the performance of the load generator is very good, the packet sending is extremely fast, and the server response is extremely fast. As a result, the port of the load generator machine is fully occupied before there is a timeout, that is to say, the last port is used and the previous port is not released. Therefore, many requests fail because the client port is exhausted and cannot connect to the server, it is caused by the limitations of the client itself and is not an engine problem.
Solution:
Today, I carefully analyzed the results of yesterday and made some experiments, which are summarized as follows:
If the request sent by the client is too fast, you can set the pacing value in the Controller's run-time setting, that is, set the interval between each request (this value can be precise to milliseconds ). This method can reduce the request startup speed for a single user and reduce the request resident time in the thread. In this way, the test results of the response time will be more realistic.
In this test, you can solve this problem by setting the pacing value to 0.001sec.
From-http://team.mapenjoy.com /? P = 79