Web site of the order of several concurrent
Evaluate a site's "size", in a different perspective, there are many ways to measure, similar to the number of articles, number of pages and the like data is very clear, there is no possible dispute. But for concurrency, the controversy very much, here from a technical point of view began to talk about the order of several Web sites.
I believe many people talk about the heat of a website, the total will inevitably ask the average daily PV, concurrent users, the number of registered users and other operational data to tell the truth from a technical point of view, these values can not put them together in a - a static site with PV PV a class SNS / Web Game site is simply not the same thing. As the Internet has a legendary "three seconds rule", the site may present more technical requirements within 1.5 seconds to load the whole page, or at least meet the standards of reading. What if you want to seriously "concurrent" not polite to say, for the HTTP network protocol such short link, in the era of WebSocket is not widespread, and can count online pure nonsense, the only can do is take time period, calculated under the user access only. These can be converted into still QPS (Quest Per Second requests per second). On concurrency, the only thing I respected only QPS and the theoretical maximum pessimism QPS.
Here it is generally based on the theoretical maximum QPS, do to the site several categories
50QPS the following - small sites
Nothing to say, just simple little website, just like this site so that you can quickly build the most simple way, without too much short-term technical bottlenecks, as long as the servers do not suck enough.
50 ~ 100QPS - DB limit type
Most of the majority of each request relational database can be controlled at about 0.01 seconds, even if your site only once every DB page request, the requested page can not guarantee 100 requests completed within 1 second, to consider at this stage do DB Cache or multiple loads. No matter the kind of program, site reconstruction is inevitable.
300 ~ 800QPS-- the bandwidth limit type
Most of the current server with the "Fast Bandwidth" IDC provided the actual bandwidth which means that the site exit is about 8M Byte. Assume that each page only 10K Byte, under the concurrent conditions, hundreds of megabytes of bandwidth has been finished. The primary consideration is CDN acceleration / remote caching, multi-machine load technology.
500 ~ 1000QPS-- limits the bandwidth of the network type Limit + Memcache
Due to the nature Key / value, each page request for memcache much larger than the direct request of DB, Memcache pessimistic about the number of concurrent 2w, seem high, but in fact in most cases, it is possible in the first times prior to the bandwidth of the network had already eaten, followed in the case of about 8K QPS, Memcache has shown instability, if there is not enough to optimize the code may be directly passed on to the pressure on the DB layer, which eventually led to the entire system over to reach a certain threshold, the rapid decline in performance.
1000 ~ 2000QPS - FORK / SELECT, the limit type lock mode
Well, in a word: threading model decision throughput. Whether your system is the most common locks are what lock, at this level, file system access locks have become a disaster. This requires a central node in the system can not exist, all data must be distributed and stored, the data processing need to be distributed. In short, keyword: distribution
2000QPS above --C10K limit
Although many applications have now achieved C25K, but short-plate theory tells us that the decision to site as a whole is always complicated by the least effective of the link. I admit that I never had 2000QPS career over, even more than 1.5K site, hope to have this experience man can communicate together under
The more you understand, the more will not, the way knowledge is progressive
