性能优化
Web网站的几个并发量级
服务器 • zkbhj 发表了文章 • 0 个评论 • 1362 次浏览 • 2017-10-25 10:45
评价一个网站的“大小”，处于视角的不同，有很多种衡量的方法，类似文章数，页面数之类的数据非常明显，也没有什么可以争议的。但对于并发来说，争议非常之多，这里就从一个技术的角度开始，谈谈几个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极限 查看全部
相信很多人谈论一个网站的热度，总免不了会询问日均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极限 查看全部
评价一个网站的“大小”，处于视角的不同，有很多种衡量的方法，类似文章数，页面数之类的数据非常明显，也没有什么可以争议的。但对于并发来说，争议非常之多，这里就从一个技术的角度开始，谈谈几个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极限
相信很多人谈论一个网站的热度，总免不了会询问日均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极限
网站静态资源使用独立域名对网站效率的影响
前端开发 • zkbhj 发表了文章 • 0 个评论 • 1393 次浏览 • 2017-05-24 10:37
在大型网站中，我们发现页面资源经常使用不同的域名进行引用，例如126邮箱的部分js、css、图片存放于//mimg.127.net/域名下，京东的部分静态图片存放在//img11.360buyimg.com域名下，那这样做究竟有什么好处呢，和性能又有什么关系呢，下面进行具体分析。
一、浏览器并发请求数的限制
我们进行网站页面访问时的客户端是浏览器，浏览器的很多机制对网站的访问速度有很大的影响（例如浏览器对静态资源的缓存机制），此外浏览器为提升页面显示效率，支持并发获取资源，如下是不同浏览器的版本对并发的支持：
浏览器对并发请求的数目限制是针对域名的，即针对同一域名（包括二级域名）在同一时间支持的并发请求数量的限制。如果请求数目超出限制，则会阻塞。因此，网站中对一些静态资源，使用不同的一级域名，可以提升浏览器并行请求的数目，加速界面资源的获取速度。
二、网络请求时cookie传输
当静态资源与主服务在同一域名下（根据业务需要，主服务请求时需要传递cookie信息），每次静态资源的请求，都会发送同域名下的cookie。而对于静态资源，服务器无需对cookie进行任何处理，它们只是在毫无意义的消耗带宽。
假设网站cookie信息有1 KB、网站首页共150个资源时，用户在请求过程中需要发送150 KB的cookie信息，在512 Kbps的常见上行带宽下，需要长达3秒左右才能全部发送完毕。很多情况下cookie的path是在整个一级域名下可用的，如果你把静态资源设置成二级域名，那么它也避免不了cookie。例如如果给 http://126.com 设置了cookie,那么会感染所有子域名, 请求 http://www.126.com/logo.gif或者http://image.126.com/logo.gif 时便会带上讨厌的cookie。
所以对于静态资源使用单独的域名，并设置为无cookie，以减少请求大小，提高网页性能。
三、方便分流或缓存
我们知道，当面对大并发访问时，在服务端会有相应的缓存机制，例如我们会在CDN中缓存一些静态资源，以便用户可以通过就近的网络节点获取资源。例如新浪微博在加载资源时，很多就放在了阿里的CDN上：
此外，独立的域名也方便我们在代理服务层做动静分离，以便提升静态请求的处理速度。
原文参考：http://blog.csdn.net/scorpio3k ... 20270 查看全部
一、浏览器并发请求数的限制
我们进行网站页面访问时的客户端是浏览器，浏览器的很多机制对网站的访问速度有很大的影响（例如浏览器对静态资源的缓存机制），此外浏览器为提升页面显示效率，支持并发获取资源，如下是不同浏览器的版本对并发的支持：
浏览器对并发请求的数目限制是针对域名的，即针对同一域名（包括二级域名）在同一时间支持的并发请求数量的限制。如果请求数目超出限制，则会阻塞。因此，网站中对一些静态资源，使用不同的一级域名，可以提升浏览器并行请求的数目，加速界面资源的获取速度。
二、网络请求时cookie传输
当静态资源与主服务在同一域名下（根据业务需要，主服务请求时需要传递cookie信息），每次静态资源的请求，都会发送同域名下的cookie。而对于静态资源，服务器无需对cookie进行任何处理，它们只是在毫无意义的消耗带宽。
假设网站cookie信息有1 KB、网站首页共150个资源时，用户在请求过程中需要发送150 KB的cookie信息，在512 Kbps的常见上行带宽下，需要长达3秒左右才能全部发送完毕。很多情况下cookie的path是在整个一级域名下可用的，如果你把静态资源设置成二级域名，那么它也避免不了cookie。例如如果给 http://126.com 设置了cookie,那么会感染所有子域名, 请求 http://www.126.com/logo.gif或者http://image.126.com/logo.gif 时便会带上讨厌的cookie。
所以对于静态资源使用单独的域名，并设置为无cookie，以减少请求大小，提高网页性能。
三、方便分流或缓存
我们知道，当面对大并发访问时，在服务端会有相应的缓存机制，例如我们会在CDN中缓存一些静态资源，以便用户可以通过就近的网络节点获取资源。例如新浪微博在加载资源时，很多就放在了阿里的CDN上：
此外，独立的域名也方便我们在代理服务层做动静分离，以便提升静态请求的处理速度。
原文参考：http://blog.csdn.net/scorpio3k ... 20270 查看全部
在大型网站中，我们发现页面资源经常使用不同的域名进行引用，例如126邮箱的部分js、css、图片存放于//mimg.127.net/域名下，京东的部分静态图片存放在//img11.360buyimg.com域名下，那这样做究竟有什么好处呢，和性能又有什么关系呢，下面进行具体分析。
一、浏览器并发请求数的限制
我们进行网站页面访问时的客户端是浏览器，浏览器的很多机制对网站的访问速度有很大的影响（例如浏览器对静态资源的缓存机制），此外浏览器为提升页面显示效率，支持并发获取资源，如下是不同浏览器的版本对并发的支持：
浏览器对并发请求的数目限制是针对域名的，即针对同一域名（包括二级域名）在同一时间支持的并发请求数量的限制。如果请求数目超出限制，则会阻塞。因此，网站中对一些静态资源，使用不同的一级域名，可以提升浏览器并行请求的数目，加速界面资源的获取速度。
二、网络请求时cookie传输
当静态资源与主服务在同一域名下（根据业务需要，主服务请求时需要传递cookie信息），每次静态资源的请求，都会发送同域名下的cookie。而对于静态资源，服务器无需对cookie进行任何处理，它们只是在毫无意义的消耗带宽。
假设网站cookie信息有1 KB、网站首页共150个资源时，用户在请求过程中需要发送150 KB的cookie信息，在512 Kbps的常见上行带宽下，需要长达3秒左右才能全部发送完毕。很多情况下cookie的path是在整个一级域名下可用的，如果你把静态资源设置成二级域名，那么它也避免不了cookie。例如如果给 http://126.com 设置了cookie,那么会感染所有子域名, 请求 http://www.126.com/logo.gif或者http://image.126.com/logo.gif 时便会带上讨厌的cookie。
所以对于静态资源使用单独的域名，并设置为无cookie，以减少请求大小，提高网页性能。
三、方便分流或缓存
我们知道，当面对大并发访问时，在服务端会有相应的缓存机制，例如我们会在CDN中缓存一些静态资源，以便用户可以通过就近的网络节点获取资源。例如新浪微博在加载资源时，很多就放在了阿里的CDN上：
此外，独立的域名也方便我们在代理服务层做动静分离，以便提升静态请求的处理速度。
原文参考：http://blog.csdn.net/scorpio3k ... 20270
一、浏览器并发请求数的限制
我们进行网站页面访问时的客户端是浏览器，浏览器的很多机制对网站的访问速度有很大的影响（例如浏览器对静态资源的缓存机制），此外浏览器为提升页面显示效率，支持并发获取资源，如下是不同浏览器的版本对并发的支持：
浏览器对并发请求的数目限制是针对域名的，即针对同一域名（包括二级域名）在同一时间支持的并发请求数量的限制。如果请求数目超出限制，则会阻塞。因此，网站中对一些静态资源，使用不同的一级域名，可以提升浏览器并行请求的数目，加速界面资源的获取速度。
二、网络请求时cookie传输
当静态资源与主服务在同一域名下（根据业务需要，主服务请求时需要传递cookie信息），每次静态资源的请求，都会发送同域名下的cookie。而对于静态资源，服务器无需对cookie进行任何处理，它们只是在毫无意义的消耗带宽。
假设网站cookie信息有1 KB、网站首页共150个资源时，用户在请求过程中需要发送150 KB的cookie信息，在512 Kbps的常见上行带宽下，需要长达3秒左右才能全部发送完毕。很多情况下cookie的path是在整个一级域名下可用的，如果你把静态资源设置成二级域名，那么它也避免不了cookie。例如如果给 http://126.com 设置了cookie,那么会感染所有子域名, 请求 http://www.126.com/logo.gif或者http://image.126.com/logo.gif 时便会带上讨厌的cookie。
所以对于静态资源使用单独的域名，并设置为无cookie，以减少请求大小，提高网页性能。
三、方便分流或缓存
我们知道，当面对大并发访问时，在服务端会有相应的缓存机制，例如我们会在CDN中缓存一些静态资源，以便用户可以通过就近的网络节点获取资源。例如新浪微博在加载资源时，很多就放在了阿里的CDN上：
此外，独立的域名也方便我们在代理服务层做动静分离，以便提升静态请求的处理速度。
原文参考：http://blog.csdn.net/scorpio3k ... 20270
Web网站的几个并发量级
服务器 • zkbhj 发表了文章 • 0 个评论 • 1362 次浏览 • 2017-10-25 10:45
评价一个网站的“大小”，处于视角的不同，有很多种衡量的方法，类似文章数，页面数之类的数据非常明显，也没有什么可以争议的。但对于并发来说，争议非常之多，这里就从一个技术的角度开始，谈谈几个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极限 查看全部
相信很多人谈论一个网站的热度，总免不了会询问日均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极限 查看全部
评价一个网站的“大小”，处于视角的不同，有很多种衡量的方法，类似文章数，页面数之类的数据非常明显，也没有什么可以争议的。但对于并发来说，争议非常之多，这里就从一个技术的角度开始，谈谈几个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极限
相信很多人谈论一个网站的热度，总免不了会询问日均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极限
网站静态资源使用独立域名对网站效率的影响
前端开发 • zkbhj 发表了文章 • 0 个评论 • 1393 次浏览 • 2017-05-24 10:37
在大型网站中，我们发现页面资源经常使用不同的域名进行引用，例如126邮箱的部分js、css、图片存放于//mimg.127.net/域名下，京东的部分静态图片存放在//img11.360buyimg.com域名下，那这样做究竟有什么好处呢，和性能又有什么关系呢，下面进行具体分析。
一、浏览器并发请求数的限制
我们进行网站页面访问时的客户端是浏览器，浏览器的很多机制对网站的访问速度有很大的影响（例如浏览器对静态资源的缓存机制），此外浏览器为提升页面显示效率，支持并发获取资源，如下是不同浏览器的版本对并发的支持：
浏览器对并发请求的数目限制是针对域名的，即针对同一域名（包括二级域名）在同一时间支持的并发请求数量的限制。如果请求数目超出限制，则会阻塞。因此，网站中对一些静态资源，使用不同的一级域名，可以提升浏览器并行请求的数目，加速界面资源的获取速度。
二、网络请求时cookie传输
当静态资源与主服务在同一域名下（根据业务需要，主服务请求时需要传递cookie信息），每次静态资源的请求，都会发送同域名下的cookie。而对于静态资源，服务器无需对cookie进行任何处理，它们只是在毫无意义的消耗带宽。
假设网站cookie信息有1 KB、网站首页共150个资源时，用户在请求过程中需要发送150 KB的cookie信息，在512 Kbps的常见上行带宽下，需要长达3秒左右才能全部发送完毕。很多情况下cookie的path是在整个一级域名下可用的，如果你把静态资源设置成二级域名，那么它也避免不了cookie。例如如果给 http://126.com 设置了cookie,那么会感染所有子域名, 请求 http://www.126.com/logo.gif或者http://image.126.com/logo.gif 时便会带上讨厌的cookie。
所以对于静态资源使用单独的域名，并设置为无cookie，以减少请求大小，提高网页性能。
三、方便分流或缓存
我们知道，当面对大并发访问时，在服务端会有相应的缓存机制，例如我们会在CDN中缓存一些静态资源，以便用户可以通过就近的网络节点获取资源。例如新浪微博在加载资源时，很多就放在了阿里的CDN上：
此外，独立的域名也方便我们在代理服务层做动静分离，以便提升静态请求的处理速度。
原文参考：http://blog.csdn.net/scorpio3k ... 20270 查看全部
一、浏览器并发请求数的限制
我们进行网站页面访问时的客户端是浏览器，浏览器的很多机制对网站的访问速度有很大的影响（例如浏览器对静态资源的缓存机制），此外浏览器为提升页面显示效率，支持并发获取资源，如下是不同浏览器的版本对并发的支持：
浏览器对并发请求的数目限制是针对域名的，即针对同一域名（包括二级域名）在同一时间支持的并发请求数量的限制。如果请求数目超出限制，则会阻塞。因此，网站中对一些静态资源，使用不同的一级域名，可以提升浏览器并行请求的数目，加速界面资源的获取速度。
二、网络请求时cookie传输
当静态资源与主服务在同一域名下（根据业务需要，主服务请求时需要传递cookie信息），每次静态资源的请求，都会发送同域名下的cookie。而对于静态资源，服务器无需对cookie进行任何处理，它们只是在毫无意义的消耗带宽。
假设网站cookie信息有1 KB、网站首页共150个资源时，用户在请求过程中需要发送150 KB的cookie信息，在512 Kbps的常见上行带宽下，需要长达3秒左右才能全部发送完毕。很多情况下cookie的path是在整个一级域名下可用的，如果你把静态资源设置成二级域名，那么它也避免不了cookie。例如如果给 http://126.com 设置了cookie,那么会感染所有子域名, 请求 http://www.126.com/logo.gif或者http://image.126.com/logo.gif 时便会带上讨厌的cookie。
所以对于静态资源使用单独的域名，并设置为无cookie，以减少请求大小，提高网页性能。
三、方便分流或缓存
我们知道，当面对大并发访问时，在服务端会有相应的缓存机制，例如我们会在CDN中缓存一些静态资源，以便用户可以通过就近的网络节点获取资源。例如新浪微博在加载资源时，很多就放在了阿里的CDN上：
此外，独立的域名也方便我们在代理服务层做动静分离，以便提升静态请求的处理速度。
原文参考：http://blog.csdn.net/scorpio3k ... 20270 查看全部
在大型网站中，我们发现页面资源经常使用不同的域名进行引用，例如126邮箱的部分js、css、图片存放于//mimg.127.net/域名下，京东的部分静态图片存放在//img11.360buyimg.com域名下，那这样做究竟有什么好处呢，和性能又有什么关系呢，下面进行具体分析。
一、浏览器并发请求数的限制
我们进行网站页面访问时的客户端是浏览器，浏览器的很多机制对网站的访问速度有很大的影响（例如浏览器对静态资源的缓存机制），此外浏览器为提升页面显示效率，支持并发获取资源，如下是不同浏览器的版本对并发的支持：
浏览器对并发请求的数目限制是针对域名的，即针对同一域名（包括二级域名）在同一时间支持的并发请求数量的限制。如果请求数目超出限制，则会阻塞。因此，网站中对一些静态资源，使用不同的一级域名，可以提升浏览器并行请求的数目，加速界面资源的获取速度。
二、网络请求时cookie传输
当静态资源与主服务在同一域名下（根据业务需要，主服务请求时需要传递cookie信息），每次静态资源的请求，都会发送同域名下的cookie。而对于静态资源，服务器无需对cookie进行任何处理，它们只是在毫无意义的消耗带宽。
假设网站cookie信息有1 KB、网站首页共150个资源时，用户在请求过程中需要发送150 KB的cookie信息，在512 Kbps的常见上行带宽下，需要长达3秒左右才能全部发送完毕。很多情况下cookie的path是在整个一级域名下可用的，如果你把静态资源设置成二级域名，那么它也避免不了cookie。例如如果给 http://126.com 设置了cookie,那么会感染所有子域名, 请求 http://www.126.com/logo.gif或者http://image.126.com/logo.gif 时便会带上讨厌的cookie。
所以对于静态资源使用单独的域名，并设置为无cookie，以减少请求大小，提高网页性能。
三、方便分流或缓存
我们知道，当面对大并发访问时，在服务端会有相应的缓存机制，例如我们会在CDN中缓存一些静态资源，以便用户可以通过就近的网络节点获取资源。例如新浪微博在加载资源时，很多就放在了阿里的CDN上：
此外，独立的域名也方便我们在代理服务层做动静分离，以便提升静态请求的处理速度。
原文参考：http://blog.csdn.net/scorpio3k ... 20270
一、浏览器并发请求数的限制
我们进行网站页面访问时的客户端是浏览器，浏览器的很多机制对网站的访问速度有很大的影响（例如浏览器对静态资源的缓存机制），此外浏览器为提升页面显示效率，支持并发获取资源，如下是不同浏览器的版本对并发的支持：
浏览器对并发请求的数目限制是针对域名的，即针对同一域名（包括二级域名）在同一时间支持的并发请求数量的限制。如果请求数目超出限制，则会阻塞。因此，网站中对一些静态资源，使用不同的一级域名，可以提升浏览器并行请求的数目，加速界面资源的获取速度。
二、网络请求时cookie传输
当静态资源与主服务在同一域名下（根据业务需要，主服务请求时需要传递cookie信息），每次静态资源的请求，都会发送同域名下的cookie。而对于静态资源，服务器无需对cookie进行任何处理，它们只是在毫无意义的消耗带宽。
假设网站cookie信息有1 KB、网站首页共150个资源时，用户在请求过程中需要发送150 KB的cookie信息，在512 Kbps的常见上行带宽下，需要长达3秒左右才能全部发送完毕。很多情况下cookie的path是在整个一级域名下可用的，如果你把静态资源设置成二级域名，那么它也避免不了cookie。例如如果给 http://126.com 设置了cookie,那么会感染所有子域名, 请求 http://www.126.com/logo.gif或者http://image.126.com/logo.gif 时便会带上讨厌的cookie。
所以对于静态资源使用单独的域名，并设置为无cookie，以减少请求大小，提高网页性能。
三、方便分流或缓存
我们知道，当面对大并发访问时，在服务端会有相应的缓存机制，例如我们会在CDN中缓存一些静态资源，以便用户可以通过就近的网络节点获取资源。例如新浪微博在加载资源时，很多就放在了阿里的CDN上：
此外，独立的域名也方便我们在代理服务层做动静分离，以便提升静态请求的处理速度。
原文参考：http://blog.csdn.net/scorpio3k ... 20270