如何建设一个高性能网站

以下知识收集自互联网：仅供自己或者大家查阅使用，请勿转载！！！

Web 应用性能优化黄金法则：先优化前端程序 (front-end) 的性能，因为80% 或以上的最终用户响应时间的花费所在。

1. 减少 HTTP 请求次数
80%的最终用户响应时间花在前端程序上，而其大部分时间则花在各种页面元素， 如图片、 样式表、 脚本和 Flash 等的下载上。 减少页面元素将会减少 HTTP 请求次数，是快速显示页面的关键所在。 一种减少页面元素个数的方法是简化页面设计。 但是否存在其他方式，能做到既有丰富内容，又能获得快速响应时间呢？可以参考以下一些技术： Image maps 组合多个图片到一张图片中。总文件大小变化不大，但减少了 HTTP 请求次数从而加快了页面显示速度。 该方式只适合图片连续的情况；同时坐标的定义是烦人又容易出错的工作。 CSS Sprites 是更好的方法。它可以将页面中的图片组合到单个文件中，并使用 CSS 的 background-p_w_picpath 和 background-position 属性来显示所需的部分图片。 Inline p_w_picpaths 使用 data: URL scheme 来在页面中内嵌图片。这将增大 HTML文件的大小。组合 inline p_w_picpaths 到你的（缓存）样式表是既能较少 HTTP 请求， 又能避免加大 HTML 文件大小的方法。 Combined files 通过组合多个脚本文件到单一文件来减少 HTTP 请求次数。样式表也可采用类似方法处理。 这个方法虽然简单，但没有得到大规模的使用。  美国网站平均每个页面有 7 个Js文件和 2 个样式表。当页面之间脚本和样式表变化很大时，该方式将遇到很大的挑战，但如果做到的话，将能加快响应时间。 减少 HTTP 请求次数是性能优化的起点。这对提高首次访问的效率起到很重要的作用。 Tenni Theurer 的文章 Browser Cache Usage – Exposed!描述，40-60% 的日常访问是首次访问，因此为首次访问者加快页面访问速度是用户体验的关 键。

2. 使用 CDN(Content Delivery Network, 内容分发网络 )

用户离 web server 的远近对响应时间也有很大影响。从用户角度看，把内容部署到多个地理位置分散的服务器上将有效提高页面加载速度。

作为实现内容地理分布的第一步，不要试图重构 web 应用以适应分布架构。 改变架构将导致多个周期性任务，如同步 session 状态，在多个 server 之间复制数据库数据。 这样缩短用户与内容距离的尝试可能被应用架构改版所延迟，或阻止。 我们还记得 80-90%的最终用户响应时间花在下载页面中的各种元素上，如图片文件、 样式表、 脚本和 Flash 等。 与其花在重构系统这个困难的任务上，还不如先分布静态内容。 这不仅能大大减少响应时间，而且由于 CDN 的存在，分布静态内容非常容易实现。 CDN 是地理上分布的 web server 的集合，用于更高效地发布内容。 通常基于网络远近来选择给具体用户服务的 web server。 一些大型网站拥有自己的 CDN，但是使用如 Akamai Technologies, Mirror Image Internet, 或 Limelight Networks 等 CDN 服务提供商的服务将是划算的。 在 Yahoo!把静态内容分布到 CDN 减少了用户影响时间 20%或更多。切换到 CDN 的代码修改工作是很容易的，但能达到提高网站的速度。

3. 增加 Expires Header
网页内容正变得越来越丰富，这意味着更多的脚本文件、样式表、图片和 Flash。 首次访问者将不得不面临多次 HTTP 请求，但通过使用 Expires header， 您可以在客户端缓存这些元素。这在后续访问中避免了不必要的 HTTP 请求。 Expires header 最常用于图片文件，但是它也适用于脚本文件、样式表和 Flash。 浏览器（和代理）使用缓存来减少 HTTP 请求的次数和大小，使得网页快速装载。 Web server 通过 Expires header 告诉客户端一个元素可以缓存的时间长度。 如果服务器是 Apache 的话，可以使用 ExpiresDefault 基于当期日期来设置过期日期，如： ExpiresDefault “access plus 10 years” 设置过期时间为从请求时间开始计算的 10 年。 请记住，如果使用超长的过期时间，则当内容改变时，您必须修改文件名称。 在 Yahoo!我们经常把改名作为 release 的一个步骤：版本号内嵌在文件名中，如 yahoo_2.0.6.js。

4. 压缩页面元素
通过压缩 HTTP 响应内容可减少页面响应时间。从 HTTP/1.1 开始，web 客户端在 HTTP 请求中通过 Accept-Encoding 头来表明支持的压缩类型，如：Accept-Encoding: gzip, deflate. 如果 Web server 检查到 Accept-Encoding 头，会使用客户端支持的方法来压缩 HTTP 响应，会设置 Content-Encoding 头，如：Content-Encoding: gzip。 Gzip 是目前最流行及有效的压缩方法。 其他的方式如 deflate，但它效果较差， 也不够流行。通过 Gzip，内容一般可减少 70%。如果是 Apache，在 1.3 版本下需 使用 mod_gzip 模块，而在 2.x 版本下，则需使用 mod_deflate。 Web server 根据文件类型来决定是否压缩。 大部分网站对 HTML 文件进行压缩。 但对脚本文件和样式表进行压缩也是值得的。实际上，对包括 XML 和 JSON 在内的任务文本信息进行压缩都是值得的。 图像文件和 PDF 文件不应该被压缩，因为它们本身就是压缩格式保存的。对它们进行压缩，不但浪费 CPU，而且还可能增加文件的大小。 因此，对尽量多的文件类型进行压缩是一种减少页面大小和提高用户体验的有效方法。

5. 把css放在head上
我们发现把样式表移到 HEAD 部分可以提高界面加载速度，因此这使得页面元素可以顺序显示。 在很多浏览器下，如 IE，把样式表放在 document 的底部的问题在于它禁止了网页内容的顺序显示。 浏览器阻止显示以免重画页面元素，那用户只能看到空白页。Firefox 不会阻止显示，但这意味着当样式表下载后，有些页面元素可能需要重画，这导致闪烁问题。 HTML 规范明确要求样式表被定义在 HEAD 中，因此，为避免空白屏幕或闪烁问题， 最好的方法是遵循 HTML 规范，把样式表放在 HEAD 中。

6. 把js文件放在底部
与样式文件一样，我们需要注意脚本文件的位置。 我们需尽量把它们放在页面的底部，这样一方面能顺序显示，另方面可达到最大的并行下载。 浏览器会阻塞显示直到样式表下载完毕，因此我们需要把样式表放在 HEAD 部分。 而对于脚本来说，脚本后面内容的顺序显示将被阻塞，因此把脚本尽量放在底 部意味着更多内容能被快速显示。 脚本引起的第二个问题是它阻塞并行下载数量。HTTP/1.1 规范建议浏览器每个主机的并行下载数不超过 2 个。 因此如果您把图像文件分布到多台机器的话，您

可以达到超过 2 个的并行下载。 但是当脚本文件下载时，浏览器不会启动其他的并行下载，甚至其他主机的下载也不启动。 在某些情况下，不是很容易就能把脚本移到底部的。如，脚本使用 document.write 方法来插入页面内容。 同时可能还存在域的问题。 不过在很多情 况下，还是有一些方法的。 一个备选方法是使用延迟脚本（deferred script）。DEFER 属性表明脚本未包 含 document.write，指示浏览器刻继续显示。不幸的是，Firefox 不支持 DEFER 属性。 IE 中，脚本可能被延迟执行，但不一定得到需要的长时间延迟。 在 不过从另外角度来说，如果脚本能被延迟执行，那它就可以被放在底部了。

7. 避免 CSS 表达式
CSS 表达式是功能强大的(同时也是危险的)用于动态设置 CSS 属性的方式。IE， 从版本 5 开始支持 CSS 表达式。

如 backgourd-color: expression((newDate()).getHours()%2?”#B8D4FF”:”#F08A00”)，即背景色每个小时切换一 次。 CSS 表达式的问题是其执行次数超过大部分人的期望。 不仅页面显示和 resize 时 计算表达式，而且当页面滚屏，甚至当鼠标在页面上移动时都会重新计算表达 式。 一种减少CSS 表达式执行次数的方法是一次性表达式，即当第一次执行时就以明确的数值代替表达式。如果必须动态设置的话，可使用事件处理函数代替。如果您必须使用 CSS 表达式的话，请记住它们可能被执行上千次，从而影响页面性能。

8. 把 JavaScript和 CSS 放到外部文件中

上述很多性能优化法则都基于外部文件进行优化。 现在，我们必须问一个问题： JavaScript 和 CSS 应该包括在外部文件，还是在页面文件中？ 在现实世界中，使用外部文件会加快页面显示速度，因为外部文件会被浏览器缓存。如果内置 JavaScript 和 CSS 在页面中虽然会减少 HTTP 请求次数，但增大了页面的大小。 另外一方面，使用外部文件，会被浏览器缓存，则页面大小会减 小，同时又不增加 HTTP 请求次数。 因此，一般来说，外部文件是更可行的方式。 唯一的例外是内嵌方式对主页更有 效，如 Yahoo!和 My Yahoo!都使用内嵌方式。一般来说，在一个 session 中，主 页访问此时较少，因此内嵌方式可以取得更快的用户响应时间。

9. 减少 DNS 查询次数
DNS 用于映射主机名和 IP 地址，一般一次解析需要 20～120 毫秒。 为了达到更高的性能，DNS 解析通常被多级别地缓存，如由 ISP 或局域网维护的 caching server，本地机器操作系统的缓存（如 windows 上的 DNS Client Service）， 浏览器的缺省 DNS 缓存时间为 30 分钟，Firefox 的缺省缓冲时间是 1 分钟。 IE 减少主机名可减少 DNS 查询的次数，但可能造成并行下载数的减少。避免 DNS 查 询可减少响应时间，而减少并行下载数可能增加响应时间。 一个可行的折中是把内容分布到至少 2 个，最多 4 个不同的主机名上。

10. 最小化 JavaScript代码

最小化 JavaScript 代码指在 JS 代码中删除不必要的字符，从而降低下载时间。 两个流行的工具是 JSMin 和 YUI Compressor。它通过删除注释和空格来减少源码大小，同时它还可以对代码进行混淆处理。 作为混淆的一部分，函数名和变量名被替换成短的字符串，这使得代码更紧凑，同时也更难读，使其难于被反向工程。Dojo Compressor (ShrinkSafe)是最常见的混淆工具。 最小化是安全的、直白的过程，而混淆则更复杂，而且容易产生问题。从对美国 10 大网站的调查来看，通过最小化，文件可减少 21%，而混淆则可减少 25%。 除了最小化外部脚本文件外，内嵌的脚本代码也应该被最小化。 即使脚本根据法则 4 被压缩后传输，最小化脚本可减少文件大小 5%甚至更高。

11. 避免重定向
重定向功能是通过 301 和 302 这两个 HTTP 状态码完成的，如： HTTP/1.1 301 Moved Permanently Location:http://example.com/newuri Content-Type: text/html 浏览器自动重定向请求到 Location 指定的 URL 上，重定向的主要问题是降低了用户体验。 一种最耗费资源、经常发生而很容易被忽视的重定向是 URL 的最后缺少/，如访 问 http://astrology.yahoo.com/astrology 将被重定向到 http://astrology.yahoo.com/astrology/。在 Apache 下，可以通过 Alias，mod_rewrite 或 DirectorySlash 等方式来解决该问题。

12. 删除重复的脚本文件
在一个页面中包含重复的 JS 脚本文件会影响性能，即它会建立不必要的 HTTP 请求和额外的 JS 执行。 不必要的 HTTP 请求发生在 IE 下，而 Firefox 不会产生多余的 HTTP 请求。 额外的 JS 执行，不管在 IE 下，还是在 Firefox 下，都会发生。 一个避免重复的脚本文件的方式是使用模板系统来建立脚本管理模块。 除了防止重复的脚本文件外，该模块还可以实现依赖性检查和增加版本号到脚本文件名中，从而实现超长的过期时间。

13. 配置 ETags
ETags 是用于确定浏览器缓存中元素是否与 Webserver 中的元素相匹配的机制， 它是比 last-modified date 更灵活的元素验证机制。ETag 是用于唯一表示元素版本的字符串，它需被包括在引号中。Web server 首先在 response 中指定 ETag： HTTP/1.1 200 OK < 03:03:59 2006 Dec 12> 10c24bc-4ab-457e1c1f”Content-Length: 12195 后来，如果浏览器需要验证某元素，它使用 If-None-Match 头回传 ETag 给 Web server，如果 ETag 匹配，则服务器返回 304 代码，从而节省了下载时间： GET /i/yahoo.gif  HTTP/1.1  Host: us.yimg.com <03:03:59 2006 Dec 12> 10c24bc-4ab-457e1c1f”HTTP/1.1 304 Not Modified ETags 的问题在于它们是基于服务器唯一性的某些属性构造的，如 Apache1.3 和 2.x，其格式是 inode-size-timestamp，而在 IIS5.0 和 6.0 下，其格式是 Filetimestamp:ChangeNumber。这样同一个元素在不同的 web server 上，其 ETag 是不一样的。这样在多 Web server 的环境下，浏览器先从 server1 请求某元素，后来向 server2 验证该元素，由于 ETag 不同，所以缓存失效，必须重新下载。

因此，如果您未用到 ETags 系统提供的灵活的验证机制，最好删除 ETag。删除 ETag 会减少 http response 及后续请求的 HTTP 头的大小。在 Apache 下，只要在配置文件中设置 FileETag none 即可。

14. 缓存 Ajax
性能优化法则同样适用于 web 2.0 应用。提高 Ajax 的性能最重要的方式是使其 response 可缓存，就象“法则 3 增加 Expires Header”讨论的那样。以下其他法则同样适用于 Ajax，当然法则 3 是最有效的方式

参考博客：http://blog.csdn.net/aalansehaiyang52/article/details/8712102

   

   以上是前端开发人员需要注意的14个前端优化法则，但是以上法则主要在改善用户等待时间，无需修改后台代码。很多技巧都是我们平常开发时需要注意的，别在开发的时候采用最好的后台架构，但是却无法获得最好的用户体验。如果设计一个应对高访问和高并发的网站，我们应该如何从架构来方面提高网站的性能：

第一步：物理分离webserver和数据库

最开始，由于某些想法，于是在互联网上搭建了一个网站，这个时候甚至有可能主机都是租借的，但由于这篇文章我们只关注架构的演变历程，因此就假设这个时候已经是托管了一台主机，并且有一定的带宽了，这个时候由于网站具备了一定的特色，吸引了部分人访问，逐渐你发现系统的压力越来越高，响应速度越来越慢，而这个时候比较明显的是数据库和应用互相影响，应用出问题了，数据库也很容易出现问题，而数据库出问题的时候，应用也容易出问题，于是进入了第一步演变阶段：将应用和数据库从物理上分离，变成了两台机器，这个时候技术上没有什么新的要求，但你发现确实起到效果了，系统又恢复到以前的响应速度了，并且支撑住了更高的流量，并且不会因为数据库和应用形成互相的影响。

第二步：增加页面缓存
好景不长，随着访问的人越来越多，你发现响应速度又开始变慢了，查找原因，发现是访问数据库的操作太多，导致数据连接竞争激烈，所以响应变慢，但数据库连接又不能开太多，否则数据库机器压力会很高，因此考虑采用缓存机制来减少数据库连接资源的竞争和对数据库读的压力，这个时候首先也许会选择采用squid等类似的机制来将系统中相对静态的页面（例如一两天才会有更新的页面）进行缓存（当然，也可以采用将页面静态化的方案），这样程序上可以不做修改，就能够很好的减少对webserver的压力以及减少数据库连接资源的竞争，OK，于是开始采用squid来做相对静态的页面的缓存。

这一步涉及到了这些知识体系：
前端页面缓存技术，例如squid，如想用好的话还得深入掌握下squid的实现方式以及缓存的失效算法等。

关于页面缓存采用的技术:

ehcache: http://ahuaxuan.iteye.com/blog/128458

oscache: http://www.blogjava.net/SIDNEY/archive/2006/01/12/27783.html

架构演变第三步：增加页面片段缓存
增加了squid做缓存后，整体系统的速度确实是提升了，webserver的压力也开始下降了，但随着访问量的增加，发现系统又开始变的有些慢了，在尝到了squid之类的动态缓存带来的好处后，开始想能不能让现在那些动态页面里相对静态的部分也缓存起来呢，因此考虑采用类似ESI之类的页面片段缓存策略，OK，于是开始采用ESI来做动态页面中相对静态的片段部分的缓存。

页面片段缓存技术，例如ESI等，想用好的话同样需要掌握ESI的实现方式等；

第四步：数据缓存
在采用ESI之类的技术再次提高了系统的缓存效果后，系统的压力确实进一步降低了，但同样，随着访问量的增加，系统还是开始变慢，经过查找，可能会发现系统中存在一些重复获取数据信息的地方，像获取用户信息等，这个时候开始考虑是不是可以将这些数据信息也缓存起来呢，于是将这些数据缓存到本地内存，改变完毕后，完全符合预期，系统的响应速度又恢复了，数据库的压力也再度降低了不少。缓存技术，包括像Map数据结构、缓存算法、所选用的框架本身的实现机制等。

第五步：增加webserver
好景不长，发现随着系统访问量的再度增加，webserver机器的压力在高峰期会上升到比较高，这个时候开始考虑增加一台webserver，这也是为了同时解决可用性的问题，避免单台的webserver down机的话就没法使用了，在做了这些考虑后，决定增加一台webserver，增加一台webserver时，会碰到一些问题，典型的有：
1、如何让访问分配到这两台机器上，这个时候通常会考虑的方案是Apache自带的负载均衡方案，或LVS这类的软件负载均衡方案；
2、如何保持状态信息的同步，例如用户session等，这个时候会考虑的方案有写入数据库、写入存储、cookie或同步session信息等机制等；
3、如何保持数据缓存信息的同步，例如之前缓存的用户数据等，这个时候通常会考虑的机制有缓存同步或分布式缓存；
4、如何让上传文件这些类似的功能继续正常，这个时候通常会考虑的机制是使用共享文件系统或存储等；
在解决了这些问题后，终于是把webserver增加为了两台，系统终于是又恢复到了以往的速度。

负载均衡技术（包括但不限于硬件负载均衡、软件负载均衡、负载算法、linux转发协议、所选用的技术的实现细节等）、主备技术（包括但不限于ARP欺骗、linuxheart-beat等）、状态信息或缓存同步技术（包括但不限于Cookie技术、UDP协议、状态信息广播、所选用的缓存同步技术的实现细节等）、共享文件技术（包括但不限于NFS等）、存储技术（包括但不限于存储设备等）。

第六步：分库
享受了一段时间的系统访问量高速增长的幸福后，发现系统又开始变慢了，这次又是什么状况呢，经过查找，发现数据库写入、更新的这些操作的部分数据库连接的资源竞争非常激烈，导致了系统变慢，这下怎么办呢，此时可选的方案有数据库集群和分库策略，集群方面像有些数据库支持的并不是很好，因此分库会成为比较普遍的策略，分库也就意味着要对原有程序进行修改，一通修改实现分库后，不错，目标达到了，系统恢复甚至速度比以前还快了。

这一步更多的是需要从业务上做合理的划分，以实现分库，具体技术细节上没有其他的要求；
但同时随着数据量的增大和分库的进行，在数据库的设计、调优以及维护上需要做的更好，因此对这些方面的技术还是提出了很高的要求的。

第七步：分表、DAL和分布式缓存
随着系统的不断运行，数据量开始大幅度增长，这个时候发现分库后查询仍然会有些慢，于是按照分库的思想开始做分表的工作，当然，这不可避免的会需要对程序进行一些修改，也许在这个时候就会发现应用自己要关心分库分表的规则等，还是有些复杂的，于是萌生能否增加一个通用的框架来实现分库分表的数据访问，这个在ebay的架构中对应的就是DAL，这个演变的过程相对而言需要花费较长的时间，当然，也有可能这个通用的框架会等到分表做完后才开始做，同时，在这个阶段可能会发现之前的缓存同步方案出现问题，因为数据量太大，导致现在不太可能将缓存存在本地，然后同步的方式，需要采用分布式缓存方案了，于是，又是一通考察和折磨，终于是将大量的数据缓存转移到分布式缓存上了。

分表更多的同样是业务上的划分，技术上涉及到的会有动态hash算法、consistenthash算法等；
DAL涉及到比较多的复杂技术，例如数据库连接的管理（超时、异常）、数据库操作的控制（超时、异常）、分库分表规则的封装等；

第九步：数据读写分离和廉价存储方案
突然有一天，发现这个完美的时代也要结束了，数据库的噩梦又一次出现在眼前了，由于添加的webserver太多了，导致数据库连接的资源还是不够用，而这个时候又已经分库分表了，开始分析数据库的压力状况，可能会发现数据库的读写比很高，这个时候通常会想到数据读写分离的方案，当然，这个方案要实现并不容易，另外，可能会发现一些数据存储在数据库上有些浪费，或者说过于占用数据库资源，因此在这个阶段可能会形成的架构演变是实现数据读写分离，同时编写一些更为廉价的存储方案，例如BigTable这种。

第十步：进入大型分布式应用时代和廉价服务器群梦想时代
经过上面这个漫长而痛苦的过程，终于是再度迎来了完美的时代，不断的增加webserver就可以支撑越来越高的访问量了，对于大型网站而言，人气的重要毋庸置疑，随着人气的越来越高，各种各样的功能需求也开始爆发性的增长，这个时候突然发现，原来部署在webserver上的那个web应用已经非常庞大了，当多个团队都开始对其进行改动时，可真是相当的不方便，复用性也相当糟糕，基本是每个团队都做了或多或少重复的事情，而且部署和维护也是相当的麻烦，因为庞大的应用包在N台机器上复制、启动都需要耗费不少的时间，出问题的时候也不是很好查，另外一个更糟糕的状况是很有可能会出现某个应用上的bug就导致了全站都不可用，还有其他的像调优不好操作（因为机器上部署的应用什么都要做，根本就无法进行针对性的调优）等因素，根据这样的分析，开始痛下决心，将系统根据职责进行拆分，于是一个大型的分布式应用就诞生了，通常，这个步骤需要耗费相当长的时间，因为会碰到很多的挑战：
1、拆成分布式后需要提供一个高性能、稳定的通信框架，并且需要支持多种不同的通信和远程调用方式；
2、将一个庞大的应用拆分需要耗费很长的时间，需要进行业务的整理和系统依赖关系的控制等；
3、如何运维（依赖管理、运行状况管理、错误追踪、调优、监控和报警等）好这个庞大的分布式应用。
经过这一步，差不多系统的架构进入相对稳定的阶段，同时也能开始采用大量的廉价机器来支撑着巨大的访问量和数据量，结合这套架构以及这么多次演变过程吸取的经验来采用其他各种各样的方法来支撑着越来越高的访问量。

参考博客：

http://blog.csdn.net/aalansehaiyang52/article/details/6635675

关于网站大数据储存可以参见如下博客

http://blog.csdn.net/aalansehaiyang52/article/details/7061378