Several concurrent levels of Web sites

Source: Internet
Author: User

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 just like this site, you can use the simplest method of rapid construction, short-term not too many technical bottlenecks, as long as the server 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. I admit that my career has never encountered more than 2000QPS, or even more than 1.5K of the site, I hope that the experience of the Buddies can communicate with the next

Ext.: http://www.litrin.net/2013/03/27/web%E7%BD%91%E7%AB%99%E7%9A%84%E5%87%A0%E4%B8%AA%E5%B9%B6%E5%8F%91%E9%87%8F%E7%BA%A7/

Several concurrent levels of Web sites

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.