如何通过业务模型，评估系统性能和配置？

      在项目实战中，需根据业务真实诉求，针对业务模型进行最佳实践分析和洞察，从主机端口、存储系统、后端磁盘等端到端进行分析和评估，才能提供比较切合业务诉求的配置。

      基于项目实战，作者已经总结出一套性能评估技术方法论，并整理成文的“IO知识和系统性能深度调优全解(第2版)”电子书，通过原文链接获取详情，感谢您对咱们公号的支持，资料目录如下。

      那么，通常有哪些因素会影响对性能的准确评估呢？在本文中会把项目性能评估中遇到的难点话题依次罗列，希望对大家有所帮助。

一、IO聚合优化写惩罚

     IO聚合成满分条大小的情况下，无需做预读操作，不会触发RAID写惩罚，RAID写惩罚在不是满分条写的时候，才会触发预读的流程。以RAID5-5小写为例，写一个数据位，需要预读两次，写校验位一次。可以认为是一个IO被放大成了四个IO。

     而满分条写的时候，同时写四个数据位，不需要预读，只需要额外写一次校验位，可以认为是四个IO被放大成了五个IO 。对比非满分条写，效率大大提高。

     存储的IO合并能力对于数据库业务是否各家都能做到IO合并呢？一般存储针对不同类型的IO有不同的合并能力；数据库业务主要是随机IO，各厂商都做不到完全满分条IO合并。存储收到的IO是否能够合并，主要取决于两个方面。

     1、主机侧发下来的业务IO是否顺序，是否连续，与主机业务软件本身、主机侧块设备、卷管理策略、HBA卡拆分策略等相关。主机下发的IO越顺序、越连续，到达阵列后的合并效果越好。

     2、IO路径上的Cache、存储块设备、硬盘等模块都会对IO进行排序与合并的操作，试图尽可能将小IO合成大IO下盘。

     对于顺序小IO而言，基本上能够实现将IO都合并成满分条后下盘。而对于IO随机程度较高的数据库业务，各厂商都无法确保所有IO都能够合并，只能尽量通过排序和合并，将相邻地址的小IO合成大IO，但合并程度由于算法实现和内存大小等因素可能会有所差异。

 

二、场景的业务模型

     OLTP、OLAP、VDI和SPC-1是当前性能评估中常见的三类业务场景。SPC-1是业界通用的随机IOP