分布式服务架构-第三章 服务化系统容量评估和性能保障

1.架构设计与非功能质量

架构设计：需求分析和整理，概要设计和详细设计

• 需求分析和整理：梳理用例和场景，抽象出系统面向的用户和角色，梳理对于每个用户和角色应该提供的功能需求、非功能质量需求和限制。
  • 非功能质量需求：高可用性，高性能，可伸缩，可扩展，安全性，稳定性，健壮性，可测试性等
  • 对功能性需求和非功能性需求进行整理，识别核心需求和特色需求。最后以核心需求和特色需求为根本展开架构设计。
• 概要设计：根据需求分析和整理阶段产出的核心需求和特色需求，对整个系统进行模块划分，并定义良好的模块之间的关系和交互。
• 详细设计：使用多视图方法来描述系统的架构
  • 多视图包括：数据视图，逻辑视图，开发视图，进程视图，物理视图，性能视图，安全视图等。
• ATAM:互联网架构权衡分析方法

2.全面的非功能质量需求

业务划分：水平拆分，垂直拆分

2.1非功能质量需求的概述

主要体现在：高性能，高可用，可伸缩，可扩展，安全性等方面

非功能质量指标：可测试性，可监控性

• 核心非功能质量指标
  • 高性能：运行效率高，性价比高----单节点服务吞吐量和响应时间
  • 高可用：持续高可用，缩短宕机时间，出错恢复，可靠性—以全年时间减去当年的宕机时间，得到的差值除以全年时间计算得出
  • 可伸缩性：垂直伸缩，水平伸缩----横向扩展能力，随节点增加，服务能力能够随着节点增加线性增加，如不能，用百分比衡量
  • 可扩展性：可插拔，组件重用—架构上的灵活性即可插拔性，将来可以不断在系统上叠加新业务和新功能。
  • 安全性：数据安全、加密、熔断、防攻击–系统的安全保护措施，防止攻击和数据泄露等。
• 其他非功能质量指标
  • 可监控性：快速发现，定位和解决
  • 可测试性：可灰度，可预览，可Mock，可拆解
  • 鲁棒性：容错性，可恢复性
  • 可维护性：易于维护，监控、运营和扩展
  • 可重用性：可移植性、解耦
  • 易用性：可操作性

2.2非功能质量需求的具体指标

应用服务器、数据库、缓存、消息队列

2.2.1应用服务器

服务的入口，请求流量从这里进入系统，数据库，缓存和消息队列的访问流量取决于应用服务器的访问量。

对应用服务器的访问量进行评估至关重要，应用服务器主要关注每秒请求的峰值及对请求的响应时间等指标，通过这些指标可以评估我们的引用服务器资源数量。

• 部署结构
  • 负载均衡策略
  • 高可用策略
  • I/O模型（NIO/BIO）
  • 线程池模型
  • 线程池中的线程数量
  • 是否多业务混合部署
• 容量和性能
  • 每天的请求量
  • 各接口的访问峰值
  • 平均的请求响应时间
  • 最大请求响应时间
  • 在线的用户量
  • 请求的大小
  • 网卡的I/O流量
  • 磁盘的I/O负载
  • 内存的使用情况
  • CPU使用情况
• 其他指标
  • 请求内容是否包含大对象
  • GC收集器的选型和配置

2.2.2数据库

根据应用层的访问量和访问峰值，计算出需要的数据库资源的吞吐量。。

• 部署结构：
  • 复制模型
  • 失效转移策略
  • 容灾策略
  • 归档策略
  • 读写分离策略
  • 分库分表（分片）策略
  • 静态数据和半静态数据是否使用缓存
  • 有没有考虑缓存穿透并压垮数据库的情况
  • 缓存失效和缓存数据预热策略
• 容量和性能:
  • 当前的数据容量
  • 每天数据增量
  • 每秒的读峰值
  • 每秒的写峰值
  • 每秒的事务量峰值
• 其他指标：
  • 查询是否走索引
  • 有没有大数据量的查询和范围查询
  • 有没有多表关联，关联是否用到索引
  • 有没有使用到悲观锁，是否可以改造成乐观锁，是否可以利用数据库内置行级锁
  • 事务和一致性级别
  • 使用的jdbc数据源类型及连接数等配置
  • 是否开启jdbc诊断日志
  • 有没有存储过程
  • 伸缩策略（分区表，自然时间分表，水平分库分表）
  • 水平分库分表实现方法（客户端，代理，Nosql）

2.2.3缓存

根据应用层的访问量和访问峰值，通过评估热数据占比，计算缓存资源的大小并估算缓存资源的峰值

• 部署结构
  • 复制模型
  • 失效转移
  • 持久策略
  • 淘汰策略
  • 线程模型
  • 预热方法
  • 哈希分片策略
• 容量与性能
  • 缓存内容大小
  • 缓存内容数量
  • 缓存内容过期时间
  • 缓存的数据结构
  • 每秒的读峰值
  • 每秒的写峰值
• 其他指标
  • 冷热数据比例
  • 是否有可能发生缓存穿透
  • 是否有大对象
  • 是否使用缓存实现分布式锁
  • 是否使用缓存支持的脚本
  • 是否避免了race condition
  • 缓存分片方法（客户端，代理，集群）

2.2.4消息队列

根据应用层的平均访问量和访问峰值，计算需要消息队列传递的数据量，计算出所需要的消息队列资源的数量，部署结构，高可用方案等

• 部署结构
  • 复制模型
  • 失效转移
  • 持久策略
• 容量和性能
  • 每天平均的数据增量
  • 消息持久的过期时间
  • 每秒的读峰值
  • 每秒的写峰值
  • 每条消息的大小
  • 平均延迟
  • 最大延迟
• 其他指标
  • 消费者线程池模型
  • 哈希分片策略
  • 消息的可靠投递
  • 消费者的处理流程和持久机制

3.典型的技术评审提纲

大量需求中识别出核心需求和特色需求，针对核心需求和特色需求设计系统，使用其他需求验证系统。

3.1现状

• 业务背景：项目名称、业务描述
• 技术背景：架构描述、当前系统容量（系统调用量的平均值，请求响应时间的平均值等）、当前系统调用量的峰值、最小和最大的请求响应时间

3.2需求

• 业务需求:要改造的内容、要实现的新需求
• 性能需求：
  • 预估系统容量（预估系统调用量的平均值，预估请求响应时间的平均值）
  • 预估系统调用量的峰值，最小和最大的请求响应时间
  • 其他非功能质量，例如：安全性，可伸缩性等

3.3方案描述

• 概述：一句话概括方案亮点，如双写、迁移、主从分离、分库分表、扩容、归档、接口改造等
• 详细说明：对方案的具体描述，可以加图，如果是改造方案，最好突出变动地方，描述角度
  • 中间件架构（应该服务器，数据库，缓存，消息队列等）
  • 逻辑架构（模块划分，模块通信，信息流，时序等）
  • 数据架构（数据结构，数据分布，拆分策略，缓存策略，读写分离策略，查询策略，数据一致性策略）
  • 异常处理，容灾策略，灰度发布，上线方案，回滚方案等
• 性能评估
  • 给出方案的基准数据，并按性能需求评估需要使用的资源数量
  • 单机并发量
  • 单机容量
  • 单机吞吐量的峰值
  • 按照预估的性能需求，预估资源数据（应用服务器，缓存，存储，队列等），伸缩方式和功能
• 方案优缺点
  • 要有具体的确定性，量化有明确的目标和结果

3.4方案对比

对比可选方案，选择倾向的方案，并给出选择这种方案的理由

3.5风险评估

标识所选方案的风险，提出此风险发生时的应对策略，例如上线失败时的回滚策略

3.6工作量评估

根据所选方案时做的具体工作，并评估开发，测试等细化任务需要的时间，形成可实施的任务计划表，计划表一般从项目计划和人员分配两个角度来管理项目。

4.性能和容量评估经典案例

4.1背景

物流系统包含两个质量优先需求

• 维护用户常用地址，在下单时提供其地址列表
• 下单时异步产生物流订单，物流系统后台通过第三方物流轮询拉取物流状态，已下单用户查询订单的物流订单和物流记录

两个需求模块需要分库分表，并且借用消息队列和缓存抗住读和写的流量，本方案主要针对这两个业务的容量和性能进行评估。

4.2目标数据量级

• 用户量达2亿，平均每天增长5万个
• 平均每天订单量400万个，下单时间段集中在9：00-23:00；促销时日订单量为1400万个，50%下单时段集中在19:30-20:30 和 22:00-23:00

4.3量级评估标准

4.3.1通用标准

• 容量：按照峰值的5倍进行冗余计算
• 用户的常用地址容量：按照30年计算
• 数据物流订单的容量：时效性较强，按照3年计算
• 第三方物流查询接口：吞吐量为5000/s

4.3.2mysql

• 单端口读：1000/s
• 单端口写：700/s
• 单表容量：5000万条

4.3.3redis

• 单端口读：40000/s
• 单端口写：40000/s
• 单端口内存容量：32GB

4.3.4kafka

• 单机读：30000/s
• 单机写：5000/s

4.3.5应用服务器

• 请求量峰值：5000/s

4.4方案

方案1：最大性能方案

需求1：用户常用地址

1）整体流程

• 提供RESTful服务来增加用户的常用地址
• 提供RESTful服务来获取用户的常用地址列表

2）数据库资源评估

• 读操作吞吐量：
  • 用户每次下单拉取一次用户地址列表，日订单量1400万且50%下单时段集中在两小时内计算：
  • （1400万 x 0.5）/(2 x 60 x 60) =1000/s
  • 容量按照5倍冗余计算，读操作吞吐量峰值为1000/s x 5 = 5000/s 需要5端口数据库服务读
• 写操作吞吐量：
  • 每天新增的用户全部增加一次常用地址，并在高峰期有20%的用户在下单时会增加一条常用地址
  • （1400万 x 0.2 + 5万）/（2 x 60 x 60）= 400/s
  • 容量按5倍冗余计算：400/s x 5 = 2000/s 需要3端口数据库服务写
• 数据容量：
  • 两亿用户，每天增长5万用户，平均每个用户5个常用地址，30年后用户常用地址表数量
  • （2亿 + 5 万 x 365 x 30年）x 5 = 35亿
  • 容量按照5倍冗余：35亿 x 5 = 175亿 需要350张表即可容纳

根据以上，

• 如果读写混合部署，需要8个端口，可以使用8主8从
• 读写分离，做主从部署，3主6从，与两倍数对齐，使用4主8从即可
• 表容量，需要350张表和2的指数对齐，512张表主库端口为4，考虑将来扩展时不用拆分数据库，尽量设计更多的库

即：设计结果：4端口 x 32 库 x 4表， 4主8从

3）缓存资源评估

使用redis缓存活跃用户的常用地址。

• 定义当天下单的用户为活跃用户，活跃用户的地址缓存24小时，假定每天下单的用户均为不同的用户，每个用户5个常用地址，每个地址大小为1KB
• 缓存大小为：1400万 x 5 x 1kb = 70GB
• 容量按5倍冗余计算：70GB x 5 = 350GB
• 没太redis32GB内存，需要11台机器，满足5000/s读操作吞吐量和2000/s的写操作吞吐量

设计结果：11台，主从

4）应用服务器资源评估

根据数据库的读操作吞吐量（5000/s）峰值和写操作吞吐量（2000/s）峰值计算，选择单台应用服务器即可，选择两台可避免单点、

设计结果：2台

需求2：物流订单和物流记录

1）整体流程

• 订单提交后，通过消息队列产生物流订单，物流订单消息稍后传入物流系统，物流系统消费物流订单消息然后入库
• 后台任务轮询未完成的物流订单，查询第三方物流接口状态，填写物流记录信息。每天产生1400万订单，订单平均3天到货，第三方查询接口提供5000/s吞吐量，每次进行状态查询需要的时间计算如下：1400万x3天/5000=2小时，将任务定位两小时查一次
• 提供RESTful服务获取物流订单信息
• 提供RESTful服务获取物流记录信息

2）数据库资源评估

• 读操作吞吐量：用户下单三天到货，三天内50%用户每天查询一次物流订单和一次物流记录
  • （1400万 x 3 x 0.5）/（24 x 60 x 60）=250/s
  • 容量按5倍冗余计算：2 x 250/s x 5 = 2500/s,， 即需要3端口数据库服务读操作
• 写操作吞吐量：
  • 用户每次下单产生一次物流订单，按促销日订单量1400万，且50%下单时段集中在两小时内计算
  • （1400万 x 0.5）/(2 x 60 x 60) = 1000/s
  • 每天1400万个订单，每个订单平均3天到货，每条物流订单产生8条物流记录，并且8条在3天内均匀产生，
  • 1400 万 x 3 x 8/3/(24 x 60 x 60)=1200/s
  • 5倍容量：（1000/s + 1200/s）x 5=11000/s 需16端口数据库服务写
• 数据容量：
  • 两亿物流订单积累，每天增加400万订单，则3年订单量
  • 2亿 + 400万 x 365天 x 3年 = 46亿
  • 5倍冗余计算：46亿 x 5 = 230亿
  • 需要460张表容纳，物流记录表是物流订单的8倍，为460 x 8 = 3680张表。

综上，

• 读写混合部署：19端口 以及19主19备
• 读写分离：16主16从
• 3680张表，和2的指数对齐选择4096张表，32库

设计结果：16端口 x 32库 x 8 表， 16主16从

3）消息队列资源评估

考虑5倍冗余后峰值为5000/s，通过单台kafka和单台处理机即可处理，考虑到单点，至少使用两台kafka

峰值突增，增加kafka集群的节点来抗住写流量，处理机根据后端入库性能来决定。

设计结果：两台kafka， 两台处理机

4）应用服务器资源评估

根据数据库读操作吞吐量（2500/s）峰值和写操作吞吐量（11000/s）峰值计算，使用3台应用服务器即可

用于查询第三方接口的后台任务服务器，由于受到第三方接口5000/s吞吐量的限制，使用单台机器即可，为了避免单点使用两台处理机即可。

设计结果：2台

方案2：最小资源方案

方案：

（1）用户常用地址

设计结果：1端口 x 128库 x 4表， 1主1从

（2）物流订单和物流记录

设计结果：1端口 x 512库 x 8表， 1主1从

4.5小结

倾向于采用最小资源方案

• 当前线上流量并不大，使用最小资源方案可节约成本
• 最小资源方案充分考虑了数据库分库分表，当读操作和写操作突增时，DBA可以拆分库到不同的端口，即增加端口来应对
• 最小资源方案在应用层设计了开关，如果性能突增，则可以临时申请和开启缓存，消息队列

5.性能评估参考标准

5.1常用的应用层性能指标参考标准

5.1.1通用标准

• 容量按照峰值的5倍冗余计算
• 分库分表后的容量一般可存储30年的数据
• 第三方查询接口吞吐量为5000/s
• 单条数据库记录占用大约1KB的空间

5.1.2MySQL

• 单端口读：1000/s
• 单端口写：700/s
• 单表容量：5000万条

5.1.3Redis

• 单端口读：40000/s
• 单端口写：40000/s
• 单端口内存容量：32G

5.1.4Kafka

• 单机读：30000/s
• 单机写：5000/s

5.1.5DB2

• 单机读峰值：20000/s
• 单机写峰值：20000/s
• 单表容量：1亿条数据

5.2常用的系统层性能指标参考标准

5.2.1寄存器和内存

• 寄存器、L2、L3、内存、分支预测失败、互斥量加锁和解锁等耗时为纳秒级别
• 内存随机读取可达30万次/s,顺序读取可达500万次/s
• 内存每秒可以读取GB级别的数据
• 读取内存中1MB的数据为250ns, 为亚毫秒级

5.2.2硬盘I/o

• 普通SATA机械硬盘IOPS能达到120次/s
• 普通SATA机械硬盘顺序读取数据可达100MB/s
• 普通SATA机械硬盘随机读取数据可达2MB/s
• 普通SATA机械硬盘旋转半圈3ms
• 普通SATA机械硬盘寻道需要3ms
• 普通SATA机械硬盘已经寻道后，开始读取数据，读取一次数据真正耗时2ms
• FusionIo卡（一种高的SSD硬盘套件）可达到百万级别的IOPS
• 高端机器配上高端存储设备，可以达到每秒GB级别的数据读取，相当于普通内存的读取速度
• 固态硬盘访问延迟，0.1~0.2ms， 为亚毫秒级别，和内存速度差不多

5.2.3网络I/O

• 常见的千兆网卡传输速度1000Mbit/s,128Mbit/s
• 千兆网卡读取1MB数据，10ms

5.2.4数据库

• 读写数据库的一条记录毫秒级别，短则几毫秒，多则几百毫秒，大于500ms认为超时
• Mysql在4核心，256GB内存的CPU中性价比最好，继续垂直扩展时由于体系限制，成本开始增加，提升性能开始减少，性价比开始降低。

5.2.5IDC

• 同一机房网络来回：0.5ms
• 异地机房来回：30-100ms
• 同一机房RPC服务调用为几个毫秒，有的为几十毫秒或几百毫秒，一般500ms以上为超时

5.2.6网站

• 网页加载为秒级别
• UV：每日一共有多少用户来访，用cookie session跟踪
• 独立ip访问，每日有多少独立ip来访，同一个局域网可看到同一个ip
• PV：每日单独用户的所有页面访问量，如果uv为50000000， 那么每秒的平均在线人数50000000/24/60/60=578人，
• 某社交媒体平台每秒写入量上万，每秒请求量上百万，每天登陆用户上亿，每天产生的数据量上千亿

5.2.7组合计算和估算

• 普通SATA机器硬盘一次随机读取时间：3ms（磁盘旋转） + 3ms（寻道）+2ms（存取数据延迟）=8ms
• 普通SATA机器硬盘每秒随机读取：1000ms/8ms=125次IOPS
• IOPS代表磁盘每秒可随机寻址多少次，随机读取速度取决于数据是如何存放的，如果数据按照块存放，每块4KB，每次读取10块，那么随机读取速度为：10x4kbx125次/s=5MB/s
• 一次读取内存时间：1000ms/30万次/s=3ns
• CPU速度=10倍 x 内存速度= 100倍xI/O速度
• 顺序读取普通SATA机械硬盘1MB 的数据：20ms
• 2的十次方=1KB ， 2的20次方= 1MB， 2的30次方=1GB， 2的32次方=4GB

6.性能测试方案的设计和最佳实践

6.1明确压测目标

• 响应时间：指的是一个请求处理从发送请求到接收响应的总体时间
• 吞吐量：指的是单位时间内系统可以处理的请求数据量
• 单线程处理：吞吐量=1s/响应时间 ---- 即系统每秒处理请求的个数
• 多核：吞吐量=(1s/响应时间) x并发数
• 对于web应用，还关注同时在线的用户数，最大并发的用户数等

eg：典型的交易系统

交易系统：下单，下单查询，退款和退款查询4个接口

• 交易系统对外能输出每秒300次交易
• 平均响应时间为1s，最大响应时间3s
• 可伸缩性能力达到80%以上
• 连续24小时运行

6.2压测场景设计和压测方案制定

6.2.1业务模型分析

按历史数据来确定各个接口的比例，依次为60%，37%，1%，2%

6.2.2确定测试类型

• 基准测试：对单线程下单接口的测试，主要用于调试测试脚本正确性及查看每个接口在无压力情况下对每个请求响应时间，一般几分钟完成
• 容量测试：检查系统能处理的最大业务量，采用梯度加压的方式不断增加并发用户量，监控响应时间和系统资源的变化情况，响应时间曲线出现拐点时的业务量就是系统能处理的最大业务量，几十分钟完成
• 负载测试：测试单个接口在不产生任何错误情况下能提供的最佳的系统性能，从而得出单个接口在响应时间满足用户需求时的最大吞吐量和并发数，压力测试目的检查系统能够支持的最大的用户并发量，在测试过程中采用梯度加压方法增加并发数，一般几十分钟完成
• 混合业务测试：按照业务流程要求对接口调用按比例进行编排，采用一定的测试加压方式进行加压，获取系统对业务流程的最大处理能力，及每个接口单独的处理能力，一般几十分钟完成
• 稳定性测试：按照混合测试的业务流程对系统施加合理的压力，持续执行一定的时间。针对运行情况，判断系统健壮性，是否存在内存泄露，是否存在较多的上下文切换，经过稳定性测试，可以发现系统程序内隐藏的具有时间累积效应性质的bug 一般12-24小时完成。
• 异常测试：指依赖服务中断，网络中断，硬件故障等异常情况下，系统对业务的影响情况。

6.2.3确定加压方式

• 瞬间加压：通过测试工具模拟大量的并发请求，同时将全量负载加压到目标系统的接口，主要考验系统对突发流量的处理能力，考验系统是否设计了削峰功能和对瞬间大量负载的熔断，限流，隔离，失效转移，降级功能，主要应用于类似秒杀、抢购、抢红包等场景中。
• 逐渐加压：模拟通用的线上系统的压力，线上系统的压力在一定周期内大体为抛物线的趋势。
• 梯度加压：目的为通过逐渐增加用户并发量，观察系统的输出能力，找到最佳或者最大的系统负载，具体指响应时间满足业务要求的情况下达到的最优或者最大的吞吐量和并发数

6.2.4确定延时方式

在客户端机器发送大量请求到目标系统，

• 一个请求发送完毕立即发送下一个请求
• 一个请求发送完毕间隔固定时间发送下一个请求
• 以一定时间间隔均衡地发送请求

6.2.5压测方案和压测场景

通过基准测试找到没有负载下各接口响应时间，，这里的响应时间将作为梯度加压的基础数据。

得到基准测试响应时间后，使用梯度加压，吞吐量梯度测试：100/s,200/s,300/s

6.3准备压测环境

6.3.1压测环境的软硬件

与线上环境相同，尽量保持相近或相似

6.3.2压测脚本

推荐一个测试脚本包含一个单独业务流程，便于统计性能结果以及在以后重用

6.3.3数据准备

6.3.4压测的执行

根据指定压测方案，执行各个压测场景测试用例，并通过观察和监控系统资源，数据库，缓存和消息队列的使用情况，判断系统是否满足既定目标。

• 系统资源占用情况
  • 系统层面指标：cpu，内存，磁盘io，网络带宽，线程数，线程切换。。。
  • 接口吞吐量，响应时间，超时情况等
  • 数据库慢sql，sql行读，死锁等
  • 缓存读写吞吐量，缓存使用增加数量
  • 消息队列吞吐量等
• 压测报告内容
  • 记录的压测数据
  • 分析是否满足压测目标
  • 指出系统存在的瓶颈点
  • 潜在风险
  • 改进意见

6.3.5问题修复和系统优化

发布压测报告，瓶颈点和风险进行整改并优化系统，修复后提交新版本，请求压测团队进行回归测试

7.有用的压测工具

7.1 ab

一款针对HTTP实现的服务进行性能压测的工具

只能测试简单的 RESTful 风格的接口，无法进行多个业务逻辑的串联测试

7.2 jmeter

基于Java的性能压力测试工具，用于对Java开发的软件做压力测试

7.3mysqlslap

mysql自带的一款性能压测工具，通过模拟多个并发客户端访问mysql来执行压力测试，同时提供详细的数据性能报告。

• 单线程测试

  mysqlslap -a -uroot -pyouarebest
  

• 100个线程测试

mysqlslap -a -c 100 -uroot -pyouarebest

• 多次测试对测试结果求平均值

mysqlslap -a -i 10 -uroot -pyouarebest

• 测试读性能指标

mysqlslap -a -c10 --number-of-queries=1000 --auto-generate-sql-load-type=read -uroot -pyouarebest

• 测试写性能指标

mysqlslap -a -c10 --number-of-queries=1000 --auto-generate-sql-load-type=write -uroot -pyouarebest

• 测试读写混合性能指标

mysqlslap -a -c10 --number-of-queries=1000 --auto-generate-sql-load-type=mixed -uroot -pyouarebest

• 多次不同并发数混合的性能指标

mysqlslap -a --concurrency=50,100 --number-of-queries 1000 --debug-info --engine=myisam,innodb --iterations=5 -uroot -pyouarebest

7.4sysbench

• cpu 性能测试

sysbench --test=cpu --cpu-max-prime=20000 run

• 线程锁性能测试

sysbench --test=threads --num-threads=64 --thread-yields=100 --thread-locks=2 run

• 磁盘随机I/o性能测试:用sysbench工具可以测试顺序读，顺序写，随机读，随机写等磁盘I/O性能

• 内存性能测试

sysbench --test=memory --num-threads=512 --memory-block-size=256M --memory-total-size=32G run

• MYSQL事务性操作测试:在准备阶段不能自动创建数据库，需要手工预先创建测试时需要使用的数据库，并使用–mysql-db=test来指定测试数据库

sysbench --test=oltp --mysql-table-engine=myisam --oltp-table-size=1000 --mysql-user=root --mysql-host=localhost --mysql-password=youarebest --mysql-db=test run

7.5dd

可以用于测试磁盘顺序I/O的存取速度

dd if=/home/robert/test-file of=/dev/null bs=512 count=10240000

7.6LoadRunner

模拟成千上万的用户同时对目标系统实施高并发负载，并实时检测系统资源的使用情况及表现的性能指标等方式来发现和定位问题。

7.7 hprof

jdk自带分析内存堆和cpu使用情况的命令行工具。是一个jvm执行时动态加载的本地代理库，加载后运行在jvm进程中。通过jvm启动时配置不同的选项，可以让hprof监控不同的性能指标，包括堆、cpu使用情况，栈和线程等。hropf会生成二进制或者文本格式的输出文件，对二进制的输出可以借助命令行工具HAT进行分析，开发者通过分析输出文件来找到性能瓶颈。