Writing in the front

Recently, many friends are saying that I have never done performance optimization work, I just do CRUD work in the company, and I do not have access to performance optimization related work. Now when I go out to find a job interview, the interviewer always asks some very difficult questions to embarrass me, many of which I can not ah! So what to do? I’ll just write down some easy interview questions related to high-concurrency systems. Today, we’ll talk about the metrics of performance tuning in high-concurrency scenarios, and what to look for when tuning.

The interview scene

Interviewer: Have you done any performance optimization related work in your daily work?

First, let’s analyze the interviewer’s question. In fact, in my own experience, when an interviewer asks a question like this. It’s not just a simple yes or no answer, per se. This simple question is intended to test the thinking ability and understanding of the interviewer. In essence, the interviewer wants the interviewer to tell the interviewer about his experience in performance optimization and his understanding of the theory of performance optimization. For example, it includes the measurement indicators of performance optimization and the problems that need to be paid attention to during the process.

If the interviewer doesn’t fully understand what the interviewer is trying to do and squeezesthe answers like toothpaste during the interview, most of the time the interviewer will assume that this person has no experience in performance optimization. At this point, the interviewer will be in the interviewer’s mind of the impression of a discount, the interview results have a very large probability of cool.

measure

When it comes to performance optimization, there are many metrics to measure, which can be broadly divided into performance metrics, response time, concurrency, open rate in seconds, and correctness. We can use the following figure to represent these measures.

Let’s take a look at each of these measures.

Performance indicators

Performance indicators can also include throughput and response speed. What we normally call QPS, TPS, HPS, etc., can be boiled down to throughput. QPS, TPS, HPS, etc.

• QPS represents the number of queries per second.
• TPS is the number of transactions per second.
• HPS represents the number of HTTP requests per second.

These are all throughput related measures.

When we do optimization work at ordinary times, we should first make clear what needs to be optimized. For example: are we optimizing to improve the throughput of the system? Or do you want to improve the response time of the system? A specific point of examples: such as some database in our program or the cache batch operations, while on the reading of the data, the response speed decreased, but the goal of our optimization is the throughput, as long as we optimized the system overall throughput increased obviously, and it also improved the performance of the program.

So, optimizing performance is not just about improving system response speed.

Here, optimizing performance is not just about optimizing throughput and response speed, but finding a balance between throughput and response speed, using limited server resources to better improve user experience.

The response time

There are two very important metrics for response time. That is: average response time and percentile.

(1) Average response time

In general, the average response time is an indication of the average processing capacity of the service interface. It is calculated by adding up the time taken for all the requests and dividing by the number of requests. Take a simple example: for example, if we send 5 requests to a website and each request takes 1ms, 2ms, 1ms, 3ms, 2ms, then the average response time is (1+2+1+3+2) / 5 = 1.8ms, so the average response time is 1.8ms.

One problem with the average response time metric is that if requests are slow for a short period of time and then quickly pass, the average response time doesn’t capture performance fluctuations very well.

(2) percentiles

Percentile is when we optimize, we define a time range, add the time spent per request to a list, and then sort those times in descending order. So, how long it takes to fetch a particular percentile, that’s the TP value.

The TP value indicates that more than N% of requests are returned within X time. For example, TP90 = 50ms, which means that requests exceeding 90th will be returned within 50ms.

Percentile is also important because it reflects the overall response of the application interface.

We generally divide the percentile into TP50, TP90, TP95, TP99, TP99.9 and other segments. The higher the requirement for the value of the high percentile, the higher the requirement for the stability of the response capability of the system.

concurrency

Concurrency refers to the number of requests that the system can handle at the same time, reflecting the load capacity of the system.

When we are optimizing a high concurrency system, we will also tune the concurrency in a variety of ways to improve the system’s ability to handle requests simultaneously.

In general, concurrency is a relatively simple metric to understand, so I won’t go into too much detail.

Second open rate

Second opening rate is mainly aimed at front-end web pages or mobile apps. If a front-end web page or APP can be smoothly opened within 1 second, especially the loading of the home page. At this point, the user will feel that the front-end web page or APP is very smooth to use, if more than 3 seconds or even longer, the user may directly quit the front-end web page or APP no longer use.

Therefore, to optimize programs in high concurrency scenarios, not only the back-end programs should be optimized, but also the front-end and APP.

correctness

Correctness means that no matter how and by what means we optimize the application, the result of the optimized interactive data must be correct. Before optimization, the performance is low and the data is correct, while after optimization, the performance is high and the data is incorrect.

Optimization needs attention

• Don’t optimize at first unless you have to (especially during development)
• Some optimization criteria are outdated and need to be considered in the current hardware and software environment (don’t be a conformist)
• Do not overemphasize certain system-level metrics, such as cache hit ratios, but focus on performance bottlenecks
• Do not blindly follow, test, find the system performance bottleneck, and then determine the means of optimization
• Balance the costs and benefits of optimizations (some optimizations may require changes to the existing architecture and additional development/operations costs)
• The goal of optimization is user experience, reduced hardware cost (reduced cluster size, independent of stand-alone performance)
• Optimizations for test environments may not work for production environments (optimizations need to be realistic)

For performance optimization, there are two main aspects, one is the JVM. Another is mysql. I have compiled two documents for common questions in interviews

jvm

-, THE JVM memory region division

Second, JVM execution subsystem

Garbage collector and memory allocation strategy

Fourth, write efficient and elegant Java programs

Fifth, performance optimization

Need this JVM tuning information, follow + forward, private message “JVM” can see how to obtain

mysql

For MySQL, I have summarized 21 commonly used techniques in practice and interview, so this document can be used as a reference for both interview and work

Feel this mysql optimization practice is not bad, welcome to pay attention to + forward, private “mysql” can be viewed