Your Position:Home>News>科技文档>浅谈网站的访问负载(QPS,PV,网站架构师)

浅谈网站的访问负载(QPS,PV,网站架构师)

每天有 86400秒,理想状态下

如果每秒访问<50人,每天PV会在 几百次 (理论上都属于小网站) 稳定的360/年. 起步的 192/年
如果每秒访问100人,每天PV会在 几千次次 (普通有网上销售行为的网站) 稳定的1500/年. 起步的 750/年
如果每秒访问800人,每天PV会在 10万次 (活跃的Forum社区等/购物网站) 稳定的850/月. 起步的 650/月
如果每秒访问>1000人,每天PV会在 1000万次以上(大型Forum社区等/电子商务)

另外一种计算方法:(如果每人平均开5个页面)

每天访问人数 UV <1000

renotalk.com SGCN.com qoo10.sg facebook.com
访问速度3700毫秒 访问速度1400毫秒 访问速度1500毫秒 访问速度2900毫秒
[在线人数:会员18,游客483] [在线人数:会员159,游客28533] [一天里 平均5万订单, 平均在线人数1万]  
 (相当每秒1个人并发) (相当每秒50人并发) (相当每秒170~500人并发) (相当每秒11000人并发)
[日均 IP 51000]  [日均 IP 33000]  [日均 IP 1140000 ]  [日均 IP 10亿 ]
[日均 PV 204000] [日均 PV 297000] [日均 PV 14820000]  [日均 PV 13亿]
 [人均访问页面4.5] [人均访问页面10]  [人均访问页面8]  
国际排名83153 国际排名62099 国际排名2318 国际排名 2
新加坡排名492 新加坡排名426 新加坡排名9 服务器未知
服务器Sucuri/Cloudproxy 服务器nginx/1.8.0    

网站架构师需要有编程的经验,从基本的算法,常用的设计模式,多线程开发,远程调用,不同类型数据源使用,这些是面试的时候看得基本功。

Quest Per Second

<50 QPS 50~100QPS
Small / StartUP DB level
 没什么好说的,简单的小网站而已,就如同本站这样,你可以用最简单的方法快速搭建,短期没有太多的技术瓶颈,只要服务器不要太烂就好。 大部分的关系型数据库的每次请求大多都能控制在0.01秒左右,即便你的网站每页面只有一次DB请求,那么页面请求无法保证在1秒钟内完成100个请求,这个阶段要考虑做Cache或者多DB负载。无论那种方案,网站重构是不可避免的。
300~800QPS 500~1000QPS
 带宽极限型  内网带宽极限+Memcache(一套开源分布式的高速缓存系统)极限型
目前服务器大多用了IDC提供的“百兆带宽”,这意味着网站出口的实际带宽是8M Byte左右。假定每个页面只有10K Byte,在这个并发条件下,百兆带宽已经吃完。首要考虑是CDN加速/异地缓存,多机负载等技术。  由于Key/value的特性,每个页面对memcache的请求远大于直接对DB的请求,Memcache的悲观并发数在2w左右,看似很高,但事实上大多数情况下,首先是有可能在次之前内网的带宽就已经吃光,接着是在8K QPS左右的情况下,Memcache已经表现出了不稳定,如果代码上没有足够的优化,可能直接将压力转嫁到了DB层上,这就最终导致整个系统在达到某个阀值之上,性能迅速下滑  
1000~2000QPS  2000QPS以上
 FORK/SELECT,锁模式极限型  C10K极限
 好吧,一句话:线程模型决定吞吐量。不管你系统中最常见的锁是什么锁,这个级别下,文件系统访问锁都成为了灾难。这就要求系统中不能存在中央节点,所有的数据都必须分布存储,数据需要分布处理。总之,关键词:分布  尽管现在很多应用已经实现了C25K,但短板理论告诉我们,决定网站整体并发的永远是最低效的那个环节。我承认我生涯中从未遇到过2000QPS以上,甚至1.5K以上的网站,希望有此经验的哥们可以一起交流下


Previous:17个提升iOS开发效率的必用工具 Next:网络电台架设方法