《构建高性能web站点》读书点滴
最近1个月在阅读《构建高性能web站点》这本书，里面讲的每一个章节都是值得扩展开来。下面记录下几个概念性的问题
一. 吞吐率：一个衡量web服务性能的指标，表征每秒处理请求的次数。该指标受到3方面的因素影响：并发用户数、总请求数、请求资源的类型。有时在请求总数一定的情况下，并发用户越多，吞吐率反而越高；另外，请求一个几kb的文件和请求一个几m的文件，最终完成处理的时间显然是不一样的。因此，吞吐率是一个比较综合的指标，并不是指并发能力。
二. 用户浏览器，代理服务器，web服务器和应用程序服务器的典型关系
三. 各级缓存设计
客户端缓存->反向代理缓存->web服务器缓存->应用程序缓存
客户端缓存
可以利用客户端浏览器的缓存机制，来减少浏览器对服务端的请求次数（当然在服务端进行图片等资源合并，并结合css图片定位技术，也可以减少HTTP请求），利用好HTTP的缓存协商，可以设计出灵活的客户端缓存方案。在HTTP头中下面的内容与缓存协商有关：
Last-Modified：动态页面通过主动推送该值，暗示浏览器在下次请求同一个url的时候，优先使用If-Modified-Since值与服务端进行缓存协商，如果缓存没有过期，那么服务端可以不用重新计算动态网页，通过返回304通知浏览器。网站的静态资源往往使用这种方法。但是该方法有一个缺点：有时，文件的最后更改时间虽然改了，但是内容却没有变，这样无法充分发挥浏览器缓存的能力。
ETag：Web服务器为每个url生成一个散列值，增加在HTTP头的ETag标记中，浏览器会优先使用If-None-Match加上这个散列值来协商缓存过期。通过对静态文件的内容进行md5变换，可以生成散列值，这样可以弥补Last-Modified的不足。但是随之带来的是服务端md5变换的计算开销。
Expires：上述两种方式，虽然可以使服务端多少避免了反复的动态网页解析和计算，但浏览器还是必须通过HTTP请求来进行协商，并没有真正意义上减少请求的次数。通过在HTTP头中添加Expires标记可以明确的告知浏览器过期形式，浏览器会彻底减少请求的次数。
反向代理缓存
在web服务器前端，还有反向代理服务器缓存。反向代理服务器本质上就是代理服务器，只是将外网的请求转发给内网的web服务器处理，他们都工作在应用层，能够理解HTTP协议。正向代理服务器具有HTTP缓存、HTTP过滤等功能，反向代理服务器同样具有HTTP缓存的能力，而且还具备一定程度上的安全性。一切HTTP友好的动态程序同样能够很好的在反向代理服务器上实现缓存。重量级的squid、轻量级的varnish、甚至是Nginx这样的web服务器软件，都可以胜任反向代理服务。
上述的代理服务器软件产品，通过各种配置可以缓存基于HTTP协议的web响应。
Web服务器缓存
Web服务器有可能支持基于url的缓存（基于key-value对），这类似反向代理缓存。缓存通常可以通过配置存储在内存或磁盘上，在缓存有效期的问题上，通常是基于HTTP协议中的头部信息判断。但是使用这样的机制需要注意：
- 动态程序会可能变得依赖于特定的web服务器
- 注意编写面向HTTP缓存友好的动态程序，会使你的动态程序更有生命力
web 服务器还具有缓存文件描述符（类似句柄）的能力，这样可以减少文件的open操作，同样是一种减少系统调用的措施，这对于一些小文件有些效果，因为文件越小花在open上的开销将越来越占有重要的比例。
应用程序缓存
应用程序本身可以对动态内容进行缓存，这可以体现在三个层面：
- 动态脚本缓存：每次脚本解析都需要消耗一定的时间，为了加快这个速度，一些服务器端脚本语言都支持动态脚本的预编译，比如我们熟悉的ASP.NET、JSP都有所谓的中间语言，解析这些中间语言会快很多。
- 动态脚本框架支持的缓存：一些动态脚本框架支持缓存，同样在选型的时候要关注一下这些框架的缓存机制和原理，比如缓存如何存放，过期如何设置，是否支持局部缓存等。
- 应用程序自身实现缓存：应用程序根据特定的业务需求独立设计缓存。
在缓存设计的具体技术上有以下几点：
- 缓存在内存，这种方式的优点就是减少了磁盘的读写，但是内存有限，单机不易扩展。
- 缓存在分布式缓存，这种方式的优点是减少了磁盘读写，并提高了可靠性和扩展性，但是由于需要网络IO，性能稍逊于单机缓存。
- 局部页面缓存，对于一些页面无法完整缓存的，可以考虑局部缓存。
- 静态化，将网站静态化可以极大的提高性能，因为用户的请求不需要动态脚本处理。
