存储性能基准

一直在思考自己的存储项目的性能评估问题，现在有些想法和结论记录下来。

从业务目标上看，一直在强调N人同时在线之类的概念，顺其自然在服务端的性能方面，考虑的是并发能力。最后的结果就是服务端的性能基准的首条成了并发，开发和测试在评估的时候，也在伪造着所谓的并发强度。交流中最常听到的就是：“你那边能支持多大的并发？”，“我这边到了**并发的时候常常出问题”之类的。同时，心中又在常常疑惑着，“并发”是什么概念，到底意味着什么……在这样的背景下，制定的第一版的I/O性能基准为：随机I/O下的并发、IOPS、响应时间；顺序I/O下的并发、吞吐量。

先撇开顺序I/O，对于随机I/O下的并发、IOPS、响应时间，不管从资料上、初步的测试结果上、理论上，疑点重重，总是分析不清。最后发现是被强加的并发的问题，对于随机I/O，要的只是IOPS和响应时间。所有测试的基本结果只要给出一个最大的IOPS，以及在不同IOPS水平下的平均响应时间。但是要强调的是，这样的结果并不意味着忽略系统的并行能力，而是已经包含在测试里面。在假设响应时间变化不大的情况下（这其实是追求的目标），IOPS到一定程度之后，IOPS越高，其实也意味着系统的并行能力越强。

说到这，很多人会提出一个在性能方面常常问的一个问题：“如果10个请求一起发起跟100个请求一起发起……”（大概很多也就是把这里面的10跟100作为评估性能并发的标准）。我要说的是两点：第一，提出这样的问题，并行的概念还不是很强烈，因为都认为100个请求的平均响应时间会比10个请求的平均响应时间长。但实际上，系统的并行能力其实要解决就是这样的问题，让多任务跑起来跟单任务一样快！如果100个请求真的掉下来了，掉得很厉害，我只能说这其实已经到了系统的平行能力的合理范围之外了；第二点，我更倾向于认为一起发起其实在一段很短的时间内完成的，那个10个跟100个所谓并发的问题变成了在t时间内IOPS为10/t跟IOPS为100/t的问题。

这样说来，其实测试黑盒跟系统黑盒之间或者用户黑盒跟系统黑盒之间，交互的只是IOPS即每秒发起的IO数，跟平均响应时间（或者给个响应时间分布什么的）。发起端根本没有办法决定所谓的并行程度。

回到业务层次，N人同时在线意味着什么？什么也不意味着，N人同时在线只能说不停的有IO请求，服务端看到的只是不同水平的IOPS。同理，IO也可以理解成其他的业务请求，结论也一样，性能评价也一样。最后再问两个问题：业务你说N人同时在线，你真的知道平行要求是多大吗？同样，测试你在模拟并发请求，模拟结果真的是你想的那样吗？