`

构建高性能Web站点(笔记五)

阅读更多

第八章 反向代理缓存


    传统代理: 用户隐藏在代理服务器之后。代理服务器工作在应用层,它只转发它支持的协议的数据。
    反向代理(Reverse Proxy): 这种机制是Web服务器隐藏在代理服务器之后,实现这种机制的服务器称作反向代理服务器(Reverse Proxy Server)。此时,Web服务器成为后端服务器,反向代理服务器称为前端服务器
    引入反向代理服务器的目的之一就是基于缓存的加速。我们可以将内容缓存在反向代理服务器上,所有缓存机制的实现仍然采用HTTP/1.1协议。


反向代理服务器不使用缓存:
    可将Nginx做为Apache的反向代理服务器,反向代理服务器不使用缓存时,吞吐率会下降,因为原本直达Web的请求,现在绕路转达,处理时间必然会增加。
    可将Web服务器和应用服务器分离,前者处理一些静态内容,并作为反向代理,后者处理动态内容。


反向代理服务器(RPS)使用缓存:
    Varnish作为RPS,能够提供较好的缓存功能。如果缓存内容发挥作用,在Http响应头中服务器显示的是后端服务器,但Via标记会指示数据的来源。
    RPS可通过修改流经它的Http头信息来决定哪些内容可以缓存,哪些内容不可以缓存。浏览器和Web服务器通过Http将自己的需求告诉RPS,RPS进行协调缓存。
    Varnish通过配置文件来修改缓存规则,使用VCL语言。它也提供强制清除缓存的功能。Varnish提供一个监控程序Varnishstat用来监控缓存命中率。


缓存命中率和后端吞吐率的理想技术模型:  
    实际吞吐率: 指反向代理服务器处理用户请求时的实际吞吐率。
    后端吞吐率: 指后端Web服务器处理来自反向代理服务器的请求时的吞吐率。
    活跃内容数: 在平均缓存有效周期内,反向代理服务器想后端服务器请求内容的次数。

   

    缓存丢失率=(活跃内容数/(实际吞吐率×平均缓存有效期))×100% 
    缓存命中率= 1-缓存丢失率 
    后端吞吐率= 活跃内容数/平均缓存有效期 
    缓存命中率= (1-(后端吞吐率/实际吞吐率))×100% 
    后端吞吐率 = (1 – 缓存命中率)×实际吞吐率
结论: 
    1. 活跃内容数和平均缓存有效期一定的情况下,缓存命中率与实际吞吐率成正比。 
    2. 实际吞吐率和平均缓存有效期一定的情况下,缓存命中率与活跃内容数成反比。 
    3. 活跃内容数和实际吞吐率一定的情况下,缓存命中率与平均缓存有效期成正比。 
    4. 活跃内容数一定的情况下,后端吞吐率与平均缓存有效期成反比。 
    5. 平均缓存有效期一定的情况下,后端吞吐率与活跃内容数成正比。 
    6. 缓存命中率的变化不一定会影响后端吞吐率。 
    7. 后端吞吐率的变化不一定会影响缓存命中率。
    由此可见,缓存命中率越高,后端服务器工作量越少是错误的认识。

 

ESI(Edge Side Includes)
    ESI类似于SSI,可以在页面中嵌入子页面,不同于SSI的是SSI在Web服务器端组装内容,ESI在Http代理服务器上组装内容,包括反向代理。
    Varnish支持ESI,这样Varnish就支持网页局部缓存,实现局部更新动态内容。AJAX也有类似的功能(它对局部内容支持异步请求)。


穿过代理:
    反向代理服务器作为用户和后端Web服务器的中介,它只将用户的Http请求转发给后端服务器,但用户的某些信息有时并不在Http请求中,如用户的IP地址和发送请求的TCP端口,这对于后端的Web服务器是不可见的,这就有必要想办法让这些信息“穿过”反向代理服务器。
    办法: 让反向代理请求后端服务器时携带附加的Http头信息(通过配置反向代理服务器来实现)。同样,如果后端服务器想要告知浏览器一些额外的信息,也可以在Http响应头中携带自定义的信息“穿过”反向代理。

 

Nginx和Lighttpd优势主要体现在网络IO模型上。
Nginx利用epoll模型可以在较大并发用户数的情况下依然提供较高的吞吐率。

 

Ajax的问题,局部内容应该和父页面所在的主机保持相同的顶级域名。

 

影响缓存命中率的因素: 缓存过期时间,缓存空间不够大被换出,缓存的粒度,架构设计。

 

影响Web服务器处理能力的因素?(服务器并发处理能力这一章)

 

 

 

 

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics