Web网站的几个并发量级
2016-03-31 18:21
477 查看
原文:http://www.cnblogs.com/yiwd/p/3711677.html
评价一个网站的“大小”,处于视角的不同,有很多种衡量的方法,类似文章数,页面数之类的数据非常明显,也没有什么可以争议的。但对于并发来说,争议非常之多,这里就从一个技术的角度开始,谈谈几个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以上的网站,希望有此经验的哥们可以一起交流下
评价一个网站的“大小”,处于视角的不同,有很多种衡量的方法,类似文章数,页面数之类的数据非常明显,也没有什么可以争议的。但对于并发来说,争议非常之多,这里就从一个技术的角度开始,谈谈几个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以上的网站,希望有此经验的哥们可以一起交流下
相关文章推荐
- 企业级容器Registry开源项目Harbor架构简介
- ArchSummit北京2015 移动应用架构趋势纪要
- 企业级Registry开源项目Harbor架构简介
- ComboBox的联动(三层架构)
- 大型网站之存储瓶颈(数据库的水平扩展)
- 网站统计中的数据收集原理及实现(openResty篇)
- IIS6.0发布网站
- LEMP架构及应用部署
- 浅析x86架构中cache的组织结构
- 网站的高性能架构
- 抓取网站数据不再是难事了,Fizzler(So Easy)全能搞定
- 天猫浏览型应用的CDN静态化架构演变
- 构建高并发高可用的电商平台架构实践
- 网站克隆神器
- 浅谈web网站架构演变过程
- iOS 架构模式 - 简述 MVC, MVP, MVVM
- Web Deploy发布网站及常见问题解决方法
- 网站 首页那点事儿(一)
- linux 网站架构的演变
- 三层架构