Several concurrent levels of Web sites

To evaluate the "size" of a Web site, different from the perspective, there are many ways to measure, like the number of articles, the number of pages and so on is very obvious, and there is nothing to dispute. But for concurrency, there's a lot of controversy here, starting with a technical perspective and talking about the order of several web sites.

Believe that a lot of people talk about a site's heat, will inevitably ask the daily average PV, while online numbers, registered users and other operational data, to tell the truth from a technical point of view, none of these values can be compared together-a static website of the PV with an SNS class/web The game site's PV is not the same thing at all. As the internet has a legendary "3-Second Law", it is possible that more website technical indicators now require 1.5 seconds to load the entire page, or at least to meet the standards of reading. If you want to seriously what "at the same time online", it is not polite to say, for HTTP such short-link network protocol, in the era of WebSocket is not popular, can be counted online purely nonsense, the only thing to do is to take a time period, calculate access to users. These can still be converted to QPS (Quest per second Requests/sec). In terms of concurrency, the only thing I admire is theoretical maximum QPS and pessimistic QPS.

Here are roughly based on the theory of maximum QPS, to make a few classifications for the site

Below 50QPS--Small website

There is nothing to say, simple small site, you can use the simplest way to quickly build, short-term not too many technical bottlenecks, as long as the server is not too bad on the good.

50~100qps--db Limit Type

Most of the relational database every request can be controlled in about 0.01 seconds, even if your site only a DB request per page, then the page request can not guarantee to complete 100 requests in 1 seconds, this phase to consider doing cache or multi-db load. Regardless of that scenario, site refactoring is unavoidable.

300~800qps--Bandwidth Limit Type

At present, the server mostly uses the "hundred gigabit bandwidth" provided by IDC, which means that the actual bandwidth of the website export is about 8M bytes. Assuming that each page is only 10K Byte, in this concurrency condition, the hundred gigabit bandwidth has been eaten. The first consideration is CDN acceleration/offsite caching, multi-machine load and other technologies.

500~1000qps--network bandwidth limit +memcache limit type

Because of the characteristics of key/value, each page of Memcache request is much larger than the request directly to the DB, memcache pessimistic concurrency of about 2w, seemingly high, but in fact most of the time, first of all, it is possible before the network bandwidth has been eaten up, followed by 8K In the case of QPS, the memcache has shown instability, and if there is not enough optimization on the code, it is possible to pass the pressure directly onto the DB layer, which eventually results in the entire system reaching a certain threshold and the performance is rapidly declining.

1000~2000qps--fork/select, lock mode limit type

Well, in a word: The threading model determines throughput. The file system access lock is a disaster at this level, no matter what lock is the most common lock in your system. This requires the system can not exist in the central node, all the data must be distributed storage, the data needs to be distributed processing. In summary, Keywords: distribution

2000QPS above--c10k limit

Although many applications have already implemented c25k, the short board theory tells us that determining the overall concurrency of the site is always the least effective link.