正文
获取设备基线性能的想法与实践
背景
产品的发展离不开功能实现和性能满足
功能实现还是可以通过功能测试，UAT等方式来验证。
性能是否满足有时候比较难处理。
虽然可以通过压测。但是压测时总会有太多的变量较难控制
一般客户也不会提供一套跟生产一样的环境进行验证。
感觉此时服务器硬件性能基线的获取就比较重要了。
通过服务器处理业务需要的资源进行一定比率的缩放。
能够简单验证，产品提供的硬件后是否满足基本的需求。
需要注意。 验证服务器资源不够的话可能比较准确。
但是验证服务器资源充足却比较困难。
因为正常业务的需求可以适量评估。但是异常代码下的场景无法评估。
很多低效代码再遇到瓶颈时会出现非常严重的性能劣化。
还需要注意点的是：
虚拟机因为有超兽和漂移的影响， 以及相同宿主机算例争抢的情况。
所以建议如果对虚拟机进行基线获取，最好是可以在不同时间节点进行获取比对。
建议多次进行运算，获取均值。
物理机器虽然理论上没有虚拟机的这些异常情况
但是电源供电，空调温度， 以及网络拥塞程度偶会影响性能表现
建议也进行明确和确定
基线获取第一部分-基本硬件信息
0. 机器基本情况：
物理机还是虚拟机， 物理机的话机器配置厂商。
虚拟机的话 虚拟化平台。存储使用情况。
1. CPU厂商，型号，主频，缓存情况。
核心数，主频。是否超售
2. 内存大小，型号
物理机考虑通道数，DDR几代，时序，工作频率2400or3200等
3. 硬盘大小，硬盘类型，硬盘型号
机械硬盘还是固态硬盘，接口类型。快大小。Raid卡类型，Raid卡配置。
4. 操作系统信息
厂商，版本，内核版本，部分内核参数配置，TCP，IO
文件打开数，防火墙，IO调度算法等等。
基线获取第二部分-测试benchmark
1. CPU算例部分
SPECCPU2006
SPECJVM2008（CPU和内存）
stress-NG
pi计算
context-switch
2. 内存部分
lmbench
cpu-z
3. IO部分
fio、gfio
diskspd
hdtune
dd
4. 网络部分
netperf
iperf
5. 综合部分
redis-benchmark
sysbench（数据库）
性能基线的要求
1. CPU部分
可以使用SPECCPU2006、2017进行验证。
单核心能力基本上对应RT时间的比例。
多核心能力可以部分反映系统的并发系统性能。
飞腾单核心跑分只有13，导致跟Intel最新CPU比较差距较大。
2. 内存部分
内存部分一般主要是考虑带宽，时序以及频率。
基本上CPU都无法喂饱CPU。在CPU能力成瓶颈的情况下
内存越好，性能表现越好。
3. IO部分（磁盘和网络）
IOPS需要与业务常见的TPS关联起来，一般数据库的一个事务的IOPS可能差异巨大。
从1到1000IOPS都有可能， 这一块要根据业务场景，数据量来分析
需要注意理论上IO仅数据库部分需要考虑，应用服务器影响启动和日志较多，其他影响较小。
网络部分所有的服务器都需要考虑。
应用服务器既要作为跟客户度沟通，又要跟数据库沟通，其实对带宽要求很高。
网络延迟好，带宽足够，不丢包才是良好的性能的前提。
这时候内核参数也很重要
4. 综合部分
redis-benchmark 很诚实的反馈机器的性能表现。如果有落盘参数，对磁盘也可以进行兼顾测试。
sysbench采用数据库模式测试，可以反馈部分性能瓶颈，但是意义可能不是非常大。不同业务场景差异巨大。
