Evaluation index of high concurrency software (website, server interface)

Evaluate the of a website “ size ”, In different perspectives , There are many ways to measure , Number of similar articles , Data such as the number of pages is very obvious , There is nothing to dispute . But for concurrency , There is a lot of controversy , Let's start from a technical point of view , Talk about a few Web The order of magnitude of the website .

I believe many people talk about the popularity of a website , It is inevitable to ask about the daily average PV, Number of people online at the same time 、 Operation data such as the number of registered users , To tell you the truth, from a technical point of view , None of these values can be compared together —— A static website PV With one SNS class /Web Game Website PV It's not the same thing . Because the Internet has a legendary “3 The law of seconds ”, Maybe there are more requirements for website technical indicators at present 1.5 Load the whole page in seconds , Or at least meet the standards of reading . If you want to be serious about something “ Online at the same time ”, Say it rudely , about HTTP For such short link network protocols , stay WebSocket It is not popular yet , It's bullshit to be able to count online , The only thing you can do is to take a time period , Calculate the access user . These can still be converted into QPS（Quest Per Second Requests per second ）. In terms of concurrency , The only thing I admire is the theory QPS And pessimism QPS.

This is roughly based on the theory QPS, Make a few categories for the website

50QPS following —— Small website

There's nothing to say , It's just a simple little website , You can use the simplest way to quickly build , There are not many technical bottlenecks in the short term , As long as the server is not too bad .

50～100QPS——DB Limit type

In most relational databases, each request can be controlled in 0.01 About seconds , Even if your site has only one page per page DB request , Then the page request cannot be guaranteed in 1 In seconds 100 A request , At this stage, we should consider doing Cache Or more DB load . Either way , Website refactoring is inevitable .

300～800QPS—— Bandwidth limiting type

Current service Most servers are used IDC Provided “ 100 megabytes of bandwidth ”, this It means that the actual bandwidth of the website outlet is 8M Byte Left Right . Assume that each page has only 10K Byte, Under this concurrency condition , 100m bandwidth has been used up . The first consideration is CDN Speed up ／ Remote cache , Multi machine load and other technologies .

500～1000QPS—— Intranet bandwidth limit ＋Memcache Limit type

because Key/value Characteristics of , Each page faces memcache Your request is far greater than the direct request to DB Request ,Memcache The number of pessimistic concurrency in 2w about , It seems very high , But in fact, in most cases , First of all, it is possible that the bandwidth of the Intranet has been consumed before , Then in 8K QPS Left and right ,Memcache Has shown instability , If there is not enough optimization in the code , May directly transfer the pressure to DB On the floor , This eventually leads to the whole system reaching a certain threshold , Performance declines rapidly .

1000～2000QPS——FORK/SELECT, Lock mode limit type

ok , In a word ： The thread model determines throughput . No matter what lock is the most common lock in your system , At this level , File system access locks are a disaster . This requires that there should be no central node in the system , All data must be stored in a distributed way , Data needs to be distributed . All in all , key word ： Distribution

2000QPS above ——C10K limit

Although many applications have been implemented now C25K, But the short board theory tells us , It is always the most inefficient link that determines the overall concurrency of the website . I admit that I have never met in my life 2000QPS above , even to the extent that 1.5K The above websites , I hope that friends with this experience can communicate with each other .