性能分析、调整方法

 文章内容来自《性能之巅》2.5章节

 昔之善战者，先为不可胜，以待敌之可胜。不可胜在己，可胜在敌。

　　　　　　　　　　　　　　　　　　　　---《孙子兵法之军形篇》

 

1、街灯讹法

　　非深思熟虑的方法。熟悉的观测工具随意看看，有概率去命中一些问题，也可能忽视一些问题。

　　性能调整能够用一种试错的方式反复摸索，对所知道的可调参数进行设置，熟悉各类不一样的值，看看是否有帮助。

　　该方法也能揭示问题，可是当你所熟悉的工具及所作的调整与问题不相关时，进展很缓慢。

　　这个方法用一类观测误差来命名，这类误差叫作街灯效应。出自一篇寓言故事：

　　一天晚上，一个警察看到一个醉汉在路灯下边的地面找东西，问他在找什么。醉汉回答说他钥匙丢了。警察看了看也找不到，就问他：“你肯定你要是是在这儿丢的，就在路灯下？”，醉汉说：“不，可是这儿的光是最亮的”。

　　至关于查看top，不是由于这么作有道理，而是用户不知道怎么样使用其余工具。

　　用这个方法找到的问题多是真的问题，但未必是你想要找的那个。

2、随机变更讹法

　　这是一个实验性质的讹方法。用户随机猜想问题可能存在的位置，而后作改动，直到问题消失。为了判断性能是否已经提高，或者做为每次变更结果的判断，用户会选择一项指标进行研究，诸如应用程序运行时间、延时、操做率（每秒操做数）、或者吞吐量（每秒的字节数）整个方法以下：

　　一、任意选择一个项目作改动（例如一项可变参数）

　　二、朝某个方向作修改

　　三、测量性能

　　四、朝另外一个方向作修改

　　五、测量性能

　　六、步骤3或者步骤5的结果是否是要好于基准值？若是是，保留修改并返回步骤1

　　这个过程可能最终得到的调整仅适用于被测的工做负载，方法很是耗时并且可能作出的调整不能保持长期有效。例如，一个应用程序的改动规避了一个数据库或者操做系统的bug，其结果是能够提高性能，可是当这个bug被修复后，程序这样的改动就再也不有意义，关键是没有人真正了解这件事情。

　　作不了解的改动还有另外一个风险，即在生产负载的高峰期可能会引起更恶劣的问题，所以还需为此准备一套回退方案。

3、责怪他人讹法

　　步骤：
　　一、找到一个不是你负责的系统或环境的组件

　　二、假定问题是与那个组件相关的

　　三、把问题扔给负责那个组件的团队

　　四、若是证实错了，返回步骤1

4、Ad Hoc核对清单法

　　当须要检查和调试系统时，技术支持人员一般会花一点时间一步步的过一遍核对清单。一个典型的场景，在产品环境部署新的服务器或应用时，技术支持人员会花半天时间来检查一遍系统在真实压力下的常见问题。该类核对清单是Ad Hoc的，基于该系统类型的经验和以前所遇到的问题。

　　举个例子，这是核对清单中的一项：

　　运行iostat -x 1检查await列。若是该列在负载下持续超过10ms，那么说明磁盘太慢或者磁盘过载。

　　一份核对清单会包含不少这样的检查项目。

　　这类清单能在最短的时间内提供最大的价值，是及时建议并且须要频繁的更新以保证反应当前状态。这类清单处理的可能是修复方法容易记录的问题，例如设置可调参数，而不是针对源代码或者环境作定制的修复。

　　若是你管理一个技术支持的专业团队，Ad Hoc核对清单能有效保证全部人都知道如何检查最糟糕的问题，能覆盖到全部显而易见的问题。核对清单可以写的清楚并且又规范，说明了如何辨别每个问题和如何作修复。不过固然，这个清单应该时长保持更新。

5、问题陈述法

　　明确问题如何陈述是支持人员开始反映问题时的例行工做，经过询问客户一下几个问题来完成：

　　一、是什么让你认为存在性能问题？

　　二、系统以前运行的好吗？

　　三、最近有什么改动？软件？硬件？负载？

　　四、问题能用延时或者运行时间来表述吗？

　　五、问题影响其余的人和应用程序吗？

　　六、环境是怎么样的？用了那些软件和硬件？是什么版本？是怎样的配置？

　　询问这些问题并获得相应的回答一般会当即指向一个根源和解决方案。所以问题陈述法做为独立的方法收录于此，并且当你应对一个新的问题时，首先应该使用的就是这个方法。

6、科学法

　　科学法研究未知的问题是经过假设和实验。步骤：

　　一、问题

　　二、假设

　　三、预测

　　四、实验

　　五、分析

　　问题就是性能问题的描述。从这点你能够假设性能不佳的缘由有什么。而后你进行试验、能够是观测性的也能够是实验性的，看看基于假设的预测是否正确。最后是分析收集的试验数据。

　　举个例子：你可能发现某个应用程序迁移到一个内存较少的系统时其性能会降低，你假设致使性能很差的缘由是较小的文件系统缓存。你可使用观测的试验方法分别测量两个系统的缓存流失率，预测内存较小的系统缓存流失率会更高。用实验的方法能够增长缓存大小（加内存），预测性能将会有所提高。另外，还能够更简单，实验性的测试能够人为的减小缓存的小大（利用一些可调参数），预计性能会变差。

　　示例（观测性）：

　　一、问题：什么问题致使了数据库查询很慢？

　　二、假设：噪声邻居（其余云计算租户）在执行磁盘I/0，与数据库的磁盘I/O在竞争（经过文件系统）

　　三、预测：若是获得在数据库查询过程当中的文件系统I/O延时，能够看出文件系统对于查询很慢是有责任的

　　四、试验：跟踪文件系统延时，发现文件系统上的等待时间在整个查询延时中的比例小于5%

　　五、分析：文件系统和磁盘对查询速度慢没有责任

　　虽然问题没有解决，可是环境中的一些大型的组件已经被排除了。执行调查的人能够回到第2步作一个新的假设。

　　示例（实验性）：

　　一、问题：为何HTTP请求从主机A到主机C要比从主机B到主机C的时间长

　　二、假设：主机A和主机B在不一样的数据中心

　　三、预测：把主机A移动到主机B同样的数据中心将修复这个问题

　　四、试验：移动主机A并测试性能

　　五、分析：性能获得修复--与假设的一致

　　若是问题没有获得解决，在开始新的假设以前，要恢复以前试验的变更！

7、诊断循环

　　诊断周期与科学方法类似：
　　假设-->仪器校验-->数据-->假设

　　就像科学法同样，这个方法也是经过收集数据来验证假设。这个循环强调数据能够快速的引起新的假设，进而验证改良，以此继续。

　　上述两个方法，理论数据都有很好的平衡。从假设发展到数据的过程很快，那么很差的理论就可尽早的被识别和遗弃，进而开发更好的理论。

8、工具法

　　导向方法以下：

　　一、列出可用到的性能工具（可选的、安装的或可购买的）

　　二、对于每个工具，列出它提供的有用的指标

　　三、对于每个指标，列出阐释该指标可能的规则

　　这个视角的核对清单告诉你那些工具能用、哪些指标能读，以及怎样阐释这些指标。虽然这至关高效，只依赖可用的（或知道的）工具，就能获得一个不彻底的系统视野，可是与街灯讹法相似，用户不知道他的视野不完整--并且可能自始至终对此一无所知。须要定制工具（如动态跟踪）才能发现的问题可能永远被识别并解决。

　　在实践中，工具法确实在必定程度上辨别除了资源的瓶颈、错误，以及其余类型的问题，但一般不过高效。

　　当大量的工具和指标可被选用时，逐个枚举是很耗时的，当多个工具具备相同功能时，状况更糟，你须要花额外的时间来了解各个工具的优缺点，在某些状况下，好比要选择作文件系统微基准的工具的场合，工具至关多，虽然这时候你只须要一个。

9、use方法

　　use方法应用于性能研究，用来识别系统瓶颈一言蔽之就是：

　　对于全部的资源、查看他的使用率、饱和度和错误。

　　术语定义：

　　资源：全部服务器物理器件（CPU、总线~~~）某些软件资源也能算在内，提供有用的指标

　　使用率：在规定的时间间隔内，资源用于服务工做的时间百分比。虽然资源繁忙，可是资源还有能力接受更多的工做，不能接受更多工做的程度被视为饱和度。

　　错误：错误事件的个数

　　某些资源类型，包括内存，使用率指的是资源所用的容量。这与基于时间的定义是不一样的，一旦资源的容量达到100%的使用率，就没法接受更多的工做，资源或者会把工做进行排队（饱和），或者返回错误，用use方法也就予以鉴别。

　　错误须要调查，由于他们会损害性能，若是故障模式是可恢复的，错误可能难以当即察觉。这包括操做失败重试，还有冗余设备池中的设备故障。

　　与工具法相反的是，use方法列举的是系统资源而不是工具，这帮助你获得一张完整的问题列表，在你寻找工具的时候作确认。即使对于有些问题现有的工具没有答案，但这些问题蕴含的知识对于性能分析也是极其有用的：这些是“已知的已知”

　　use方法会将分析引导到必定数量的关键指标上，这样能够尽快的核实全部的系统资源。在此以后，若是尚未找到问题，那么能够考虑采用其余的方法。

　　图描绘了use方法的流程图。错误被置于检查首位，要先于使用率和饱和度。错误一般容易很快被解释，在研究其余指标以前，把它们梳理清楚是省时高效的：

　　

 

　　这个方法辨别出的极可能是系统瓶颈的问题，不过，一个系统可能不止面临一个性能问题，所以你可能一开始就能找到问题，但所找到的问题绝非你关心的那个。在根据须要返回use方法遍历其余资源以前，每一个发现能够用更多的方法进行调查。

　　指标描述：

　　use方法的指标一般以下：

　　使用率：必定时间间隔内的百分比值

　　饱和度：等待队列的长度

　　错误：报告出的错误次数

　　虽然看起来有点违反直觉，但即使总体的使用率在很长一段时间都处于较低水平，一次高使用率的瞬时冲击仍是能致使饱和度与性能问题的。某些监控工具汇报的使用率是超过5分钟的均值，举个例子：每秒CPU使用率可能变更的很是剧烈，所以5分钟的时长的均值可能会掩盖短期内的100%的使用率，甚至是饱和的状况。

　　想一想一些高速公路收费站，使用率就至关于有多少收费站在忙于收费。使用率100%意味着你找不到一个空的收费站，必须排在别人的后边（饱和的状况）若是我说一成天收费站的使用率是40%，你能判断当天是否有车在某一时间排过队吗？极可能在高峰时候确实排过队，那时的使用率是100%，可是在这一天的均值上是看不出的。

　　资源列表：

　　use方法的第一步是要建一张资源列表，要尽量完整。下面是一张服务器一般的资源表，配有相应的例子：

　　cpu：插槽、核、硬件线程（虚拟cpu）

　　内存：dram；

　　网络接口：以太网端口

　　存储设备：磁盘

　　控制器：存储、网络

　　互联：cpu、内存、I/O

　　每一个组件一般做为一类资源类型。例如，内存是一种容量资源，网络接口是一类I/O资源（IOPS或吞吐量）。有些组件体现出多种资源类型：例如，存储设备既是I/O资源也是容量资源，这时须要考虑到全部的类型都能形成性能瓶颈，同时，也要知道I/O资源可能进一步被当作排队系统来研究，将请求排队并被服务。

　　某些物理资源，诸如硬件缓存（如cpu缓存，可能不在清单中。）use方法是处理在高使用率或饱和状态下性能降低的资源最有效的方法，固然还有其余的检测方法。若是你不肯定清单是否该包括一项资源，那就包括它，看看在实际指标中是什么样的状况。

 

　　原理框图

　　另外一种遍历全部资源的方法是找到或者画一张系统的原理框图，正以下图示，这样的图还显示了组件的关系，这对寻找数据流动中的瓶颈是颇有帮助的。

　　CPU、内存、I/O互联和总线经常被忽视。所幸的是，他们不是系统的常见瓶颈，由于这些组件自己就设计有超过吞吐量的余量。可能你须要升级主板，或者减少负载。例如：零拷贝就减轻了内存和总线的负载

　　

　　指标

　　一旦你掌控了资源的列表，就能够考虑这三类指标：使用率、饱和度以及错误。下表种列举了一些资源和指标类型，以及一些可能的指标。

　　这些指标要么是必定时间间隔的均值，要么是累计数目。

　　

 

　　　　　　　　　　　　双CPU系统原理框图示例

　　

　　

　　　　　　　　　　　use方法指标示例

　　重复全部的组合，包括获取每一个指标的步骤，记录下当前没法得到的指标，那些是已知的未知。最终你获得一个大约30项的指标清单，有些指标难以测量，有些根本测不了。所幸的是常见的问题用较简单的指标就能发现（例如：CPU饱和度，内存容量饱和度，网络接口使用率，磁盘使用率），因此这些指标首先要测量

　　一些比较难的组合示例可见下表

　　

 

　　　　　　　　　　　　use方法指标的进阶示例

　　上述的某些指标可能用操做系统的标准工具是没法得到的，可能须要使用动态跟踪或者用到CPU性能计数器。

　　软件资源

　　某些软件资源的检测方法可能类似。这里指的是软件组件，而不是整个应用程序，示例以下：

　　一、互斥锁：锁被持有的时间是使用时间，饱和度指的是有线程排队在等锁

　　二、线程池：线程忙于处理工做的时间是使用时间，饱和度指的是等待线程池服务的请求数目

　　三、进程/线程容量：系统的进程或线程的总数是有上限的，当前的使用数目是使用率，等待分配认为是饱和度，错误是分配失败

　　四、文件描述符容量：同进程/线程容量同样，只不过针对的是文件描述符

　　若是这些指标在你的案例里管用，就用它们；不然，用其余方法也是能够的，如延时分析。

　　使用建议：

　　对于使用上述这些指标类型，这里有一些整体的建议：

　　使用率：100%的使用率一般是瓶颈的信号（检查饱和度并确认其影响）。使用率超过60%可能会是问题。基于如下理由：时间间隔的均值，可能掩盖了100%使用率的短时间爆发，另外，一些资源，诸如硬盘，一般在操做期间是不能被中断的，即便是作优先级较高的工做，随着使用率的上升，排队延时会变的更频繁和明显。

　　饱和度：任何程度的饱和都是问题（非零），饱和度能够用排队长度或者排队所花的时间来度量

　　错误：错误都是值得研究的。尤为是随着错误增长性能会变差的那些错误

　　低使用率、无饱和、无错误：这样的反例研究起来容易。这点要比看起来还有用--缩小研究的范围能帮你快速的将精力集中在出问题的地方，判断其不是某一个资源的问题，这是一个排除法的过程。

　　云计算

　　在云计算环境，软件资源控制在于限制或者给分享系统的多个租户设定阈值。在Joyent的公司，咱们主要用os虚拟技术，来设定内存限制，cpu限制，以及存储I/O的门限制。每一项资源的限定都能用use方法来检验，与检查物理资源的方法相似。

　　举个例子，内存容量使用率是租户的内存使用率与其余内存容量的比值。内存容量饱和出现于匿名的分页活动，虽然传统的页面扫描此时多是空闲的。

10、工做负载特征概括

　　工做负载特征概括是辨别这样一类问题简单而又高效的方法--由施加的负载致使的问题。这个问题关注于系统的输入，而不是所产生的性能。你的系统可能没有任何架构或者配置上的问题，可是系统的负载超出了它所能承受的合理范围。

　　工资负载能够经过回答下列问题来进行特征概括：

　　一、负载是谁产生的？进行ID，用户ID，远端IP地址？

　　二、负载为何会调用？代码路径、堆栈跟踪？

　　三、负载的特征是什么？IOPS、吞吐量、方向类型（读取/写入）？包含变更（标准方差），若是有的话

　　四、负载是怎样随着时间变化的？有平常模式吗？

　　将上述全部的问题都作检查会颇有用，即使你对于答案会是什么已经有了很强的指望，但仍是应作一遍，由于你可能大吃一惊。

　　请思考这么一个场景：你碰到一个数据库性能问题，数据库请求来自一个web服务器池，你是否是应该检查正在使用数据库的IP地址？你本认为这些应该都是web服务器，正如所配置的那样。但你检查后发现好像整个因特网都在往数据库扔负载，以摧毁其性能。你正处于dos攻击中！
　　最好的性能来自消灭没必要要的工做，有时候没必要要的工做室因为应用程序的不正常运行引发的，例如：一个困在循环的线程无故的增长CPU的负担。没必要要的工做也有可能源于错误的配置--举个例子，在白天运行全系统的备份--或者是以前说过的dos攻击。概括工做负载的特征能识别这类问题，经过维护和从新配置能够解决这些问题。

　　若是被识别出的问题没法解决，那么能够用系统资源控制来限制它。举个例子，一个系统备份的任务压缩备份数据会消耗CPU资源，这会影响数据库，并且还要用网络资源来传输数据。用资源控制来限定备份任务对CPU和网络的使用（若是系统支持的话）这样虽然备份仍是会发生，但不影响数据库

　　除了识别问题，工做负载特征概括还能够做为输入用于仿真基准设计。若是度量工做负载只是用的均值，理想状况，你还要收集分布和变化的细节信息。这对于仿真工做负载的多样性，而不是仅测试均值负载是很重要的。

　　工做负载分析经过辨识出负载问题，有利于将负载问题和架构问题区分开。

　　执行工做负载特征概括所用的工具和指标视目标而定。一部分应用程序所记录的详细的客户活动信息能够成为统计分析的数据来源。这些程序还能够提供每日或每个月的用户试用报告，这也是值得关注的。

11、向下挖掘分析法

　　深度分析开始于在高级别检查问题，而后依据以前的发现缩小关注的范围，忽视那些无关的部分，更深刻发掘那些相关的部分。整个过程会探究到软件栈较深的级别，若是须要，甚至能够达到硬件层，以求找到问题的根源。

　　在《Solaris性能与工具》一书中，针对系统性能，深度分析方法分为如下三个阶段：

　　一、检测：用于持续记录高层级的统计数据，若是问题出现，予以辨别和报警

　　二、识别：对于给定问题，缩小研究的范围，找到可能的瓶颈

　　三、分析：对特定的系统作进一步的检查，找到问题根源并量化问题

　　检测是在公司范围内执行，全部服务器和云数据都会聚合在一块儿。传统的方法是使用SNMP，监控支持该协议的网络设备。数据能够揭示长期的变化特色，这些是没法由短期内运行的命令行工具得到的。若是发现怀疑的问题，多数的检测方案会报警，此时及时分析进入下一阶段。

　　问题的识别在服务器上是交互执行的，用标准的检测工具来检查系统的组件：CPU、磁盘、内存等等。一般是用vmstat、iostat、mpstat这样的工具起一个命令行会话来完成的。还有一些较新的工具经过GUI支持的实时性能分析。

　　有些分析工具还具有tracing或者profiling的功能，用以对可疑区域作更深层次的检查。作这类深层的分析可能须要定制工具乃至检查源代码。大量研究的努力就花在这里，俺须要对软件栈的层次作分离来找出问题的根本缘由。执行这类任务的工具包括stace、truss、pref、Dtrace

　　五个why

　　在分析阶段，你还有一个能用的方法，叫作“五个why”技巧：问本身why？而后做答：

　　一、查询多了数据库性能就开始变差。why？

　　二、因为内存换页磁盘I/O延时。why？

　　三、数据库内存用量变得太大了。why？

　　四、分配器消耗的内存比应该用的多。why？

　　五、分配器存在内存碎片的问题。why？

　　这是一个真实的例子，但出人意料的是要修复的是系统的内存分配库。是持续的质问和对问题实质的深刻研究使得问题得以解决。

12、延时分析

　　延时分析检查完成一项操做所用的时间，而后把时间再分红小的时间段，接着对有着最大的延时的分析时间段作再次的划分，最后定位并量化问题的根本缘由。与深度分析相同，延时分析也会深刻研究到软件栈的各层来找到延时问题的缘由。

　　分析能够从所施加的工做负载开始，检查工做负载是如何在应用程序中处理的，而后深刻到操做系统的库、系统调用、内核以及设备驱动。

　　举个例子、Mysql的请求延时分析可能涉及到如下问题的回答：

　　一、存在请求延时的问题吗？（是的）

　　二、请求时间大量花费在CPU上？（不在CPU上）

　　三、不花在CPU上的时间在等待什么？（文件系统I/O）

　　四、文件系统的I/O时间是花在磁盘I/O上仍是锁竞争上？（磁盘I/O）

　　五、磁盘I/O主要是随机寻址的时间仍是数据传输的时间？（数据传输的时间）

　　对于这个问题，每一步所提出的问题都讲延时划分红了两个部分，而后继续分析那个较大可能的部分：延时的二分搜索法，你能够这么理解，下图

　　一旦是被出A和B中较慢的那个，就能够对其作下一步的分析和划分，依此类推。

　　数据库查询的延时分析是R方法的目的。

　　

 

　　　　　　　　　　　　延时分析过程

十3、R方法

　　R方法是针对Oracle数据库开发的性能分析方法，意在找到延时的根源，基于Oracle的traceevents。它被描述成“基于时间响应性能提高方法，能够获得对业务的最大经济收益”，着重于识别和量化查询过程当中所消耗的时间，虽然它是用于数据库研究领域，可是方法思想能够应用于全部系统，做为一种可能的研究手段，值得在此说起，

十4、事件跟踪

　　系统的操做就是处理离散的事件，包括CPU指令、磁盘I/O，以及磁盘令、网络包、系统调用、函数库调用、应用程序事件、数据库查询等等。性能分析一般会研究这些事件的汇总数据，诸如每秒操做数，每秒的字节数、或者延时的均值。有时一些重要的细节信息不会出现这些汇总之中，所以最好的研究事件的方法是逐个检查。

　　网络排错经常须要逐包检查，用的工具备tcpdump，下边这个例子将个个网络包概括汇总成了一行行文字。

　　

　　

　　tcpdump按照须要能够输出各种信息

　　存储设备I/O在块设备层能够用iosnoop来跟踪

 　　

 

　　这里打印出了一些时间戳，包括起始时间，终止时间，请求和完成之间的时间，以及服务这此次I/O的估计时间。

　　系统调用层是另外一个跟踪的经常使用层，工具备Linux的strace和基于Solaris系统的truss。这些工具也有打印时间戳的选项。

　　当执行事件跟踪时，须要找到如下信息：

　　一、输入：事件请求的全部属性，即类型、方向、尺寸等等

　　二、时间：起始时间、终止时间、延时

　　三、结果：错误状态、事件结果

　　有时性能问题能够经过检查时间的属性来发现，不管是请求仍是结果。事件的时间戳有利于延时分析，通常跟踪工具都会包含这个功能。上述的tcpdump用参数-ttt，输出所包含的DELTA时间，就测量了包与包之间的时间。

　　研究以前发生的事件也能提供信息。一个延时特别差的事件，一般叫作延时离群值，多是由于以前的事件而不是自身所形成的。例如，队列尾部时间的延时可能会很高，但这是由以前队列里的事件形成的，而并不是该时间自己。这种状况只能用事件跟踪来加以辨别。

十5、基础栈统计

　　把当前的性能指标与以前的数值作比较，对分析问题经常有启发做用。负载和资源使用的变化是可见的，能够把问题回溯到他们刚发生的时候。某些观测工具（基于内核计算器）能显示启动以来的信息统计，能够用来与当前的活动作比较。虽然这比较粗糙，但总好过没有。另外的方法就是作基础栈统计。

　　基础栈统计包括大范围的系统观测并将数据进行保存以备未来参考。与启动以来的信息统计不一样，后者会隐藏变化，基础栈囊括了每秒的统计，所以变化是可见的。

　　在系统或应用程序变化的以前和以后都能作基础栈统计，进而分析性能变化。能够不按期的执行基础栈统计并把它做为站点记录的一部分，让管理员有一个参照。了解“正常”是什么样的。如果做为性能检测的一部分，能够天天都按固定的间隔执行这类任务。

十6、静态性能调整

　　静态性能调整处理的是架构配置的问题。其余的方法着重的是负载施加后的性能：动态性能。静态性能分析是在系统空闲没有施加负载的时候执行的。

　　作性能分析和调整，要对系统的全部组件确认如下问题：

　　一、该组件是须要的嘛？

　　二、配置是针对预期的工做负载设定的嘛？

　　三、组件的自动配置对于预期的工做负载时最优的嘛？

　　四、有组件出现错误吗？是在降级状态吗？

　　下面是一些在静态性能调整中可能发现的问题：

　　一、网络接口协商：选择100Mb/s而不是1Gb/s

　　二、创建RAID池失败

　　三、使用的操做系统、应用程序或固件是旧的版本。

　　四、文件系统记录的尺寸和工做负载I/O的尺寸不一致

　　五、服务器意外配置了路由

　　六、服务器使用的资源，诸如认证，来自远端的数据中心，而不是本地的。

　　幸运的是，这些问题都很容易检查。可贵是要记住作这些事情。

十7、缓存调优

　　从应用程序到磁盘，应用程序和操做系统都会部署多层的缓存来提升I/O性能。这里介绍各级缓存的调优策略：

　　一、缓存的大小尽可能和栈的高度同样。靠近工做执行的地方，减小命中缓存的资源开销。

　　二、确认缓存开启并确实在工做。

　　三、确认缓存的命中/失效比例和失效率

　　四、若是缓存的大小是动态的，确认它的当前尺寸。

　　五、针对工做负载调整缓存。这项工做依赖缓存的可调参数。

　　六、针对缓存调整工做负载。这项工做包括减小对缓存没必要要的消耗，这样能够释放更多空间来给目标负载使用。

　　要当心二次缓存--好比，消耗内存的两块不一样的缓存块，把相同的数据缓存了两次。

　　还有，要考虑到每一层的缓存调优的总体性能收益。调整CPU的L1缓存能够节省纳秒级别的时间，当缓存失效时，用的是L2。提高CPU的L3缓存能避免访问速度慢的多的主存，从而得到较大的性能收益。

十8、微基准测试

　　微基准测试测量的是施加的简单的人造工做负载的 性能。微基准测试能够用于执行科学方法，将假设和预测放到测试中验证，或者做为容量规划的一部分来执行。

　　这与业界的基准定标是不一样的，工业的基准定标是针对真实世界和天然的工做负载。这样的基准定标执行时须要工做负载仿真，执行和理解的复杂度高。

　　微基准测试因为涉及的因素较少，因此执行和理解会较为简单，能够用微基准测试工具来施加工做负载并度量性能。或者用负载生成器来产生负载，用标准的系统工具来测量性能。两种方法均可以，可是稳妥的方法时使用微基准测试工具并用标准系统工具再次确认性能数据。

　　下边是一些微基准测试的例子，包括一些二维测试：

　　一、系统调用：针对fork（），exec（），open（），read（），close（）；

　　二、文件系统读取：从缓存过的文件读取，读取数据大小从1B变化到1MB；

　　三、网络吞吐量：针对不一样的socket缓冲区的尺寸测试TCP端对端数据传输。

　　微基准测试一般在目标系统上的执行会尽量快，测量完成大量上述的这类操做所要的时间，而后计算均值（平均时间=运行时间/操做次数）