Shulou(Shulou.com)06/03 Report--

This article mainly introduces "what are the commonly used performance optimization methods". In the daily operation, I believe that many people have doubts about the commonly used performance optimization methods. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the doubts about "what are the commonly used performance optimization methods?" Next, please follow the editor to study!

SQL optimization

When the response time of the interface you develop exceeds that of 200ms, you have to optimize it. Of course, 200ms is not an absolute value, depending on the application scenario. Take App as an example, if you call 5 APIs on a page (beside the point: you can also do aggregation), then the total time is 1 second, which is OK for users. Of course, the faster the response, the better.

The interface is time-consuming 200ms, in which database operations account for the majority, and there will be N database operations in one interface. So the speed priority of optimizing SQL is the highest, and a large number of slow SQL will drag down the whole system.

The optimization of SQL is not the focus of this article, most of the slow SQL still has something to do with your usual development habits. Most of them will not consider the performance when writing SQL, as long as they write it out. Join will come at will, without combing the query fields or indexing. It will be cool when it comes to concurrency and data volume.

You can refer to this article about the usage specification of the database: the boss asked me to sort out the mysql usage specification within the company and share it with you.

When the amount of data is large, we must do read-write separation and sub-database sub-table, which is also the only way to optimize.

Separation of reading and writing

Sub-database sub-table

Reduce repeated calls

Another fatal problem with poor performance is repeated calls, with the same logic repeatedly querying the database in different methods, repeatedly invoking RPC services, and so on.

For example, the following code:

SkuDao.querySkus (productId) .stream () .map (sku-> {skuDao.getById (sku.getId ());})

Obviously, the data has been queried, and it has been queried again according to ID. The more the number is, the more time is wasted. Here is just an example. I believe there are a lot of repeated queries in real projects. I also wrote an article before to explain how to solve this problem of repeated queries. If you are interested, you can check out this article: it's a coquettish operation, and ThreadLocal can also be used as a cache.

Query on demand

Many functions that are not complex in business logic are slow to respond. Often when writing code without thinking, casually call some existing methods, causing the overall response to slow down, to sum up: most of the performance problems are written by the code.

Tell me a scene, everyone must have seen it. The parameter is a commodity ID, the function is the commodity on the shelf, needs to carry on the status judgment, meets the condition can be on the shelf. In this scenario, you only need to get the status of the product to judge, and sometimes the code you see is in the following ways:

GoodsDetail goods = goodsService.detail (id); if (goods.getStatus () = = GoodsStatusEnum.XXXX) {}

There is a lot of logic in detail, in addition to the basic product information, there are many other content, which is the reason for the slow.

Parallel call

For an interface, if we design multiple internal RPC services or multiple external interfaces, if there is no correlation between the interfaces, we can use parallel calls to improve performance.

CompletableFuture is very suitable for the scenario of parallel calls. This article does not elaborate on the use of CompletableFuture. Anyone who does Java should use it.

In addition to CompletableFuture, for the processing of collection classes, you can use parallelStream to implement parallel calls.

In micro services, there is a layer dedicated to aggregation API, and the aggregation layer is very suitable for parallel invocation. A function or a page presentation will involve multiple interfaces. Through the aggregation layer, interface aggregation and data clipping will be carried out at the back end to respond to the front end together.

Caching on

Caching is also the most commonly used in optimization, with the most obvious improvement and low cost. Don't abuse caching, either. Not all scenarios can rely on heap caching to improve performance.

First of all, for business scenarios with low real-time requirements, you can give priority to the use of cache, and you don't have to think too much about updating, just expire naturally.

For business scenarios with high real-time requirements, there must be a complete cache update mechanism to use cache, otherwise it is easy to cause inconsistency between business data and cached data.

The recommended practice is to subscribe to binlog to update the cache uniformly, and do not update or invalidate the cache in the code. Simple scenarios are fine, and there are only a few entries, which is not a problem. Some data is used in multiple scenarios, and there are too many entries to update.

Asynchronous processing

Some logic can be processed asynchronously in the background without real-time feedback to the user.

The most common way of asynchronous processing is to add the task to the thread pool for processing. The thread pool needs to consider the capacity and the monitoring of some indicators. Related articles can check out my article: temporarily tickled, jerked off a dynamic thread pool, the source code put Github

In addition to monitoring some metrics, another concern for the use of thread pools is task persistence. If your data is already stored, it's okay to read it out and execute it through the thread pool. If there is no persistence thrown directly into the thread pool for execution, there is a possibility of loss, such as a service restart scenario.

With regard to persistence, whether it is thread pool or EventBus, it will be encountered, so for asynchronous scenarios, I recommend that you use message queue.

Message queuing can store task information to ensure that it will not be lost. Separate consumption of messages from the queue for logical processing, if you want to improve the consumption speed, you can also use thread pool for multithreaded consumption at the consumer side of the queue, and multithreaded consumption should also avoid message loss. You can check out my article: Shh! Is it really good to use asynchronous events this way?

JVM parameter adjustment

In general, we don't have to adjust the JVM parameters. Occasionally some code is not well written, resulting in memory overflow, this time will make some adjustments and optimize the code.

The main purpose of parameter adjustment is to reduce the pause caused by GC. If your program has been in GC and has been pausing, your interface will naturally be slow.

As long as there is no frequent Full GC, the parameter adjustment of optimizing this JVM can be done at the end, giving priority to SQL optimization.

Add machine

Add the machine is the ultimate move, and the volume up, you in how to optimize the single machine and single database anti-concurrency ability is also limited, this time can only be extended horizontally.

If it is in the early stage of start-up, and in the rapid development, adding machines is the most direct way of optimization, although the cost has gone up, but the development resources are also costs, saving can achieve more business needs. Wait until it is stable in the medium term before considering the architecture, overall optimization and refactoring of performance.

Just like playing games, equipped players are arrogant, and the same is true for back-end applications, such as high-equipped machines, high-equipped database configurations, high-equipped caches, and so on.

At this point, the study of "what are the commonly used performance optimization methods" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.