horrible , Mean response time 150ms, In addition, other problems were found in the process of pressure measurement , Background error , It turns out that OpenSearch Limit queries per second
1、 modify OpenSearch To configure , And will be pressure tested in the environment OpenSearch Change the connection address to the intranet address .2、 Change the place of cyclic query cache in the code to one-time batch query return .3、 Confirm with related students and remove useless code from the project .
While optimizing the code , Changed configuration , But it's worse , And there are new problems . at that time , Checked the code over and over , The number of times to determine the query cache is minimal , And the connection thread pool parameters are also adjusted to a relatively large and reasonable value . If , If the re pressure test still can not meet the requirements , There is only one last move ： Caching result sets . namely , To the user ID And user search keywords are key, The result of the query is value, cache 5 minute .
It finally meets the requirements , Concurrent 60 When the response time reaches 32ms, And I found a new optimization point .
Interface actually has the operation of checking database , This can't be tolerated , After the investigation, some unnecessary dependencies were removed .
Learned to use RedisTemplate Of executePipelined Conduct redis Batch query
1、 Be sure to avoid circular queries on databases and caches （PS： There can be no query cache in the loop , Not to mention the operation of querying database , Because the number of cycles can't be controlled ）;
2、 about API Interface , In general, it's directly checking the cache , I didn't check the database ;
3、 Multi use batch query , Use less single query , Try to find out ;
4、 For using alicloud , Pay attention to the configuration of corresponding products , The money that should be spent still has to be spent , meanwhile , Remember to use the intranet address of the corresponding product in the formal environment ;
5、 Pay attention to the connection pool size （ Including database connection pool 、Redis Cache connection pool 、 Thread pool ）;
6、 Do not deploy other services on the pressure measuring machine , Only the services to be tested , Avoid being affected by other projects ; For online environments , It's best to deploy only one important service on one machine ;
7、 Useless and commented out code , It's better to clean up the useless dependence in time ;
8、 Clusters don't have to say ;
9、 Some monitoring tools can help us better locate problems , For example, link tracking , Used in this project PinPoint;
10、 If the space for technical optimization is already very small , Try to start with business , Speak with actual data , From daily visits , Historical traffic data to convince the test ;
11、 Every code change has the potential to introduce new problems , therefore , Every time you change the code, you need to do regression testing （PS： After each revision , I will use several different keyword search , Then compare the data returned before and after modification to see if they are consistent , This is the time postman, as well as Beyond compare That comes in handy ）;
12、 The key point is to add more logs , It's convenient to eliminate problems later , Because the most important way to troubleshoot online problems is through logs ;
Three gold and four silver are here , Give a small benefit ！