获取设备基线性能的想法与实践

背景

产品的发展离不开功能实现和性能满足
功能实现还是可以通过功能测试，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采用数据库模式测试，可以反馈部分性能瓶颈，但是意义可能不是非常大。不同业务场景差异巨大。