【编者按】
Linda，Cirrus Data的创始人之一，本科毕业于清华大学精密仪器系，于2005年获新泽西理工计算机博士学位，研究存储阵列调度算法。本篇文章是Linda存储手记系列第三篇。我仔细看过了，里面干货不少，例如深入剖析了延迟和响应时间的异同。欢迎转发，也欢迎投稿。
Linda存储手记的前两篇：
第一篇《一个投资顾问兼研发老兵（RAID调度算法博士）的存储手记》
第二篇《【原创】Linda存储手记之二》：QA Engineer和自动化测试
第三篇 《【原创】Linda存储手记之三》：延迟和响应时间：相同，却又不同
备注：封面照片是Wai Lam
---Begin---
上次文章发出后，Peter转给我几个读者的提问。有的探讨了问题基于的数学模型，可见提问者的学术功底；有的对一些结论表达的精确程度产生质疑。这些让我再次感慨学术界和工业界的分（分歧）与合（统一）。
无疑，学术研究为技术发展指引了方向；但前提是要基于技术实践而生、并从技术中提炼。有很多经典的书籍[1]生动的记录了理论和实验在人类科学进步中的轨迹；恰如我们走路留下的脚印一样，左右前后，不断前行。个人认为，实验设计绝对可以成为一门独立学科：且不用说其伟大作用，仅实验内容的覆盖性、参数取舍、对结论支持的有效性、数据展现（类data visualization）甚至排期，都要独具匠心。
就这点我曾和我的免疫学家姐姐在一次闲聊中发现，学术界和工业界一样，都有那么一些工作根本不知道要证明什么、或得到什么结论，而没头没脑的堆积大量数据。最近在一次POC测试中，我也对客户迫切想拿到产品的测试报告、但在我再三询问后却仍无法得知他们到底想要什么指标、证明什么问题而感到困惑不已。
我很希望通过几篇笔记，把存储界常用却又容易含糊的（指标）名词加以确认，并用直观的场景描述和大家分享这些名词的用意，即“为什么是这样”和“它们能反映什么”；我相信，这对分析问题大有好处。
以下译文来自技术博客，作者：Wai Lam于2015年4月24日，Linda译。
正如上期讨论的“延迟和响应时间：相同，却又不同”所说，在评估存储性能的时候，这两个概念往往容易被混淆。在存储领域，评定性能最常用的是吞吐量throughput和每秒的I/O（IOPS）。吞吐量以每秒传输的字节数来计量；如今，是MB，估计不久就会是GB了。而IOPS如字面得知。不过，更多人会对延迟产生疑问，其中两个经常被提出的问题是：
- 1. 延迟是评定性能的又一个指标么？
- 2. 延迟对吞吐量和IOPS产生影响么？
让我们先看第二个问题。上期我对延迟做了一个普适的定义，即发给存储系统的单个小I/O的响应时间（Linda：总体响应时间是整个系统各个组成部分的综合结果。当命令是极小的数据时，和延迟相比，读/写时间极微甚至不在一个数量级，可忽略）。
对发出的读命令来说，延迟是从命令发出至返回读取数据的时间；对发出的写命令来说，延迟是从命令发出写数据至数据成功写完并返回确认的时间。
系统的延迟往往因硬件特性而各异，譬如机械臂的移动、信号延迟或不同的处理逻辑；当然，因其他系统访问同一存储也会产生动态延迟。另外，当数据路径中插入其他硬件也会增加延迟—不避讳的说，我们的技术（Linda：这项透明插入数据路径的发明技术是CirrusData的专利技术）也会给系统增加延迟，即使非常微小。
关键是—增加的延迟是否会降低IOPS和MBPS？
答案是：Yes，and No。
“Yes”是建立在绝对意义上的：任何增加的延迟都会在某种情况下以特定方式对I/O访问产生一定程度的影响。例如，倘若一个应用是每次只对一个I/O做完全串行的处理，那么每个增加的延迟当然会影响到IOPS，进而也会影响吞吐量，因为延迟影响有累积效应。但实际上，极少的应用软件会用完全串行的单一小I/O访问存储系统。绝大部分都是同时并行处理大量的I/O，这也就回答“No”—延迟通常不会影响吞吐量和IOPS。
这里用一个例子来说明。
比方说一个存储系统有100,000IOPS的处理能力，和客户端主机用一根长长的线缆连接：假设线缆长10英里、有100微秒的延迟。如果我们用一些单一1KB的I/O，则完成每个I/O需100微秒；IOPS为10,000，吞吐量为10MB/s。但如果我们将线缆长度增加10英里--延迟也相应增加，那么完成每个I/O的时间成为200微秒，继而导致5,000IOPS和5MB/s的吞吐量。
然而不要忘了，大多数应用软件都是在同时处理大量的I/O。即使是一些关联性数据需要串行完成，系统也通常会在同一时刻并行处理多个这样的有关联性的数据交易（database transaction）--只要交易之间沒有关联。
用前面的例子，再让系统同时发出10个I/O。10英里的线缆将得到100,000个IOPS，吞吐量为100MB/s；20英里的线缆则有2倍延迟，于是得到50,000个IOPS，50MB/s的吞吐量。
如果我们现在同时发出20个I/O呢？我们已经提到存储系统的处理上限是100,000IOPS，于是在10英里线缆的情况下，任何发出的I/O高于10都不会提高性能了。而在20英里线缆的情况下，同时发出20个I/O能将IOPS提升到100,000和100MB/s的吞吐量。也就是说，当并行处理I/O的量足以弥补延迟时，吞吐量和IOPS将不会被影响。
至于第一个问题，延迟是否是评定性能的又一个指标，个人认为并非如此。拿延迟绝对值来评定性能的情况极少。我的确听说过高频交易所会为打败对手而在纳秒级争夺；但你大可放心，因为他们会用昂贵、惊人规模的高速内存，并在地理、物理位置上采取尽量靠近交易的运作地点--这种机构能负担如此高昂的开销，因为他们在每一个有可能赚钱的节骨眼都会不遗余力。不过，通常和他们一样有如此要命需求的应用不多。
本文中提到的每个实验都可以通过IOMeter或FIO等标准测试工具验证。对于某些产品，一旦用到将数据缓存到SSD，延迟将会从毫秒降低到微秒的范围，也将大幅度提高I/O性能。
[1]在这点上，KipThorne的《黑洞和时间弯曲》堪称一部物理发展的史诗。
---End---
微信公众号平台"乐生活与爱IT"在目前阶段，主要是分享软件定义存储(SDS)，及VMware VSAN相关的文章，偶尔也会分享虚拟化、云计算、大数据，甚至生活类的好文章，欢迎对SDS感兴趣的朋友，加入软件定义存储讨论 QQ群:122295009，可下载原创的一些文章，及其他有参考价值的文档。
欢迎您通过扫描关注微信公众号：“乐生活与爱IT”。
关注后，可以通过点击左下角的“文章目录”，通过输入三位数（记住！是三位数，目前第一位是0或者1）详细了解如何查看历史文章。
