性能之巅：洞悉系统、企业与云计算 - (EPUB全文下载)

文件大小：0.51 mb。
文件格式：epub 格式。
书籍内容：

性能之巅：洞悉系统、企业与云计算
第1章　绪论
第2章　方法
第3章　操作系统
第4章　观测工具
第5章　应用程序
第6章　CPU
第7章　内存
第8章　文件系统
第9章　磁盘
第10章　网络
第11章　云计算
第12章　基准测试
第13章　案例研究
附录A　USE法：Linux
附录B　USE法：Solaris
附录C　sar总结
附录D　DTrace单行命令
附录E　从DTrace到SystemTap
附录F　精选练习题答案
附录G　系统性能名人录
封底
第1章　绪论
性能是一门令人激动的，富于变化同时又充满挑战的学科。本章会引领你进入性能的领域，尤其针对系统性能，阐述涉及的人员、所做的事情、分析的视角和面临的挑战。我将介绍一项非常重要的性能指标——延时，同时还会介绍计算机领域一些的新进展：动态跟踪和云计算。为了帮助读者更好地理解，本章还提供了一些与性能相关的例子。
1.1　系统性能
系统性能是对整个系统的研究，包括了所有的硬件组件和整个软件栈。所有数据路径上和软硬件上所发生的事情都包括在内，因为这些都有可能影响性能。对于分布式系统来说，这意味着多台服务器和多个应用。如果你还没有你的环境的一张示意图，用来显示数据的路径，赶紧找一张或者自己画一张。它可以帮助你理解所有组件的关系，并确保你不会只见树木不见森林。
图1.1 呈现的是单台服务器上的通用系统软件栈，包括操作系统（OS）内核、数据库和应用程序层。术语“全栈”（entire stack）有时一般仅仅指的是应用程序环境，包括数据库、应用程序，以及网站服务器。不过，当论及系统性能时，我们用全栈来表示所有事情，包括系统库和内核。
图1.1　通用系统软件栈
本书第3章“操作系统”，将详细讨论这个软件栈，在后面几章里还会有更深入的研究。本章接下来的部分主要讲述系统性能和性能的概要。
1.2　人员
系统性能是一项需要多类人员参与的事务，其中包括系统管理员、技术支持人员、应用开发者、数据库管理员和网络管理员。对于他们的大多数来说，性能是一项兼职的事情，他们可能会有发掘性能的倾向，但仅限于本职工作范围内（网络团队检查网络、数据库团队检查数据库，如此等等）。然而，对于某些性能问题，要找到根本原因还需要这些团队一起协同工作才行。
一些公司会雇用性能工程师，其主要任务就是维护系统性能。他们与多个团队协同工作，对环境做全局性的研究，执行一些对解决复杂性能问题至关重要的操作。与此同时，他们会开发更好的工具，对整个环境做系统级分析（system-wide analysis），为容量规划（capacity planning）定义指标。
在性能领域也有某些专职于特定应用程序的工种，例如，Java 性能工程师和MySQL 性能工程师。通常他们在开始使用特定的应用程序工具之前，会做一些系统性能检查，但是有限。
1.3　事情
性能领域包括了以下的事情，我按照理想的执行顺序将它们排列如下：
1.设置性能目标和建立性能模型
2.基于软件或硬件原型进行性能特征归纳
3.对开发代码进行性能分析（软件整合之前）
4.执行软件非回归性测试（软件发布前或发布后）
5.针对软件发布版本的基准测试
6.目标环境中的概念验证（Proof-of-concept）测试
7.生产环境部署的配置优化
8.监控生产环境中运行的软件
9.特定问题的性能分析
步骤1～5 是传统软件产品开发过程的一部分。产品发行之后，接下来要么是在客户环境中进行概念验证测试，要么直接进行部署和配置。如果在客户环境中碰到问题（步骤6～9），这说明该问题在软件开发阶段没有得到发现和修复。
理想情况下，在硬件选型和软件开发之前，性能工程师就应该开始工作。作为工作的第一步，可以设定性能目标并建立一个性能模型。产品开发过程常常缺失了这一步，性能工程工作被推迟直到问题出现。在架构决策确定之后，随着软件开发工作的一步步推进，修复性能问题的难度会变得越来越大。
术语容量规划（capacity planning）指的是一系列事前行动。在设计阶段，包括通过研究开发软件的资源占用情况，来得知原有设计在多大程度上能满足目标需求。在部署后，包括监控资源的使用情况，这样问题在出现之前就能被预测。
能够有助于完成上述事情的方法和工具在本书中都有覆盖。
对于不同的公司和不同的产品，环境和要做的事情都各不相同，多数情况下，不需要全部执行以上的九步。你的工作可能集中于某几步或者仅仅是其中的一步。
1.4　视角
与很多事情专注于一点不同，性能是可以从不同的视角来审视的。图1.2 展示了两种性能分析的视角：负载分析（workload analysis）和资源分析（resource analysis），二者从不同的方向对软件栈做分析。
图1.2　分析视角
系统管理员作为系统资源的负责人，通常采用资源分析视角。应用程序开发人员，对最终实现的负载性能负责，通常采用负载分析视角。每一种视角都有自身的优势，第2章将详细讨论这些。尝试从两个视角都进行分析，对于解决某些具有挑战性的问题是不无裨益的。
1.5　性能是充满挑战的
系统性能工程是一个充满挑战的领域，具体原因有很多，其中包括以下事实，系统性能是主观的、复杂的，而且常常是多问题并存的。
1.5.1　性能是主观的
技术学科往往是客观的，太多的业界人士审视问题非黑即白。在进行软件故障查找的时候，判断bug 是否存在或bug 是否修复就是这样。bug 的出现总是伴随着错误信息，错误信息通常容易解读，进而你就明白错误为什么会出现了。
与此不同，性能常常是主观性的。开始着手性能问题的时候，对问题是否存在的判断都有可能是模糊的，在问题被修复的时候也同样，被一个用户认为是“不好”的性能，另一个用户可能认为是“好”的。
考虑下面的信息：
磁盘的平均I/O 响应时间是1ms。
这是“好”还是“坏”？响应时间或者说是延时，虽然作为最好的衡量指标之一，但还是难以用来说明延时的情况。从某种程度上说，一个给定指标是“好”或“坏”取决于应用开发人员和最终用户的性 ............

以上为书籍内容预览，如需阅读全文内容请下载EPUB源文件，祝您阅读愉快。