对于那些定期执行大量文件同步操作的云文件共享客户来说，潜在的文件处理开销是一个非常重要的评价量化指标。我发现，一个容量为50MB或100MB的文件是一个比较理想的测试对象，因为一方面其容量小到足以快速运行，另一方面其容量大到不会在运行时引入测量误差。测试文件中包含的数据类型应当是不易被压缩的——例如视频文件——从而确保测得的传输速度不是一个大文件被压缩至很小后的传输速度表现。
我还建议使用一个包含了众多小文件的文件夹——我所使用的一个文件夹包括了每个容量为10KB约5000个文件。测试所需的数据传输时间非常短，这一测试结果为我们揭示了云文件共享服务中任何类型文件的传输开销。
但是，确定测试文件的类型仅仅只是一个开始。下面的内容将帮助您准确地获得和理解您的云文件共享服务基准测试项目的测试结果。
精确测量是关键
最终，我们需要测量的参数是大文件的传输容量和文件夹中小文件的被处理数量，这主要取决于具体使用测试套件中的那一部分。为了实现这一目标，您需要知道有哪些对象被传输以及传输所用的准确时间。虽然这听上去好像很简单，但这恰恰正是云文件共享服务测试过程中最具挑战性的一部分。此外，在进行测试时应关闭自动同步功能。
为了进行测试，应将作为测试基准的文件或文件夹载入至客户端上相应的测试文件夹以便测试上传，或载入至云界面以便测试下载。
有些云文件共享服务提供了在同步事件从启动到结束期间记录相关信息的“易读”日志。而其他的服务则可能不会提供非常精确的同步持续时间，它们使用“小时” 和“分钟”而不是“秒”来作为同步功能结束时的状态信息。不幸的是，您的测试恰恰需要精确的“分钟”和“秒”信息来计算传输速度。这里有几种方法可供您使用来测量同步运行时间，但其中最简单也是最有效的方法之一就是通过使用秒表功能。即，当同步操作启动时点击“开始”，而在出现“同步完成”消息时点击“停止”。
如果您必须对同步功能进行手工计时，那么这是为您的测试文件找到“合适容量”的另一个好理由。例如，如果文件过小，在三秒钟内就运行完成了，那么用户就很可能会错误点击“开始”和“停止”按钮，从而给测量结果带来极大的测量误差。而如果运行时间为100秒，那么点击“停止”按钮时的二次延迟就不会对测试结果带来多大的影响。同样，如果您选择的文件容量过大，每次运行都要运行90分钟以上，那么您就不得不坐在电脑桌前盯着屏幕等待“同步完成”消息出现。
秒表计时的方法可能并不是非常理想，但它可能就是你的最佳选择了。我已经尝试过很多其他的测量方法，其中成败各半。有一次，我使用了开源的 WireShark网络捕获工具来捕捉跟踪整个同步事件以供后期分析使用。该工具为每一个数据包都提供了详细的时间标记。但是，每一种服务都在数据同步操作中使用了专用协议，因此任何尝试精确定位同步事件的开始与结束都纯粹是靠撞大运的。
我还曾使用了AutoIT脚本工具来显示时间并截图以供后期查看。该工具能够以任意时间间隔循环执行截图功能，从而实现所需的测量精度水平。但是，你可能需要在后期从数百张截图中手动筛选找出显示“同步完成”消息的截图。
报告结果：度量转换统一单位是有益的
在收集完精确测量数据之后，您需要通过一种有意义的方式进行报告。我已经看过一些测试者的报告，他们把原始结果——持续时间——作为云服务的最终性能指标。但是，我相信应当把测试结果转换成为一个更有意义、更具普遍价值的指标。对于大文件传输，这个基本的性能指标是Mbps。
您还可以使用吞吐量测试结果，以及计算吞吐量和可用链接速度的比值。因此，当一个10 Mbps 的链路中显示5Mbps 的下载速度，那么其使用率为50%，您就可以使用在不同位置运行的测试进行比较，不仅可以比较原始吞吐量，而且可以比较相对于可用宽带的吞吐量。这是一个比较简单的计算，它可以向使用者提供一些很有价值的信息。
对于小文件测试来说，Mbps的实际意义并不大。用户真正关心的是每分钟被处理了多少个文件，这一指标可以通过将被处理文件数量除以以分钟为单位的时间来计算得到。虽然你可能没有想到在不同云文件共享服务之间这个时间会有很大变化，但这就是事实。我曾经见过一些测试，其中一家供应商能够实现约15个文件/秒的处理速度，而另一家则每两秒种只能处理一个文件。
云文件共享服务陷阱
当对云文件共享服务项目进行基准测试时，这里需要我们有更多一些的思考：
• 测试地点：数据吞吐量会随地点不同而不同，并且其间的差异也是非常巨大的。如果您的用户群主要位于芝加哥，那么您的基准测试地点就不应选择在旧金山。在两个地点实现相同的带宽配置并不意味着其测试结果会是一样的，这是因为我们没有简单的方法可以了解每个办公室和服务供应商设备之间的延迟或带宽。所以，应当在用户使用该服务的位置进行测试。
• 异常值：您的测试结果可能会在一天中的某个时间、一周中的某一天又或者出于未知原因而出现显著差异。数据的传输是通过不受您控制的云的，这就意味着其中有可能存在着几个Mbps的测量误差。为了解决这一问题，您需要把这一情况告知测试结果的审查者，即该测试结果是一个可变的性能测试。您可能需要重复进行五次测试，剔除其中最好和最坏的结果，然后对剩余测试结果求平均值。云的本质就是如此，您可能需要在较长的一段时间内进行多次重复测试才能获得一个具有较低标准偏差的测试结果。如果您只是简单地对所有测试结果求平均值，那么其中的一些粗大误差将会导致与真实结果相差较大的偏差，这样就造成了测试结果不具较高的可信性。
• 影子副本：这一测试还有可能存在着一些特别的陷阱。例如，您可能会使用相同的文件作为测试对象来进行重复多次测试，这貌似没有问题。但是，如果您发现突然之间这些文件的上传速度较之前骤然有了较大提升，那么这有可能是因为供应商采用了影子副本技术。如果这些文件已经存在于服务器上(即便是隐藏在回收箱内)，那么一些系统会非常聪明地检测到这一点而不再一次地执行上传操作。与之类似，相同的情况也适用于您已下载的文件。您应当删除并清空回收箱以确保您是真正地把这些文件下载到您的同步文件夹内。
有条理地使用常识来检查您的测试结果的完整性，并把测试结果转为有意义的指标，那么您就会知道您的下一步选择方向了。
本文作者：滕晓龙
来源：51CTO
