评价一个网站的“大小”，处于视角的不同，有很多种衡量的方法，类似文章数，页面数之类的数据非常明显，也没有什么可以争议的。但对于并发来说，争议非常之多，这里就从一个技术的角度开始，谈谈几个Web网站的数量级。

相信很多人谈论一个网站的热度，总免不了会询问日均PV，同时在线人数、注册用户数等运营数据，说实话从技术角度来说，这几个数值没有一个可以放在一起比较的——一个静态网站的PV跟一个SNS类/Web Game网站的PV根本就不是一回事。由于互联网有一个传说中的“3秒定律”，可能当下更多的网站技术指标要求1.5秒以内加载整页，或者至少可以达到阅读的标准。如果要较真什么“同时在线”，毫不客气的说，对于HTTP这类短链接的网络协议来说，在WebSocket还不普及的时代，能统计在线纯属扯淡，唯一能做的只是取个时间段，计算下访问用户而已。这些依然可以换算成QPS（Quest Per Second每秒请求数）。就并发而言，我唯一推崇的只有理论最大QPS和悲观QPS。

 

这里就大致根据理论最大QPS，给网站做几个分类

50QPS以下——小网站

没什么好说的，简单的小网站而已，你可以用最简单的方法快速搭建，短期没有太多的技术瓶颈，只要服务器不要太烂就好。

50～100QPS——DB极限型

大部分的关系型数据库的每次请求大多都能控制在0.01秒左右，即便你的网站每页面只有一次DB请求，那么页面请求无法保证在1秒钟内完成100个请求，这个阶段要考虑做Cache或者多DB负载。无论那种方案，网站重构是不可避免的。

300～800QPS——带宽极限型

目前服务器大多用了IDC提供的“百兆带宽”，这意味着网站出口的实际带宽是8M Byte左右。假定每个页面只有10K Byte，在这个并发条件下，百兆带宽已经吃完。首要考虑是CDN加速／异地缓存，多机负载等技术。

500～1000QPS——内网带宽极限＋Memcache极限型

由于Key/value的特性，每个页面对memcache的请求远大于直接对DB的请求，Memcache的悲观并发数在2w左右，看似很高，但事实上大多数情况下，首先是有可能在次之前内网的带宽就已经吃光，接着是在8K QPS左右的情况下，Memcache已经表现出了不稳定，如果代码上没有足够的优化，可能直接将压力转嫁到了DB层上，这就最终导致整个系统在达到某个阀值之上，性能迅速下滑。

1000～2000QPS——FORK/SELECT，锁模式极限型

好吧，一句话：线程模型决定吞吐量。不管你系统中最常见的锁是什么锁，这个级别下，文件系统访问锁都成为了灾难。这就要求系统中不能存在中央节点，所有的数据都必须分布存储，数据需要分布处理。总之，关键词：分布

2000QPS以上——C10K极限

尽管现在很多应用已经实现了C25K，但短板理论告诉我们，决定网站整体并发的永远是最低效的那个环节。我承认我生涯中从未遇到过2000QPS以上，甚至1.5K以上的网站，希望有此经验的哥们可以一起交流下

 

本文系转载文章，如果有侵权，麻烦联系博主进行删除。谢谢！~~~

联系邮箱: lc9008@qq.com

 

 

作者：Linsa
链接：https://www.zhihu.com/question/45406520/answer/109911793
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
 

 

附一些关于性能测试的观点(摘取自： https://www.zhihu.com/question/45406520)

1. 首先明确下并发的概念。在性能测试中并发可以理解为同一时刻做不同的事，或同一时刻做同样的事。一般我们在性能测试的时候也是这么去模拟的。那这个同一时刻的并发是很难做到的。要知道我们用来发起压力的测试工具本身要能做到同一时刻发起压力，如果设置线程数过多，负载机本身资源不足会有排队，请求建立和服务端的连接过程会排队，请求数据发送到服务的时候在网络队列上也会排队，请求数据达到服务端，在服务端也会进行排队，所以严格意义上的并发多少用户数等等是比较难做到的。
但是，并发我们可以分层去看，像一般的webserver或容器服务都有监控数据，如nginx的Active connections，tomcat的currentThreadsBusy，这些参数表明服务本身目前正在处理的最大并发线程数。到了代码层每个方法的实际并发数又是另一回事。根据请求的到达情况来看，每一层的并发数都会有不同。
使用一台机器发起600个线程，和使用2台机器各发起300线程，从服务端的请求达到情况来看，确实会存在不一样的情况。
2. 性能测试中不只关注并发数，尤其是单接口性能测试的时候，更多关注吞吐量、响应时间等指标来评估服务端性能。验证服务端最高每秒能正确处理的请求数，以及请求的响应延时情况。
曾经看过并实施过RBI性能测试方法，快速瓶颈识别法。推荐资料：rapid_bottleneck_identifation_百度文库。RBI强调了80%的性能问题可以通过吞吐量测试来发现，其他20%的性能问题可以通过引入并发用户数等更复杂的场景来发现。推荐有空可以看看。