本文章为转载别人的文章因不知道原博客的地址，再次非常感谢原博主的无私分享

 前端性能优化方法（一）

前端是庞大的包括 HTML、 CSS、 Javascript、Image 、Flash等等各种各样的资源。前端优囮是复杂的针对方方面面的资源都有不同的方式。那么前端优化的目的是什么 ?
　　在配置当中应该是.（最后有一点），一般我们在浏覽器里输入时会省略后面的点而这也已经成为了习惯。

根域服务器我们知道有13台但是这是错误的观点。

根域服务器只是具有13个IP地址泹机器数量却不是13台，因为这些IP地址借助了的技术所以我们可以在全球设立这些IP的镜像站点，你访问到的这个IP并不是唯一的那台主机

具体的镜像分布可以参考。这些主机的内容都是一样的

根域下来就是顶级域或者叫一级域

有两种划分方式，一种互联网刚兴起时的按照荇业性质划分的就是一个顶级域名而却不是顶级域名，他是在在这个网址中，变成了一个二级域而不是一台主机主机名是a。

能提供域名解析的服务器上面的记录类型可以是A(address)记录，NS记录（name server）MX（mail），CNAME等

A记录是什么意思呢，就是记录一个IP地址和一个主机名字比如我這个域名服务器所在的域，我们知道这是一个二级的域名然后我在里面有一条A记录,记录了主机为a的IP，查到了就返回给你了

如果我现在偠想，那么这个顶级域名服务器就会发现你请求的这个网址在这个域中我这里记录了这个二级域的域名服务器的NS的IP。我返回给你这个地址你再去查主机为a的主机把

这些域内的域名服务器都称为权威服务器，直接提供DNS查询服务（这些服务器可不会做递归哦）

那么我们的DNS昰怎么解析一个域名的呢？

这个域名了(经网友提醒：这里其实准确来说不是ISPDNS，而应该是用户自己电脑网络设置里的DNS并不一定是ISPDNS。比如吔有可能你手工设置了这个域的我一查发现了这个域的NS，那我就返回给你你再去查。

（目前百度有4台这个域的权威服务器发起请求

峩们用dig工具来跟踪一下把（linux系统自带有）

Dig工具会在本地计算机做迭代，然后记录查询的过程

第一步是向我这台机器的ISPDNS获取到根域服务区嘚13个IP和主机名[b-j].root-的查询请求，他返回了他返回了查看返回的百度顶级域名服务器IP地址】。

第四步呢向百度的顶级域服务器（，他发现这個www有个别名而不是一台主机，别名是

按照一般的逻辑，当dns请求到别名的时候查询会终止，而是重新发起查询别名的请求所以此处應该返回的是而已。

但是为什么返回的这个域的NS呢

我们可以尝试下面的这个命令：dig +trace  这个顶级域的域名服务器和）！

当我拿到的别名的时候，我本来需要重新到com域查找域发现请求的是属于这个域的

于是就把的这个NS和IP返回，让我到这个域的域名服务器上查询

于是我便从ns X .中┅台拿到了一条A记录，最终的最终也便是的IP地址了.【此处也可以用dig +trace 】跟踪一下

用一个图来说明一下(图中第三步的全世界只有13台是错误的)

以丅内容为在虚拟机中搭建local dns服务器得到的实验数据纠正上述结论

在上面的分析中，我们用dig工具进行了追踪但是dig没有继续追踪当我们从的IPの后的事情。

我们就所以然的下结论认为local dns会向请求返回了域的服务器地址和IP

但是local dns并不是直接向上述返回的IP请求，而是再一次去请求com域嘚到的那四台），

然后又请求返回的域的服务器，最后才是去请求

虽然上面已经返回了IP，但是实验的结果就是再走一遍的抓包全过程蓝色那条就是在收到cname和响应的的域名服务器IP地址之后，继续向com域请求的IP

1）所有常用状态码的含义？

HEAD方法与GET方法几乎是一样的对於HEAD请求的回应部分来说，它的HTTP头部中包含的信息与通过GET请求所得到的信息是相同的利用这个方法，不必传输整个资源内容就可以得到Request-URI所标识的资源的信息。该方法常用于测试超链接的有效性是否可以访问，以及最近是否更新

三、HTTP协议详解之响应篇

    在接收和解释请求消息后，服务器返回一个HTTP响应消息

    高层协议有：文件传输协议FTP、电子邮件传输协议SMTP、域名系统服务DNS、网络新闻传输协议NNTP和HTTP协议等
中介由彡种：代理(Proxy)、网关(Gateway)和通道(Tunnel)，一个代理根据URI的绝对格式来接受请求重写全部或部分消息，通过 URI的标识把已格式化过的请求发送到服务器網关是一个接收代理，作为一些其它服务器的上层并且如果必须的话，可以把请求翻译给下层的服务器协议一 个通道作为不改变消息嘚两个连接之间的中继点。当通讯需要通过一个中介(例如：防火墙等)或者是中介不能识别消息的内容时通道经常被使用。
     代理(Proxy)：一个中間程序它可以充当一个服务器，也可以充当一个客户机为其它客户机建立请求。请求是通过可能的翻译在内部或经过传递到其它的 服務器中一个代理在发送请求信息之前，必须解释并且如果可能重写它代理经常作为通过防火墙的客户机端的门户，代理还可以作为一個帮助应用来通过协议处 理没有被用户代理完成的请求
网关(Gateway)：一个作为其它服务器中间媒介的服务器。与代理不同的是网关接受请求僦好象对被请求的资源来说它就是源服务器；发出请求的客户机并没有意识到它在同网关打交道。
网关经常作为通过防火墙的服务器端的門户网关还可以作为一个协议翻译器以便存取那些存储在非HTTP系统中的资源。
    通道(Tunnel)：是作为两个连接中继的中介程序一旦激活，通道便被认为不属于HTTP通讯尽管通道可能是被一个HTTP请求初始化的。当被中继 的连接两端关闭时通道便消失。当一个门户(Portal)必须存在或中介(Intermediary)不能解釋中继的通讯时通道被经常使用

2、协议分析的优势—HTTP分析器检测网络攻击

以模块化的方式对高层协议进行分析处理，将是未来入侵检测嘚方向

另外，ajax异步请求同样遵循HTTP协议原理大同小异。

浏览器加载显示html页面内容的顺序

我们经常看到浏览器在加载某个页面时,部分内容先显示出来,又有些内容后显示那么浏览器加载显示html究竟是按什么顺序进行的呢?

其实浏览器加载显示html的顺序是按下面的顺序进行的：
1、IE下載的顺序是从上到下，渲染的顺序也是从上到下下载和渲染是同时进行的。
2、在渲染到页面的某一部分时其上面的所有部分都已经下載完成（并不是说所有相关联的元素都已经下载完）。
3、如果遇到语义解释性的标签嵌入文件（JS脚本CSS 剑? 敲创耸盜E的下载过程会启用单獨连接进行下载。
4、并且在下载后进行解析解析过程中，停止页面所有往下元素的下载
5、样式表在下载完成后，将和以前下载的所有樣式表一起进行解析解析完成后，将对此前所有元素（含以前已经渲染的）重新进行渲染
6、JS、CSS中如有重定义，后定义函数将覆盖前定義函数

Firefox处理下载和渲染顺序大体相同，只是在细微之处有些差别例如：iframe的渲染

如果你的网页比较大，希望部分内容先显示出来粘住瀏览者，那么你可以按照上面的规则合理的布局你的网页达到预期的目的。

不能并行下载和解析（阻塞下载）
当 引用了JS的时候浏览器發送1个jsrequest就会一直等待该request的返回。因为浏览器需要1个稳定的DOM树结构而JS中很有可能有代 码直接改变了DOM树结构，比如使用 到你看到google主页过程中嘟发生了什么

本文将基于一些开源浏览器的例子——Firefox、 Chrome及Safari，Safari是部分开源的

根据W3C（World Wide Web Consortium 万维网联盟）的浏览器统计数据，当前（2011年5月）Firefox、Safari忣Chrome的市场占有率综合已接近60％。（原文为2009年10月数据没有太大变化）因此，可以说开源浏览器已经占据了浏览器市场的半壁江山

浏览器嘚主要功能是将用户选择得web资源呈现出来，它需要从服务器请求资源并将其显示在浏览器窗口中，资源的格式通常是HTML也包括PDF、image及其他格式。用户用URI（Uniform Resource Identifier 统一资源标识符）来指定所请求资源的位置在网络一章有更多讨论。

HTML和CSS规范中规定了浏览器解释html文档的方式由 W3C组织对這些规范进行维护，W3C是负责制定web标准的组织

这些年来，浏览器厂商纷纷开发自己的扩展对规范的遵循并不完善，这为web开发者带来了严偅的兼容性问题

但是，浏览器的用户界面则差不多常见的用户界面元素包括：

奇怪的是，并没有哪个正式公布的规范对用户界面做出規定这些是多年来各浏览器厂商之间相互模仿和不断改进得结果。

并没有规定浏览器必须具有的UI元素但列出了一些常用元素，包括地址栏、状态栏及工具栏还有一些浏览器有自己专有得功能，比如Firefox得下载管理更多相关内容将在后面讨论用户界面时介绍。

浏览器的主偠组件包括：

1.     用户界面－包括地址栏、后退/前进按钮、书签目录等也就是你所看到的除了用来显示你所请求页面的主窗口之外的其他部汾

3.     渲染引擎－用来显示请求的内容，例如如果请求内容为html，它负责解析html及css并将解析后的结果显示出来

4.     网络－用来完成网络调用，例如http請求它具有平台无关的接口，可以在不同平台上工作

5.     UI后端－用来绘制类似组合选择框及对话框等基本组件具有不特定于某个平台的通鼡接口，底层使用的用户接口

7.     数据存储－属于持久层浏览器需要在硬盘中保存类似cookie的各种数据，HTML5定义了web database技术这是一种轻量级完整的客戶端存储技术

需要注意的是，不同于大部分浏览器Chrome为每个Tab分配了各自的渲染引擎实例，每个Tab就是一个独立的进程

对于构成浏览器的这些组件，后面会逐一详细讨论

Firefox和Chrome都开发了一个特殊的通信结构，后面将有专门的一章进行讨论

渲染引擎的职责就是渲染，即在浏览器窗口中显示所请求的内容

默认情况下，渲染引擎可以显示html、xml文档及图片它也可以借助插件（一种浏览器扩展）显示其他类型数据，例洳使用PDF阅读器插件可以显示PDF格式，将由专门一章讲解插件及扩展这里只讨论渲染引擎最主要的用途——显示应用了CSS之后的html及图片。

Webkit是┅款开源渲染引擎它本来是为平台研发的，后来由Apple移植到Mac及Windows上相关内容请参考。

渲染引擎首先通过网络获得所请求文档的内容通常鉯8K分块的方式完成。

下面是渲染引擎在取得内容之后的基本流程：

图2：渲染引擎基本流程

渲染引擎开始解析html并将标签转化为内容树中的dom節点。接着它解析外部CSS文件及style标签中的样式信息。这些样式信息以及html中的可见性指令将被用来构建另一棵树——render树

Render树由一些包含有颜銫和大小等属性的矩形组成，它们将被按照正确的顺序显示到屏幕上

Render树构建好了之后，将会执行布局过程它将确定每个节点在屏幕上嘚确切坐标。再下一步就是绘制即遍历render树，并使用UI后端层绘制每个节点

值得注意的是，这个过程是逐步完成的为了更好的用户体验，渲染引擎将会尽可能早的将内容呈现到屏幕上并不会等到所有的html都解析完成之后再去构建和布局render树。它是解析完一部分内容就显示一蔀分内容同时，可能还在通过网络下载其余内容

从图3和4中可以看出，尽管webkit和Gecko使用的术语稍有不同他们的主要流程基本相同。Gecko称可见嘚格式化元素组成的树为frame树每个元素都是一个frame，webkit则使用render树这个名词来命名由渲染对象组成的树Webkit中元素的定位称为布局，而Gecko中称为回流Webkit称利用dom节点及样式信息去构建render树的过程为attachment，Gecko在html和dom树之间附加了一层这层称为内容接收器，相当制造dom元素的工厂下面将讨论流程中的各个阶段。

既然解析是渲染引擎中一个非常重要的过程我们将稍微深入的研究它。首先简要介绍一下解析

解析一个文档即将其转换为具有一定意义的结构——编码可以理解和使用的东西。解析的结果通常是表达文档结构的节点树称为解析树或语法树。

例如解析“2＋3－1”这个表达式，可能返回这样一棵树

解析基于文档依据的语法规则——文档的语言或格式。每种可被解析的格式必须具有由词汇及语法规则组成的特定的文法称为上下文无关文法。人类语言不具有这一特性因此不能被一般的解析技术所解析。

解析可以分为两个子过程——语法分析及词法分析

词法分析就是将输入分解为符号符号是语言的词汇表——基本有效单元的集合。对于人类语言来说它相当於我们字典中出现的所有单词。

语法分析指对语言应用语法规则

解析器一般将工作分配给两个组件——词法分析器（有时也叫分词器）負责将输入分解为合法的符号，解析器则根据语言的语法规则分析文档结构从而构建解析树，词法分析器知道怎么跳过空白和换行之类嘚无关字符

图6：从源文档到解析树

解析过程是迭代的，解析器从词法分析器处取道一个新的符号并试着用这个符号匹配一条语法规则，如果匹配了一条规则这个符号对应的节点将被添加到解析树上，然后解析器请求另一个符号如果没有匹配到规则，解析器将在内部保存该符号并从词法分析器取下一个符号，直到所有内部保存的符号能够匹配一项语法规则如果最终没有找到匹配的规则，解析器将拋出一个异常这意味着文档无效或是包含语法错误。

很多时候解析树并不是最终结果。解析一般在转换中使用——将输入文档转换为叧一种格式编译就是个例子，编译器在将一段源码编译为机器码的时候先将源码解析为解析树，然后将该树转换为一个机器码文档

圖5中，我们从一个数学表达式构建了一个解析树这里定义一个简单的数学语言来看下解析过程。

词汇表：我们的语言包括整数、加号及減号

现在来分析一下“2＋3－1”这个输入

第一个匹配规则的子字符串是“2”，根据规则5它是一个term，第二个匹配的是“2＋3”它符合第2条規则——一个操作符连接两个term，下一次匹配发生在输入的结束处“2＋3－1”是一个表达式，因为我们已经知道“2＋3”是一个term所以我们有叻一个term紧跟着一个操作符及另一个term。“2＋＋”将不会匹配任何规则因此是一个无效输入。

词汇表通常利用正则表达式来定义

例如上面嘚语言可以定义为：

正如看到的，这里用正则表达式定义整数

语法通常用BNF格式定义，我们的语言可以定义为：

如果一个语言的文法是上丅文无关的则它可以用正则解析器来解析。对上下文无关文法的一个直观的定义是该文法可以用BNF来完整的表达。可查看

有两种基本嘚解析器——自顶向下解析及自底向上解析。比较直观的解释是自顶向下解析，查看语法的最高层结构并试着匹配其中一个；自底向上解析则从输入开始逐步将其转换为语法规则，从底层规则开始直到匹配高层规则

来看一下这两种解析器如何解析上面的例子：

自顶向丅解析器从最高层规则开始——它先识别出“2＋3“，将其视为一个表达式然后识别出”2＋3－1“为一个表达式（识别表达式的过程中匹配叻其他规则，但出发点是最高层规则）

自底向上解析会扫描输入直到匹配了一条规则，然后用该规则取代匹配的输入直到解析完所有輸入。部分匹配的表达式被放置在解析堆栈中

自底向上解析器称为shift reduce 解析器，因为输入向右移动（想象一个指针首先指向输入开始处并姠右移动），并逐渐简化为语法规则

解析器生成器这个工具可以自动生成解析器，只需要指定语言的文法——词汇表及语法规则它就鈳以生成一个解析器。创建一个解析器需要对解析有深入的理解而且手动的创建一个由较好性能的解析器并不容易，所以解析生成器很囿用Webkit使用两个知名的解析生成器——用于创建语法分析器的Flex及创建解析器的Bison（你可能接触过Lex和Yacc）。Flex的输入是一个包含了符号定义的正则表达式Bison的输入是用BNF格式表示的语法规则。

HTML解析器的工作是将html标识解析为解析树

W3C组织制定规范定义了HTML的词汇表和语法。

正如在解析简介Φ提到的上下文无关文法的语法可以用类似BNF的格式来定义。

不幸的是所有的传统解析方式都不适用于html（当然我提出它们并不只是因为恏玩，它们将用来解析css和js）html不能简单的用解析所需的上下文无关文法来定义。

Html 有一个正式的格式定义——DTD（Document Type Definition 文档类型定义）——但它并鈈是上下文无关文法html更接近于xml，现在有很多可用的xml解析器html有个xml的变体——xhtml，它们间的不同在于html更宽容，它允许忽略一些特定标签囿时可以省略开始或结束标签。总的来说它是一种soft语法，不像xml呆板、固执

显然，这个看起来很小的差异却带来了很大的不同一方面，这是html流行的原因——它的宽容使web开发人员的工作更加轻松但另一方面，这也使很难去写一个格式化的文法所以，html的解析并不简单咜既不能用传统的解析器解析，也不能用xml解析器解析

Html适用DTD格式进行定义，这一格式是用于定义SGML家族的语言包括了对所有允许元素及它們的属性和层次关系的定义。正如前面提到的htmlDTD并没有生成一种上下文无关文法。

DTD有一些变种标准模式只遵守规范，而其他模式则包含叻对浏览器过去所使用标签的支持这么做是为了兼容以前内容。最新的标准DTD在

输出的树也就是解析树，是由DOM元素及属性节点组成的DOM昰文档对象模型的缩写，它是html文档的对象表示作为html元素的外部接口供js等调用。

树的根是“document”对象

DOM和标签基本是一一对应的关系，例如如下的标签：

将会被转换为下面的DOM树：

图8：示例标签对应的DOM树

和html一样，DOM的规范也是由W3C组织制定的访问，这是使用文档的一般规范一個模型描述一种特定的html元素，可以在 查看html定义

这里所谓的树包含了DOM节点是说树是由实现了DOM接口的元素构建而成的，浏览器使用已被浏览器内部使用的其他属性的具体实现

正如前面章节中讨论的，hmtl不能被一般的自顶向下或自底向上的解析器所解析

3.     解析过程是往复的，通瑺源码不会在解析过程中发生改变但在html中，脚本标签包含的“document.write ”可能添加标签这说明在解析过程中实际上修改了输入

不能使用正则解析技术，浏览器为html定制了专属的解析器

Html5规范中描述了这个解析，算法包括两个阶段——符号化及构建树

符号化是词法分析的过程，将輸入解析为符号html的符号包括开始标签、结束标签、属性名及属性值。

符号识别器识别出符号后将其传递给树构建器，并读取下一个字苻以识别下一个符号，这样直到处理完所有输入

图9：HTML解析流程

算法输出html符号，该算法用状态机表示每次读取输入流中的一个或多个芓符，并根据这些字符转移到下一个状态当前的符号状态及构建树状态共同影响结果，这意味着读取同样的字符，可能因为当前状态嘚不同得到不同的结果以进入下一个正确的状态。

这个算法很复杂这里用一个简单的例子来解释这个原理。

基本示例——符号化下面嘚html：

初始状态为“Data State”当遇到“<”字符，状态变为“Tag open state”读取一个a－z的字符将产生一个开始标签符号，状态相应变为“Tag name state”一直保持这个狀态直到读取到“>”，每个字符都附加到这个符号名上例子中创建的是一个html符号。

当读取到“>”当前的符号就完成了，此时状态回箌“Data state”，“<body>”重复这一处理过程到这里，html和body标签都识别出来了现在，回到“Data state”读取“Hello world”中的字符“H”将创建并识别出一个字符符号，这里会为“Hello world”中的每个字符生成一个字符符号

这样直到遇到“</body>”中的“<”。现在又回到了“Tag open state”，读取下一个字符“/”将创建一个闭匼标签符号并且状态转移到“Tag name state”，还是保持这一状态直到遇到“>”。然后产生一个新的标签符号并回到“Data state”。后面的“</html>”将和“</body>”┅样处理

图10：符号化示例输入

在树的构建阶段，将修改以Document为根的DOM树将元素附加到树上。每个由符号识别器识别生成的节点将会被树构慥器进行处理规范中定义了每个符号相对应的Dom元素，对应的Dom元素将会被创建这些元素除了会被添加到Dom树上，还将被添加到开放元素堆棧中这个堆栈用来纠正嵌套的未匹配和未闭合标签，这个算法也是用状态机来描述所有的状态采用插入模式。

来看一下示例中树的创建过程：

构建树这一阶段的输入是符号识别阶段生成的符号序列

首先是“initial mode”，接收到html符号后将转换为“before html”模式在这个模式中对这个符號进行再处理。此时创建了一个HTMLHtmlElement元素，并将其附加到根Document对象上

状态此时变为“before head”，接收到body符号时即使这里没有head符号，也将自动创建┅个HTMLHeadElement元素并附加到树上

现在，转到“in head”模式然后是“after head”。到这里body符号会被再次处理，将创建一个HTMLBodyElement并插入到树中同时，转移到“in body”模式

然后，接收到字符串“Hello world”的字符符号第一个字符将导致创建并插入一个text节点，其他字符将附加到该节点

接收到body结束符号时，转迻到“afterbody”模式接着接收到html结束符号，这个符号意味着转移到了“after after body”模式当接收到文件结束符时，整个解析过程结束

图11：示例html树的构建过程

在这个阶段，浏览器将文档标记为可交互的并开始解析处于延时模式中的脚本——这些脚本在文档解析后执行。

文档状态将被设置为完成同时触发一个load事件。

你从来不会在一个html页面上看到“无效语法”这样的错误浏览器修复了无效内容并继续工作。

以下面这段html為例：

这段html违反了很多规则（mytag不是合法的标签p及div错误的嵌套等等），但是浏览器仍然可以没有任何怨言的继续显示它在解析的过程中修复了html作者的错误。

浏览器都具有错误处理的能力但是，另人惊讶的是这并不是html最新规范的内容，就像书签及前进后退按钮一样它呮是浏览器长期发展的结果。一些比较知名的非法html结构在许多站点中出现过，浏览器都试着以一种和其他浏览器一致的方式去修复

Html5规范定义了这方面的需求，webkit在html解析类开始部分的注释中做了很好的总结

解析器将符号化的输入解析为文档并创建文档，但不幸的是我们必须处理很多没有很好格式化的html文档，至少要小心下面几种错误情况

1.     在未闭合的标签中添加明确禁止的元素。这种情况下应该先将前┅标签闭合

3.     想在一个行内元素中添加块状元素。关闭所有的行内元素直到下一个更高的块状元素

下面来看一些webkit容错的例子：

Note－这里的错誤处理在内部进行，用户看不到

这指一个表格嵌套在另一个表格中，但不在它的某个单元格内

webkit将会将嵌套的表格变为两个兄弟表格：

webkit使用堆栈存放当前的元素内容，它将从外部表格的堆栈中弹出内部的表格则它们变为了兄弟表格。

用户将一个表单嵌套到另一个表单中则第二个表单将被忽略。

是一个由嵌套层次的站点的例子最多只允许20个相同类型的标签嵌套，多出来的将被忽略

放错了地方的html、body闭匼标签

支持不完整的html。我们从来不闭合body因为一些愚蠢的网页总是在还未真正结束时就闭合它。我们依赖调用end方法去执行关闭的处理

所鉯，web开发者要小心了除非你想成为webkit容错代码的范例，否则还是写格式良好的html吧

还记得简介中提到的解析的概念吗，不同于htmlcss属于上下攵无关文法，可以用前面所描述的解析器来解析Css规范定义了css的词法及语法文法。

每个符号都由正则表达式定义了词法文法（词汇表）：

“ident”是识别器的缩写相当于一个class名，“name”是一个元素id（用“＃”引用）

语法用BNF进行描述：

说明：一个规则集合有这样的结构

div.error和a.error时选择器，大括号中的内容包含了这条规则集合中的规则这个结构在下面的定义中正式的定义了：

这说明，一个规则集合具有一个或是可选个數的多个选择器这些选择器以逗号和空格（S表示空格）进行分隔。每个规则集合包含大括号及大括号中的一条或多条以分号隔开的声明声明和选择器在后面进行定义。

Webkit使用Flex和Bison解析生成器从CSS语法文件中自动生成解析器回忆一下解析器的介绍，Bison创建一个自底向上的解析器Firefox使用自顶向下解析器。它们都是将每个css文件解析为样式表对象每个对象包含css规则，css规则对象包含选择器和声明对象以及其他一些符匼css语法的对象。

web的模式是同步的开发者希望解析到一个script标签时立即解析执行脚本，并阻塞文档的解析直到脚本执行完如果脚本是外引嘚，则网络必须先请求到这个资源——这个过程也是同步的会阻塞文档的解析直到资源被请求到。这个模式保持了很多年并且在html4及html5中嘟特别指定了。开发者可以将脚本标识为defer以使其不阻塞文档解析，并在文档解析结束后执行Html5增加了标记脚本为异步的选项，以使脚本嘚解析执行使用另一个线程

Webkit和Firefox都做了这个优化，当执行脚本时另一个线程解析剩下的文档，并加载后面需要通过网络加载的资源这種方式可以使资源并行加载从而使整体速度更快。需要注意的是预解析并不改变Dom树，它将这个工作留给主解析过程自己只解析外部资源的引用，比如外部脚本、样式表及图片

样式表采用另一种不同的模式。理论上既然样式表不改变Dom树，也就没有必要停下文档的解析等待它们然而，存在一个问题脚本可能在文档的解析过程中请求样式信息，如果样式还没有加载和解析脚本将得到错误的值，显然這将会导致很多问题这看起来是个边缘情况，但确实很常见Firefox在存在样式表还在加载和解析时阻塞所有的脚本，而chrome只在当脚本试图访问某些可能被未加载的样式表所影响的特定的样式属性时才阻塞这些脚本

当Dom树构建完成时，浏览器开始构建另一棵树——渲染树渲染树甴元素显示序列中的可见元素组成，它是文档的可视化表示构建这棵树是为了以正确的顺序绘制文档内容。

一个渲染对象直到怎么布局忣绘制自己及它的children

每个渲染对象用一个和该节点的css盒模型相对应的矩形区域来表示，正如css2所描述的那样它包含诸如宽、高和位置之类嘚几何信息。盒模型的类型受该节点相关的display样式属性的影响（参考样式计算章节）下面的webkit代码说明了如何根据display属性决定某个节点创建何種类型的渲染对象。

元素的类型也需要考虑例如，表单控件和表格带有特殊的框架

在webkit中，如果一个元素想创建一个特殊的渲染对象咜需要复写“createRenderer”方法，使渲染对象指向不包含几何信息的样式对象

渲染对象和Dom元素相对应，但这种对应关系不是一对一的不可见的Dom元素不会被插入渲染树，例如head元素另外，display属性为none的元素也不会在渲染树中出现（visibility属性为hidden的元素将出现在渲染树中）

还有一些Dom元素对应几個可见对象，它们一般是一些具有复杂结构的元素无法用一个矩形来描述。例如select元素有三个渲染对象——一个显示区域、一个下拉列表及一个按钮。同样当文本因为宽度不够而折行时，新行将作为额外的渲染元素被添加另一个多个渲染对象的例子是不规范的html，根据css規范一个行内元素只能仅包含行内元素或仅包含块状元素，在存在混合内容时将会创建匿名的块状渲染对象包裹住行内元素。

一些渲染对象和所对应的Dom节点不在树上相同的位置例如，浮动和绝对定位的元素在文本流之外在两棵树上的位置不同，渲染树上标识出真实嘚结构并用一个占位结构标识出它们原来的位置。

图12：渲染树及对应的Dom树

Firefox中表述为一个监听Dom更新的监听器，将frame的创建委派给Frame Constructor这个构建器计算样式（参看样式计算）并创建一个frame。

Webkit中计算样式并生成渲染对象的过程称为attachment，每个Dom节点有一个attach方法attachment的过程是同步的，调用新節点的attach方法将节点插入到Dom树中

处理html和body标签将构建渲染树的根，这个根渲染对象对应被css规范称为containing block的元素——包含了其他所有块元素的顶级塊元素它的大小就是viewport——浏览器窗口的显示区域，Firefox称它为viewPortFramewebkit称为RenderView，这个就是文档所指向的渲染对象树中其他的部分都将作为一个插入嘚Dom节点被创建。

创建渲染树需要计算出每个渲染对象的可视属性这可以通过计算每个元素的样式属性得到。

样式包括各种来源的样式表行内样式元素及html中的可视化属性（例如bgcolor），可视化属性转化为css样式属性

样式表来源于浏览器默认样式表，及页面作者和用户提供的样式表——有些样式是浏览器用户提供的（浏览器允许用户定义喜欢的样式例如，在Firefox中可以通过在Firefox Profile目录下放置样式表实现）。

1.     样式数据昰非常大的结构保存大量的样式属性会带来内存问题

2.     如果不进行优化，找到每个元素匹配的规则会导致性能问题为每个元素查找匹配嘚规则都需要遍历整个规则表，这个过程有很大的工作量选择符可能有复杂的结构，匹配过程如果沿着一条开始看似正确后来却被证奣是无用的路径，则必须去尝试另一条路径

例如，下面这个复杂选择符

这意味着规则应用到三个div的后代div元素选择树上一条特定的路径詓检查，这可能需要遍历节点树最后却发现它只是两个div的后代，并不使用该规则然后则需要沿着另一条路径去尝试

我们来看一下浏览器如何处理这些问题：

webkit节点引用样式对象（渲染样式），某些情况下这些对象可以被节点间共享，这些节点需要是兄弟或是表兄弟节点并且：

10.  不能有生效的兄弟选择器，webcore在任何兄弟选择器相遇时只是简单的抛出一个全局转换并且在它们显示时使整个文档的样式共享失效，这些包括＋选择器和类似:first-child和:last-child这样的选择器

Firefox用两个树用来简化样式计算－规则树和样式上下文树，webkit也有样式对象但它们并没有存储茬类似样式上下文树这样的树中，只是由Dom节点指向其相关的样式

样式上下文包含最终值，这些值是通过以正确顺序应用所有匹配的规则并将它们由逻辑值转换为具体的值，例如如果逻辑值为屏幕的百分比，则通过计算将其转化为绝对单位样式树的使用确实很巧妙，咜使得在节点中共享的这些值不需要被多次计算同时也节省了存储空间。

所有匹配的规则都存储在规则树中一条路径中的底层节点拥囿最高的优先级，这棵树包含了所找到的所有规则匹配的路径（译注：可以取巧理解为每条路径对应一个节点路径上包含了该节点所匹配的所有规则）。规则树并不是一开始就为所有节点进行计算而是在某个节点需要计算样式时，才进行相应的计算并将计算后的路径添加到树中

我们将树上的路径看成辞典中的单词，假如已经计算出了如下的规则树：

假如需要为内容树中的另一个节点匹配规则现在知噵匹配的规则（以正确的顺序）为B-E-I，因为我们已经计算出了路径A-B-E-I-L所以树上已经存在了这条路径，剩下的工作就很少了

现在来看一下树洳何保存。

样式上下文按结构划分这些结构包括类似border或color这样的特定分类的样式信息。一个结构中的所有特性不是继承的就是非继承的對继承的特性，除非元素自身有定义否则就从它的parent继承。非继承的特性（称为reset特性）如果没有定义则使用默认的值。

样式上下文树缓存完整的结构（包括计算后的值）这样，如果底层节点没有为一个结构提供定义则使用上层节点缓存的结构。

使用规则树计算样式上丅文

当为一个特定的元素计算样式时首先计算出规则树中的一条路径，或是使用已经存在的一条然后使用路径中的规则去填充新的样式上下文，从样式的底层节点开始它具有最高优先级（通常是最特定的选择器），遍历规则树直到填满结构。如果在那个规则节点没囿定义所需的结构规则则沿着路径向上，直到找到该结构规则

如果最终没有找到该结构的任何规则定义，那么如果这个结构是继承型嘚则找到其在内容树中的parent的结构，这种情况下我们也成功的共享了结构；如果这个结构是reset型的，则使用默认的值

如果特定的节点添加了值，那么需要做一些额外的计算以将其转换为实际值然后在树上的节点缓存该值，使它的children可以使用

当一个元素和它的一个兄弟元素指向同一个树节点时，完整的样式上下文可以被它们共享

来看一个例子：假设有下面这段html

简化下问题，我们只填充两个结构——color和margincolor結构只包含一个成员－颜色，margin结构包含四边

生成的规则树如下（节点名：指向的规则）

上下文树如下（节点名：指向的规则节点）

假设峩们解析html，遇到第二个div标签我们需要为这个节点创建样式上下文，并填充它的样式结构

我们进行规则匹配，找到这个div匹配的规则为1、2、6我们发现规则树上已经存在了一条我们可以使用的路径1、2，我们只需为规则6新增一个节点添加到下面（就是规则树中的F）

然后创建┅个样式上下文并将其放到上下文树中，新的样式上下文将指向规则树中的节点F

现在我们需要填充这个样式上下文，先从填充margin结构开始既然最后一个规则节点没有添加margin结构，沿着路径向上直到找到缓存的前面插入节点计算出的结构，我们发现B是最近的指定margin值的节点洇为已经有了color结构的定义，所以不能使用缓存的结构既然color只有一个属性，也就不需要沿着路径向上填充其他属性计算出最终值（将字苻串转换为RGB等），并缓存计算后的结构

第二个span元素更简单，进行规则匹配后发现它指向规则G和前一个span一样，既然有兄弟节点指向同一個节点就可以共享完整的样式上下文，只需指向前一个span的上下文

因为结构中包含继承自parent的规则，上下文树做了缓存（color特性是继承来的但Firefox将其视为reset并在规则树中缓存）。

例如如果我们为一个paragraph的文字添加规则：

那么这个p在内容树中的子节点div，会共享和它parent一样的font结构这種情况发生在没有为这个div指定font规则时。

Webkit中并没有规则树，匹配的声明会被遍历四次先是应用非important的高优先级属性（之所以先应用这些属性，是因为其他的依赖于它们－比如display）其次是高优先级important的，接着是一般优先级非important的最后是一般优先级important的规则。这样出现多次的属性將被按照正确的级联顺序进行处理，最后一个生效

总结一下，共享样式对象（结构中完整或部分内容）解决了问题1和3Firefox的规则树帮助以囸确的顺序应用规则。

对规则进行处理以简化匹配过程

后面两个很容易匹配到元素因为它们所拥有的样式属性和html属性可以将元素作为key进荇映射。

就像前面问题2所提到的css的规则匹配可能很狡猾，为了解决这个问题可以先对规则进行处理，以使其更容易被访问

解析完样式表之后，规则会根据选择符添加一些hash映射映射可以是根据id、class、标签名或是任何不属于这些分类的综合映射。如果选择符为id规则将被添加到id映射，如果是class则被添加到class映射，等等

这个处理是匹配规则更容易，不需要查看每个声明我们能从映射中找到一个元素的相关規则，这个优化使在进行规则匹配时减少了95＋％的工作量

第一条规则将被插入class映射，第二条插入id映射第三条是标签映射。

下面这个html片段：

我们首先找到p元素对应的规则class映射将包含一个“error”的key，找到p.error的规则div在id映射和标签映射中都有相关的规则，剩下的工作就是找出这些由key对应的规则中哪些确实是正确匹配的

例如，如果div的规则是

这也是标签映射产生的因为key是最右边的选择符，但它并不匹配这里的div元素因为这里的div没有table祖先。

以正确的级联顺序应用规则

样式对象拥有对应所有可见属性的属性如果特性没有被任何匹配的规则所定义，那么一些特性可以从parent的样式对象中继承另外一些使用默认值。

这个问题的产生是因为存在不止一处的定义这里用级联顺序解决这个问題。

一个样式属性的声明可能在几个样式表中出现或是在一个样式表中出现多次，因此应用规则的顺序至关重要，这个顺序就是级联順序根据css2的规范，级联顺序为（从低到高）：

浏览器声明是最不重要的用户只有在声明被标记为important时才会覆盖作者的声明。具有同等级別的声明将根据specifity以及它们被定义时的顺序进行排序Html可视化属性将被转换为匹配的css声明，它们被视为最低优先级的作者规则

连接a－b－c－d㈣个数量（用一个大基数的计算系统）将得到specifity。这里使用的基数由分类中最高的基数定义例如，如果a为14可以使用16进制。不同情况下a為17时，则需要使用阿拉伯数字17作为基数这种情况可能在这个选择符时发生html body div div …（选择符中有17个标签，一般不太可能）

规则匹配后，需要根据级联顺序对规则进行排序webkit先将小列表用冒泡排序，再将它们合并为一个大列表webkit通过为规则复写“>”操作来执行排序：

webkit使用一个标誌位标识所有顶层样式表都已加载，如果在attch时样式没有完全加载则放置占位符，并在文档中标记一旦样式表完成加载就重新进行计算。

当渲染对象被创建并添加到树中它们并没有位置和大小，计算这些值的过程称为layout或reflow

Html使用基于流的布局模型，意味着大部分时间可鉯以单一的途径进行几何计算。流中靠后的元素并不会影响前面元素的几何特性所以布局可以在文档中从右向左、自上而下的进行。也存在一些例外比如html tables。

坐标系统相对于根frame使用top和left坐标。

布局是一个递归的过程由根渲染对象开始，它对应html文档元素布局继续递归的通过一些或所有的frame层级，为每个需要几何信息的渲染对象进行计算

根渲染对象的位置是0,0，它的大小是viewport－浏览器窗口的可见部分

所有的渲染对象都有一个layout或reflow方法，每个渲染对象调用需要布局的children的layout方法

为了不因为每个小变化都全部重新布局，浏览器使用一个dirty bit系统一个渲染对象发生了变化或是被添加了，就标记它及它的children为dirty－需要layout存在两个标识－dirty及children are dirty，children are dirty说明即使这个渲染对象可能没问题但它至少有一个child需偠layout。

当layout在整棵渲染树触发时称为全局layout，这可能在下面这些情况下发生：

layout也可以是增量的这样只有标志为dirty的渲染对象会重新布局（也将導致一些额外的布局）。增量 layout会在渲染对象dirty时异步触发例如，当网络接收到新的内容并添加到Dom树后新的渲染对象会添加到渲染树中。

增量layout的过程是异步的Firefox为增量layout生成了reflow队列，以及一个调度执行这些批处理命令Webkit也有一个计时器用来执行增量layout－遍历树，为dirty状态的渲染对潒重新布局

另外，当脚本请求样式信息时例如“offsetHeight”，会同步的触发增量布局

全局的layout一般都是同步触发。

有些时候layout会被作为一个初始layout之后的回调，比如滑动条的滑动

当一个layout因为resize或是渲染位置改变（并不是大小改变）而触发时，渲染对象的大小将会从缓存中读取而鈈会重新计算。

一般情况下如果只有子树发生改变，则layout并不从根开始这种情况发生在，变化发生在元素自身并且不影响它周围元素唎如，将文本插入文本域（否则每次击键都将触发从根开始的重排）。

layout一般有下面这几个部分：

渲染对象的宽度使用容器的宽度、渲染對象样式中的宽度及margin、border进行计算例如，下面这个div的宽度：

到这里是最佳宽度的计算过程现在计算宽度的最大值和最小值，如果最佳宽喥大于最大宽度则使用最大宽度如果小于最小宽度则使用最小宽度。最后缓存这个值当需要layout但宽度未改变时使用。

当一个渲染对象在咘局过程中需要折行时则暂停并告诉它的parent它需要折行，parent将创建额外的渲染对象并调用它们的layout

绘制阶段，遍历渲染树并调用渲染对象的paint方法将它们的内容显示在屏幕上绘制使用UI基础组件，这在UI的章节有更多的介绍

和布局一样，绘制也可以是全局的－绘制完整的树－或增量的在增量的绘制过程中，一些渲染对象以不影响整棵树的方式改变改变的渲染对象使其在屏幕上的矩形区域失效，这将导致操作系统将其看作dirty区域并产生一个paint事件，操作系统很巧妙的处理这个过程并将多个区域合并为一个。Chrome中这个过程更复杂些，因为渲染对潒在不同的进程中而不是在主进程中。Chrome在一定程度上模拟操作系统的行为表现为监听事件并派发消息给渲染根，在树中查找到相关的渲染对象重绘这个对象（往往还包括它的children）。

css2定义了绘制过程的顺序－这个就是元素压入堆栈的顺序，这个顺序影响着绘制堆栈从後向前进行绘制。

一个块渲染对象的堆栈顺序是：

Firefox读取渲染树并为绘制的矩形创建一个显示列表该列表以正确的绘制顺序包含这个矩形楿关的渲染对象。

用这样的方法可以使重绘时只需查找一次树，而不需要多次查找——绘制所有的背景、所有的图片、所有的border等等

Firefox优囮了这个过程，它不添加会被隐藏的元素比如元素完全在其他不透明元素下面。

重绘前webkit将旧的矩形保存为位图，然后只绘制新旧矩形嘚差集

浏览器总是试着以最小的动作响应一个变化，所以一个元素颜色的变化将只导致该元素的重绘元素位置的变化将大致元素的布局和重绘，添加一个Dom节点也会大致这个元素的布局和重绘。一些主要的变化比如增加html元素的字号，将会导致缓存失效从而引起整数嘚布局和重绘。

渲染引擎是单线程的除了网络操作以外，几乎所有的事情都在单一的线程中处理在Firefox和Safari中，这是浏览器的主线程Chrome中这昰tab的主线程。

网络操作由几个并行线程执行并行连接的个数是受限的（通常是2－6个）。

浏览器主线程是一个事件循环它被设计为无限循环以保持执行过程的可用，等待事件（例如layout和paint事件）并执行它们下面是Firefox的主要事件循环代码。

根据CSS2规范术语canvas用来描述格式化的结构所渲染的空间——浏览器绘制内容的地方。画布对每个维度空间都是无限大的但浏览器基于viewport的大小选择了一个初始宽度。

根据的定义畫布如果是包含在其他画布内则是透明的，否则浏览器会指定一个颜色

CSS盒模型描述了矩形盒，这些矩形盒是为文档树中的元素生成的並根据可视的格式化模型进行布局。每个box包括内容区域（如图片、文本等）及可选的四周padding、border和margin区域

每个节点生成0－n个这样的box。

所有的元素都有一个display属性用来决定它们生成box的类型，例如：

inline－生成一个或多个行内box

默认的是inline但浏览器样式表设置了其他默认值，例如div元素默認为block。可以访问查看更多的默认样式表示例

1.     normal－对象根据它在文档的中位置定位，这意味着它在渲染树和在Dom树中位置一致并根据它的盒模型和大小进行布局

在static定位中，不定义位置而使用默认的位置其他策略中，作者指定位置——top、bottom、left、right

Box布局的方式由这几项决定：box的类型、box的大小、定位策略及扩展信息（比如图片大小和屏幕尺寸）。

Block box：构成一个块即在浏览器窗口上有自己的矩形

Inline box：并没有自己的块状区域，但包含在一个块状区域内

block一个挨着一个垂直格式化inline则在水平方向上格式化。

Inline盒模型放置在行内或是line box中每行至少和最高的box一样高，當box以baseline对齐时——即一个元素的底部和另一个box上除底部以外的某点对齐行高可以比最高的box高。当容器宽度不够时行内元素将被放到多行Φ，这在一个p元素中经常发生

相对定位——先按照一般的定位，然后按所要求的差值移动

一个浮动的box移动到一行的最左边或是最右边，其余的box围绕在它周围下面这段html：

这种情况下的布局完全不顾普通的文档流，元素不属于文档流的一部分大小取决于容器。Fixed时容器為viewport（可视区域）。

注意－fixed即使在文档流滚动时也不会移动

这个由CSS属性中的z-index指定，表示盒模型的第三个大小即在z轴上的位置。Box分发到堆棧中（称为堆栈上下文）每个堆栈中靠后的元素将被较早绘制，栈顶靠前的元素离用户最近当发生交叠时，将隐藏靠后的元素堆栈根据z-index属性排序，拥有z-index属性的box形成了一个局部堆栈viewport有外部堆栈，例如：

虽然绿色div排在红色div后面可能在正常流中也已经被绘制在后面，但z-index囿更高优先级所以在根box的堆栈中更靠前。

针对 VM 的性能优化方法

针对 CPU 的性能優化方法

针对 RAM 的性能优化方法

针对 DISK 的性能优化方法

1 、虚拟化逻辑分层示意图

2 、X86 结构下虚拟化的问题

? X86 的 os 通常直接运行在物理硬件层面因此它的执行权限必须为 ring 0.

? X86 虚拟化架构则要求 os 运行在虚拟化层级上面

? 二进制转换是最原始的 32bit x86 虚拟化的指令结构

? 利用二进制转换，就可以實现：

o 让 VMM 单独运行在 ring 0保证相对独立与性能

? CPU 硬件虚拟化使得 VMM 运行虚拟机变得更加简单

? CPU 硬件虚拟化允许 VMM 不依赖二进制转换依然能够完全控制虚拟机

? 两者都是 CPU 的一种指令执行模式，它们的主要功能如下：

o 自动的通过 hypervisor 来获取权限和灵敏度级别

7 、虚拟环境性能分析

o 单台物理服務器上的单台虚拟机

? Hypervisor 位于物理设备与虚拟机之间

o 影响性能的重要因素

o 单台物理机上运行多台虚拟机

? Hypersior 位于物理设备与虚拟机之间

? 调度開锁以及网路、存储、计算资源不足等问题

? 降低第二维度中可能存在的部分性能问题

8 、vSphere 环境中影响性能的因素

9 、关于性能的最佳实践

10 、瑺见的性能问题

? 通常性能问题都应该是在进行综合性能定义、管理的过程中出现的

? 综合所有产品的性能问题而言，性能问题通常体現在如下方面

o 应用程序无法满足预先规划的性能浮动范围

o 用户反馈性能故障或吞吐不足

11 、性能问题排错方法论

? 排查性能问题和排查故障問题很多时候都是相似的或者说：性能问题与故障问题的界限其实是很模糊的，因此都需要遵循类似的方法论才能比较有效的进行排查

? 根据前辈们和厂家总结的经验，通常都建议参考如下 逻辑来定义故障

o 故障的体现形式是什么

o 从哪里着手开始查找问题？

o 如何确定怎樣检查问题

o 是否确认找到问题就是真正意义上的问题所在？

o 想要针对性解决这个问题需要做些什么

o 如果处理之后问题依然存在，接下來该怎么办

二、针对 VM 的性能优化方法

1 、VM 性能相关概览

? 经过精细化配置、调校后的 VM 将会为 Applications 提供一个最好的运行环境

? 通常考虑 VM 的性能相關的参数包含下列几个选项

2 、首先选定合适的 OS 类型

? 在创建 VM 时，一定要正确选择 Guest OS 的类型

? Guest OS 类型会决定缺省的最优化硬件以及配套的设定

? VM 裏的时间计算逻辑会导致 Guest OS 的时间要想保持准确性是很重要的

? 规避这种可能性的方式

o 尽量选择需要较小时间中断的 Guest OS

? 无论如何别用 2 种以仩的时间同少方式

? 被用于提升 VM 的性能和可管理性

? 确保 VMware Tools 是处于正常被 激活状态的，如果没有被激活则请激活它

o 它会影响着 VM 的性能

o 正常狀态下只能升级，不能降级

? 这个版本出现在 vSphere 5.5 当中其上的虚拟机支持下列新功能

o 激活了 SMP，则进程可能会被 跨 vCPUs 进行迁移会导致额外的开銷

? 如果有选择，最好是使用 OS 缺省的建议配置

? 大内存页面状态下：

o 大内存页面内存的使用会降低内存管理开销且能够变相提升 hypervisor 性能

? 为 VM 嘚交换文件单独找个地方存放

o 尽量不要将交换文件存放在 Thin 模式下的 LUN 上面

? 针对 I/O 敏感类型业务选用

? PVSCSI 是一个和 BusLogic 和 LSI Logic 相似的部件但是它是一个低 CPU 开销、高吞吐、低延迟和更好扩展能力的控制器类型

? 如果有的选择，尽量使用 vmxnet3 这款虚拟网路卡：

? 确保物理网路卡运行在全双工模式囷最高速状态

? 在虚拟机开启和成功启动前会消耗大量的资源

o 需要足够的磁盘空间用于存放下面 2 个 vswp 文件

? 为了顺利开启 vm，ESXi Host 必须要有大量嘚 CPU、内存资源用于满足虚拟机的启动当然，还需要包含启动这台虚拟机所需要的额外 Memory 开销

? 想要成功开启 VM 还需要有足够的存储空间存放 swap 攵件

o *.vswp 交换文件的大小取决于虚拟机已配置的内存及预留值

? 创建虚拟机的向导中会根据 Guest OS 类型不同而设定不同的默认建议选择

16 、VM 性能最佳實践

? 把不必要的设备，例如:USB, CD-ROM, 软驱等删除

? 针对大 I/O 类型的业务需要考虑清楚，因为它会导致 Guest OS 的 I/O 性能受到影响

三、针对 CPU 的性能优化方法

? 基本上可以将 World 理解为 CPU 上调度的执行任务

? 所以，VM 就相当于一级 worlds 的集合

o 一个用于虚拟鼠标、键盘、屏幕（MKS）

? CPU 资源的分配对于用户而言是動态和透明的

o 每个 vCPU 在调度时会按照资源设定的优先级别去调用

o 两颗以上的 vCPUs 的 SMP 虚拟机在调度到不同的 CPU 上时可能存在不同的执行速率，所以會不均衡

o 当除了某个 vCPU 外整体的 vCPUs 的调度并没有完整执行，vCPU 的不均衡程度会加剧

o 当 vCPU 不均衡比例超过一定比例之后也会被判定为不均衡

? 该組件技术表示检测到不均衡之后同时调度大量虚拟机 vCPUs 的技术

? 当 SMP 虚拟机在 vCPUs 之间表现出明显的数据共享时，则依托缓存分布的方式将会是退洏求其次的负载分布方式

o 同一台物理服务器上通过本地内存访问 CPU 的进程效率会高于远程内存

o 当虚拟机的内存分布中大部分不在本地内存昰，就意味着此时的 NUMA 性能是较差的

? CPU 资源不足时的资源调度逻辑

o 如果存在 CPU 争用则 Scheduler 会强行按照优先级顺序去依次满足高优先级>低优先级的虛拟机 CPU 请求

o 如果 vCPU 想要尝试去在没有可用 CPU Cycles 的物理 CPU 上执行指令时，请求会被列入等待队列

? 每一组的统计数据信息：

? 输入"V"可以查看虚拟机的楿关输出信息

? 输入"e"可以显示为虚拟机分配的所有可用 worlds

? 用于监控性能的重要指标

? 这个值通常都意味着高资源使用率

? 这个参数适用于幾乎所有的对象

? 这是衡量 CPU 是否存在性能问题的重要指标

注：x x = 时间单位 ms ， 20000 单位为 ms 缺省系统刷新周期为 20s ， y = RDY 的百分比（超过 10% 时则会存在性能问题超过 5% 时可能就会存在，但当时可能并不存在严重性的性能问题）

四、针对 RAM 的性能优化方法

? Guest 里面可在评估活动内存状况时更加直觀

? ESXi 活动内存评估技术需要时间去完成

? Host memory 使用情况会基于虚拟机在物理主机和 Guest 内存使用相关优先级而定

o 这种情况下则性能可能存在问题

14 、解决内存不瞳的问题

? 同时开启大量虚拟机时就会出现这个情况

o 此时，虚拟机会消耗大量的内存

? Host-Level Swapping 会导致启动缓慢不过，完成启动之後不一定会影响性能

? 虚拟机的内存被 Swap Out 到磁盘时，也不一定会影响性能如果这部分内存不被访问的话

五、针对 DISK 的性能优化方法

? 检查昰否存在磁盘故障

o 确认是否有足够的带宽，看看是否能满足预期应用的开销需求

? 针对这样的问题怎么办？

o 检查相关的关键参数包含類似下面几个参数：

? 磁盘命令的被迫终止数目

? 关键参数：读、写速率和使用情况

? 下面几个参数被用于评估磁盘的吞吐情况：

? 也可鉯选用 MB 的方式来计算

5 、磁盘吞吐状况范例

?注：输入字母 d 可以看 hba 卡相关的信息

o输入字母 u 可以查看 lun 的相关信息

o输入字母 v 可以查看虚拟机相关嘚信息

8 、监控命令和队列命令

10 、监控是否存在严重存储过载

13 、设备驱动队列深度

? 设备驱动队列深度决定 LUN 在同一时间支持的活动命令数目

? 设置设备驱动队列值可以用于降低磁盘延迟：

o 其它的通常缺省队列深度为 32.

o 最大队列深度建议为 64.

o 设备驱动队列深度控制着 LUN 上面任意时间的活动命令数目

o VMkernel 队列是设备驱动队列的溢出部分

o 当针对存储阵列的活动命令数据过高时，就会产生这个部分的队列

? 在主机端或存储阵列端洳果有大量的队列就会增加命令延迟

o LUN 在一个较短周期内被单一主机占用的时间

? Metadata 更新的通常会受到下列因素影响：

? 最小化对虚拟机性能影响：

o 别在高峰时期去做前面那些事情

16 、存储多路径技术简介

? 可以帮助解决存储的存储性能故障

o 可以与下列组件结合：

? 衡量网路性能相关的参数有哪些？

? 通常和网路相关的关键参数主要是和网路统计信息相关的部分，包括：

? 输入字母 n 可以查看网路相关的统计示意图

? 相关重要参数包括:

o %DRPRX:接收包的丢包率百分比

o 支持传输包聚合处理

o 支持中断聚合处理以便减轻来自网路的中断开销

9 、影响网路性能的楿关组件

? vSphere 通过结合物理网路卡的新特性，来实现针对网路性能的提升和保障包括：

? 允许利用网路卡针对网路包执行 checksum 操作

? 降低来自粅理 CPU 开销压力

? 能够根据包的大小来不同程度上提供更好的性能支持

? TSO 可以通过减少大量来自 TCP 流量发送所需的 CPU 负载的情况下提升网络性能：

? 较大 TCP 包会被 Offload 到网路卡来进一步细分处理

? 网路卡会将其切割到 MTU 大小的帧

? 如果网络卡支持，则 TSO 会默认在 VMkernel 接口上激活

? 虚拟机级别的 TSO 需偠手动激活

? 在进行包传输前IP 层会将包切片到 MTU 帧大小：

? 接收端自行重组相关数据

? 支持更大的以太网包，最大为 9000 字节

? 可以减少帧的傳输数量

? 可以降低发送和接收端的 CPU 使用率

? 虚拟机端虚拟网路卡最好是配为 vmxnet3

o 利用 DMA 直接访问内存

? 绕过 CPU让 NIC 直接访问内存

? 避免内存空间需要通过 VMkernel 处理一次的情况

? 利用 Scatter-Gathe 的方式来实现将内存写入到不相邻的内存区块

? 允许灵活的使用可用内存，进而提供更好的性能

? NetQueue 的性能提升主要体现在下面几个方面：

? 在 10GbE 和 40GbE 网路卡环境下大幅提升虚拟环境的网路性能

o SplitRx 通过利用多物理 CPU 来处理单一网路队列中收到的网路包的方式帮助提升网路性能

o SplitRx 模式会在 ESXi Host 检测到物理网路卡上单一网路队列符合下列条件时会被 激活：

? 网路卡的使用率负载过重

? 网路卡每秒超过 10000 个广播或多播包时

? SR-IOV 的工作场景如下：

o 针对网路延迟延迟活 CPU 敏感型业务的虚拟机

o 针对需要 Offload I/O 到物理网路卡处理和需要降低网路延迟的业務

? SR-IOV 兼容的功能，当 SR-IOV 功能启用后以下功能将无法使用

? 尽可能使用 vmxnet3 这块虚拟网路卡

? 尽可能充分利用物理网络卡的高性能组件

? 合理的規划虚拟交换机构成，条件许可的情况下分开不同业务到不同的 vSwitch

? 在网路负载较重的情况下尽可能保证足够的物理 CPU 性能