Full link voltage measurement: building three models

Foreword of pressure measurement

The last article mainly introduced the preparation stage of full link voltage measurement , The core point ： Core link related knowledge .

An important purpose of combing the core link is to obtain the traffic model . But in the full link voltage measurement , In addition to the flow model , Business models are as important as data models . This article , Let's introduce how to build these three models .

Business scenario model

It is mentioned in the previous article that ： In the core application corresponding to the core business , The path through which the most important request traffic to achieve the realization of enterprise profits is guaranteed , That is, the core link . After understanding this sentence , You can have a good understanding of the business scenario model . The following figure shows a common e-commerce double 11 Business scenario model diagram at the time of promotion , I take this mind map as an example to analyze and illustrate .

Generally speaking, there are several steps to sort out the business scenario model ：

Determine the business scope mainly involved in this promotion according to the business characteristics （ E-commerce is generally trading 、 Activity and inventory business ）;

Determine the business scope involved , What are the corresponding core businesses （ Here we need to further refine the business , Pictured above ）;

According to the sorted out core business scenarios , Further marking （ Assume that the flow is too high , Which can give up ）;

The business scenarios mentioned above are refined and labeled to give weight , To know more clearly , What are the most core scenarios that can't go wrong .

Peak flow model

The estimated flow model should be based on the peak flow scenario , Otherwise, it is likely that there will be online problems during the promotion period due to insufficient preparation due to wrong estimation . This is not only a technical and monitoring problem , We should also comprehensively consider the business objectives and business conversion rate during this promotion . for instance ：

Business objectives ： double 11 The estimated average per customer price of the day 500, One day GMV10 Billion , Payment order quantity is 200W;

Transformation technical indicators ：

Assume that the daily payment order quantity is 50W, The payment conversion rate is 40%, Order payment QPS The peak value is 200. It is estimated that the payment conversion rate during the promotion is 60%, Then you can get ： Promote peak order payment QPS by （200/40%）60%（200W/50W）=1200QPS. This 1200QPS It's a guaranteed value , Generally, in order to leave some redundant space , Will float up 30%, That is, the amount paid for the order QPS Estimated as 1500;

E-commerce's shopping guide browsing, order payment conversion link is generally ： home page → Goods details → Create order → Order payment → Successful payment , This process is a transformation logic similar to funnel . Suppose the home page → Conversion rate of goods 40%, Goods details → Create an order with a conversion rate of 40%, Create order → The conversion rate of order payment is 40%, Then we can get ： Create order QPS by 1500/40%=3750, Goods details QPS by 3750/40%=9375, home page QPS by 9375/40%=23437;

According to the dependency between core links , With the help of monitoring and trace track , Finally, I got the promotion period , All involved core applications and core links QPS The number .

Finally, we will get a traffic model diagram similar to the following ：

Pressure measurement data model

About the pressure measurement data model , In fact, it can be divided into 2 Parts of ： Pressure measurement model and data model .

Piezometric model

In my personal experience , The pressure measurement model can be divided from the following dimensions ：

1. Single machine single interface benchmark （ Interface level ）

Pressure measurement of single machine and single interface , You can increase the request by gradient , Observe as requests increase , Performance & Changes in resource depletion . Under the current microservice Architecture , The performance bottleneck of the whole link , Depends on the short plate （ Barrel principle ）. therefore , The purpose of single machine single link benchmark , It is to conduct performance evaluation before the start of full link pressure test , Locate and troubleshoot the link bottleneck .

2. Single machine hybrid link scenario （ Service levels ）

Single machine mixed scene , Most of them increase the request by gradient , Observe service level performance .

Purpose of single machine hybrid link voltage test , It is the bottleneck of checking upstream and downstream call dependency , And take the test results as the reference value of the current limiting plan . Focus on 3 Indicators ：

Safe water level （CPU50%）

Alarm water level （CPU70%）

Maximum water level （CPU≥90%&Load5≥150%）

3. Production of full link voltage test scenarios （ Production clusters ）

Full link voltage measurement for production clusters , There are many pressure measurement models to be involved , Generally, there are several kinds of ：

①. Gradient pressure model ： To detect the maximum throughput of the system in the cluster mode （ And avoid crushing Services , Cause an accident ）;

②. Fixed concurrency model ： Verify the stability of the system under load for a long time ;

③. Impulsive concurrency model ： The robustness of the detection system 、 Verify the correctness of current limiting fuse and other service protection measures & Usability ;

④. Oversold validation model ： Mainly for some limited time rush purchases & Second kill scene ; Usually this kind of scene , Distributed locks are involved 、

cache 、 Data consistency and other technical points ; If you can't play well , It is easy to cause customer complaints 、 Asset loss 、 Even abnormal service downtime ！

Data model

After talking about the pressure measurement model , Next, let's talk about the data model . Data scenarios , Often overlooked , But in fact, the data scenario is more important . If the data used in the test is inaccurate , The test results often deviate greatly . About the data required for the test , Please refer to the following points ：

In my personal experience , The test data in the data model is mainly divided into the following types ：

Basic data ： Also known as preliminary data , The purpose of preliminary data is to be consistent with online （ At least an order of magnitude ）, Combined with the online growth rate , Confirm the embedded data magnitude and embedded method . It involves the data to be verified during pressure measurement , It is necessary to elaborate the design when laying the groundwork , Including data size , Number , Distribution, etc .

Hot data ： You need to understand the implementation logic of the tested interface , Confirm the following information ：

Whether there are operations related to hot data ： For example, all users kill the same product ;

When different types of data processing logic are different , It is necessary to improve the coverage of performance test code through the diversification of test data ;

Cache data ： To confirm whether there is a cache , What is the cache size （ Exclude large key, Generally speaking 142W Of key Occupy Redis One G Of memory ）;

Spike buying related data , Generally speaking, it is queue processing , Put this type of data into the cache for processing to deal with high concurrency . Another example is what users need to log in token Data such as , During production pressure measurement , It needs to be preheated into the cache in advance , Avoid user service becoming a bottleneck during pressure measurement ;

Friends who like software testing , If my blog helps you 、 If you like my blog content , please “ give the thumbs-up ” “ Comment on ” “ Collection ” One Key triple connection ！