E-commerce Summary (vi) system capacity estimation

A few days ago, the concept of PV and concurrency, also probably explained the concurrency, bandwidth and other indicators of calculation. Interested friends, you can look at my previous article: "Talk about PV and concurrency." I'll talk about it today. Capacity estimates.

E-commerce company's friends, whether such a scene is familiar:

Operations and products The mysterious run came to ask:

We have to do a promotion at night, the server can withstand it? How many machines do I need to add if I can't carry it?

As a result, technology is a face of crazy.

In fact, these are the problem of system capacity estimation, capacity estimation is one of the necessary skills of architects. The so-called capacity estimation is actually the maximum amount of traffic that the system can withstand before it is down. This is an important indicator of the ability of the technician to understand the system. Common capacity evaluations include a range of content such as traffic, concurrency, bandwidth, CPU, memory, disk, and much more. Let's talk today about capacity projections.

　　One, several important parameters

QPS: number of requests processed per second

Concurrency : number of requests processed concurrently by the system

　 Response Time : Average response time is generally taken

Many people often confuse concurrency with QPS, understand the meaning of the above three elements, and can deduce the relationship between them: QPS = concurrency/average response time

Second, the steps and methods of capacity evaluation

1: Estimated total traffic

How do I know the total number of visits? What is the best way to assess an operation's traffic, or to evaluate a system's on-line PV?

The simplest way is to ask the business side, ask the students to run, ask the product classmate, see the product and the operation of the flow estimate of the activity.

However, the business side of the estimate of traffic should be two indicators, PV and user access number. Technicians need more of these two data to calculate other related indicators, such as QPS. Specific how to calculate can refer to my previous article PV and concurrency.

2: Estimated average QPS

　　　　　　Total number of requests = Total PV * page-derived connections

Average QPS = Total number of requests/total time

For example: The total number of visits to the active page within 1 hours is 30w PV, which has a derivative connection of 30, then the average QPS of the landing page

(30w * 30)/(60 * 60) = 2500,

3: Estimated peak QPS

System capacity Planning, you can not only consider the average QPS, but to resist the peak of the QPS, how to assess peak QPS?

This is based on the actual business assessment, through the previous marketing activities of PV and other data to estimate. In general, the peak QPS is about 3-5 times the mean QPS, and the average daily QPS is 1000, so the peak QPS is estimated to be 5000.

However, some businesses such as "kill the business" are more difficult to assess the volume of business visits, and the capacity evaluation of such a business is not discussed here.

4: Estimated system, single machine limit QPS

How to estimate a business, a server single-machine limit QPS?

This performance indicator, is the server, one of the most basic indicators, so there is no other way, is the stress test. Through the pressure test, the server's single-machine limit QPS is calculated.

Before a business goes live, stress testing is generally required (many startups, the business iteration system may not have this step, it's tragic), the app pushes a campaign for example (estimated daily average QPS 1000, peak QPS 5000), the business scenario might be:

1) Push an active message through the APP

2) Operational Activities H5 Landing page is a Web site

3) H5 floor-to-ceiling pages are assembled from cache caches, database DB data

Through the stress test found that the Web server can only resist 1200 Qps,cache and database db can withstand the concurrency of pressure, (generally speaking, 1% of the traffic to the database, the database of the QPS can be easily anti-live, the cache word QPS can resist, need to evaluate the cache bandwidth, This assumes that the cache is not a bottleneck, so that we get the Web single-machine limit of the QPS is 1200. In general, production systems do not run full limits, which can easily affect the life and performance of the server, allowing a single line to run to QPS 1200 * 0.8 = 960.

Extension said, through the stress test, already know that the web layer is a bottleneck, you can make some adjustments to the web-related optimization to improve the Web server single-machine QPS.

Also, in the stress test work, the general is a specific business perspective of the stress test, is concerned about a specific business of the concurrency and QPS.

5: Answer the first two questions　　　　　

Required machines = Peak QPS/single-machine limit QPS

Well, the above has got the peak QPS is 5000, the single-machine limit QPS is 1000, the online deployment of 3 servers:

(1) Can the server withstand? ---peak 5000, stand-alone 1000, 3 units on line, can't carry

(2) How many machines do I need to add if I can't carry it? 2 additional units, 1 units in advance, to 3 sets of insurance

third, the last

Above, just a few personal experience sharing, there is nothing wrong place, everyone tap to shoot bricks, there are better suggestions welcome reply,,

E-commerce Summary (vi) system capacity estimation