Thoughts on stress testing

Ideas:

The stress testing, SQL optimization, memcached optimization, SQL stress testing, and other simulated samples are tested to form a series of methods to prepare our knowledge reserves for possible future situations. Of course, at present, our small systems do not need such optimization, but may only be improved by less than a millisecond. However, we are working out the solution, not to optimize it, we need to develop a set of ideas that will be followed by all development optimization ideas in the future.

I. Implement code-level stress testing

 

1. Use the simplest webshells for testing, and do not use complicated software such as Load Runner. Leave the complicated stuff to the test team's sisters.

2. Add code to the action that may be accessed by many people (or obtain which action is used by many people through druid), and complete the serialization of the number of people who may need ginseng, for example, if this action requires a person ID as a parameter and returns the basic information of the person, we extract the person ID of 100 people from the person table to form an array and write a random method at the action entry, obtain a value in this array as the random access person ID, which basically simulates the real situation.

3. Use webbench to simulate multiple accesses to this action and view the pressure limit.

4. Other actions perform the same test. After the test is completed, paste the test result into the action code, which indicates that the test is completed and is convenient for the project manager to check.

5. After the test is completed, comment out the parameter sequence and random code.

Expected completion time: 1 day

.

Ii. Change the idea that memcached can only cache specific data, so that memcached can cache all the data after sorting in one section.

Then, the Java end uses array or list operations to extract the data that the user really wants. For example, the user provides a TS, 100, and the database stores 200 records, then we cache all the 200 records, and then retrieve the 200 records in memcached during user requests. Then we use Java to remove the first 100 records and only return the last 100 records to the user. This idea is very effective for solving specific problems. We need to conduct further experiments to clarify this idea so that we can use it in a large amount in designing other caches. In this way, we will no longer limit memcached's fear of parameter changes, and will not initiate requests to the database if the parameters change significantly, provided that we have an excellent design philosophy. Estimated time: 2 days

 

Iii. memcached push problems.

If memcached is used for a large number of queries, if there are many people and all data is not cached at the time of launch, all requests will be sent to the database, which is the avalanche effect, to solve this problem, we can consider using the push method. What is our push solution? Initially, I thought it was a Java project. I executed SQL statements one by one, and saved the results to memcached according to the rules. After the preheating, I started Tomcat again, this will greatly increase the user's initial access speed. As for how to execute SQL statements and what SQL statements to execute, the specific problem is analyzed. It should be similar to the code written in AOP. In the future, you can also find a way to extract the code in AOP and share the Code with the push.

Reference: http://www.cnblogs.com/sunli/archive/2010/09/06/cache_expire_same_time.html

Estimated time: 4 days