《构建高性能Web站点》第五章 第六章 第七章
包括:《构建高性能Web站点》第五章 动态脚本加速 第六章 浏览器缓存 第七章Web服务器缓存
动态脚本加速
1.opcode缓存
PHP、Ruby、Python,它们都属于解释型语言,所以用它们编写的动态内容都需要依赖相应的解释器程序来运行。
解释器程序也是一个二进制可执行文件,比如/bin/ruby,它同样可以直接在进程中运行,在运行过程中,解释器程序需要对输入的脚本代码进行分析,领会它们的旨意,然后执行它们。
编译型语言和解释型语言:
https://blog.csdn.net/u014647208/article/details/78329187
https://blog.csdn.net/u010830004/article/details/78282070
概括来说:
编译型语言翻译只做了一次,运行时不需要翻译,所以编译型语言的程序执行效率高,但也不能一概而论,部分解释型语言的解释器通过在运行时动态优化代码,甚至能够使解释型语言的性能超过编译型语言。
解释型语言在运行的时候才翻译,比如VB语言,在执行的时候,专门有一个解释器能够将VB语言翻译成机器语言,每个语句都是执行的时候才翻译。这样解释型语言每执行一次就要翻译一次,效率比较低。
解释器完成对脚本代码的分析后,便将它们生成可以直接运行的中间代码,也称为操作码(Operate Code, opcode)。
从程序代码到中间代码的这个过程,我们称为解释(parse),它由解释器来完成。与此相似的是,编译型语言中的编译器(如C语言的编译器gcc),也要将程序代码生成中间代码,这个过程我们称为编译(compile)。
编译器和解释器的一个本质不同在于,解释器在生成中间代码后,便直接执行它,所以运行时的控制权在解释器;而编译器则将中间代码进一步优化,生成可以直接运行的目标程序(例如exe),但不执行它,用户可以在随后的任意时间执行它,这时控制权在目标程序,和编译器没有任何关系。
正是因为解释器每次运行的时候都将脚本代码作为输入数据来分析,所以它的数据结构可以动态改变,这使得解释型语言具备了很多丰富的动态特性,在开发和调试中有很多优势,特别是一些流行的Web开发框架,其中的一些特性如果没有动态语言的支持是无法实现的。
opcode缓存器扩展,比如APC、eAccelerator、XCache等。
2.解释器扩展模块
3.脚本跟踪与分析
我们需要了解如何测量脚本程序中各处代码的执行时间,为此,代码跟踪是少不了的,我们必须掌握脚本的高级调试技巧,几乎所有脚本语言都内置了或多或少的调式方法,但是也许它们并不专业,而且不够完整。
==浏览器缓存 ==
1.别忘了浏览器
如果你换一个角度,把浏览器想象成为Web站点分派到千家万户的缓存管理器,那么从现在开始,你不能再对浏览器坐视不理了。
听起来非常不错,这似乎告诉我们应该把握一个原则,尽可能地让Web站点的内容缓存在用户浏览器中,这样将在一定程度上减少了服务器的计算开销,而且也避免了有些内容由于不必要的重复传输而带来的带宽浪费。
2.缓存协商
缓存内容存储在浏览器本地,而内容由Web服务器生成,任何一方都不可能独立完成这一系列过程,所以它们之间必须有一种沟通机制,这就是HTTP中的“缓存协商”。
协商的过程很容易理解,首先,当浏览器向Web服务器请求一些内容时,Web服务器需要告诉浏览器哪些内容可以被缓存,一旦浏览器知道某个内容可以缓存后,下次当浏览器需要请求这个内容时,它便不会直接向服务器请求完整内容,而是询问服务器是否可以使用本地的缓存,服务器在收到浏览器的询问后需要作出果断的回应,到底是允许浏览器使用本地缓存还是将最新的内容传回浏览器。
协商方式:
1.If-Modified-Since与Last-Modified
2.Etag和If-None-Match
3.彻底消灭请求
HTTP中还有另一个标记,那就是Expires,它告诉浏览器该内容在何时过期,暗示浏览器在该内容过期之前不需要再询问服务器,而直接使用本地缓存即可。
这样的好处显而易见,一旦浏览器丝毫不用请求服务器,那将完全节省了带宽和服务器处理等开销,可谓皆大欢喜。
Expires标记更像善于放权的管理者,浏览器一旦看到某个内容附带Expires标记后,便拥有了极大的权力,它无须在过期之前每次都询问服务器,完全可以自作主张,而Last-Modified标记让浏览器感到拘束,它们不得不每次都询问服务器,即便它们认为这样做毫无意义。
Web服务器缓存
1.URL映射
对于任何Web服务器,当我们向它发送一个HTTP请求后,它要做的主要工作就是解析URL,然后完成从URL到实际内容或资源的映射。这里所说的映射是一个抽象的概念,实际上就是服务器处理请求并生成响应内容的过程,而这里之所以说“映射”,是希望从URL的角度来看服务器的处理过程。
如果我们不看过程,只关注URL和最终的响应内容,则它们确实就像一系列的对应关系。这个过程可以是重定向、代理等。
2.缓存响应内容
3.缓存文件描述符
对于静态内容,特别是拥有大量小文件的站点,Web服务器相当大的一部分开销花在了打开文件上,即open()系统调用,所以我们还可以考虑将打开后的文件描述符直接缓存到Web服务器的内存中,当然,文件描述符是反映系统资源的数据结构,它也只能存在于本机内存中。
还没有评论,来说两句吧...