云性能基准测试及其应用研究

可在www.sciencedirect.com在线获取理论计算机科学电子笔记340（2018）23-39www.elsevier.com/locate/entcs云性能基准测试Adam Cattermole1，Matthew Forshaw2纽卡斯尔大学泰恩河畔纽卡斯尔摘要多年来，云基础设施一直作为按需服务提供给众多不同的提供商。不同的实例类型提供了硬件规格，但没有具体的性能指标。对虚拟机进行基准测试是对比和比较多个提供商提供的不同服务的一种方法。本文提出了一种工具，允许自动收集云基础设施的性能信息，比较这些服务的成本关键词：云基准测试，性能评估，开源1引言在过去的几十年里，对云计算的依赖急剧增加。随着技术的进步和连接速度的提高，用户的需求也在增加。许多提供各种不同服务的公司需要使用额外的计算资源，以允许它们继续可靠地提供其操作。在不同科学领域中，也需要使用这些系统来允许在合理的时间内完成一些大型计算。然而，提供所需资源可采取若干不同形式，并有相关成本及收益。云计算环境的性能特征尚不清楚[7]。由于许多不同的因素，很难对工作负载的运行进行预测。为任务提供的机器通常是虚拟化的，很少向最终用户提供底层硬件的功能。某些实例可能比其他实例执行得更好，1电子邮件：a. newcastle.ac.uk2电子邮件：matthew. newcastle.ac.ukhttps://doi.org/10.1016/j.entcs.2018.09.0031571-0661/© 2018作者。出版社：Elsevier B.V.这是CC BY许可下的开放获取文章（http://creativecommons.org/licenses/by/4.0/）。24A. 卡特莫尔，M.Forshaw/Electronic Notes in Theoretical Computer Science 340（2018）23直接影响调度决策，以充分利用可用时间，这反过来又有助于降低成本。这项工作的动机是深入了解云基础设施的性能如何在实例类型和提供商之间变化。这有助于深入探索云计算的真实性能，而不是根据所列硬件规格和历史性能做出假设。通过改进在云上运行的作业的估计执行时间，等待实例变得可用的延迟应该更少通过了解高性能实例类型上的执行时间是否值得增加成本，可以更好地调度具有截止日期的作业如果一个特定的作业被估计在一个供应的实例上剩余足够的可用时间完成，更好的估计可以允许分配另一个作业来充分利用这个剩余时间。为了实现这一目标，我们创建了一个工具，可以用来自动收集来自不同提供商的云实例的计算性能结果通过处理整个测试过程，从配置新的云实例到提取结果，而不使资源运行，该工具的设计考虑到了易用性最初的实现强调云基础设施的计算能力虽然其他人也创建了类似的系统，但有些人更专注于数据驱动的应用程序，可供公众使用的系统较少出于这个原因，我们将此工具作为一个开源替代品，它可以完整地供其他人使用。通过使用此系统，可以跨Microsoft Azure和Amazon Web Services平台(AWS)弹性计算云（EC2），允许对结果进行分析收集的性能信息显示了来自云提供商的不同VM系列之间的巨大差异有些结果显示，从一个实例到下一个实例，性能差异很大，而另一些结果从一次运行到另一次运行，性能非常不同的实例系列在很大程度上具有不同的每小时成本，而成本并不总是具有代表性，例如Azure提供的基本A系列中的多核实例类型通常比其他系列性能更差，同时每小时成本也更高2云基准测试在对云服务进行基准测试时，有些因素可能对性能的影响比其他因素更大。一些云应用程序可能更依赖于实时网络操作，因此可用的总带宽或网络延迟将是至关重要的。越来越多的应用程序与大量数据进行交互，从而增加了对高性能数据存储解决方案的需求。Cooper等人[4]开发了一个评估工具，名为“Yahoo！云服务基准（YCSB），其可用于测量服务云系统的此类数据的性能。YCSB使用多个不同的工作负载，每个工作负载测试系统的各个不同方面，例如读/写A. 卡特莫尔，M.Forshaw/Electronic Notes in Theoretical Computer Science 340（2018）2325操作，不同的数据大小，请求分布等。这提供了一个洞察服务将如何在许多不同的条件下执行。这项研究的重点是对许多应用程序的重要数据服务系统的性能由于资源提供方式涉及许多不同的因素，因此通常很难比较云基础架构或云计算。不同的硬件，虚拟化技术和服务器配置从一个提供商到下一个提供商[3]。已经进行了一些研究，可以更好地比较不同云提供商的计算性能。Li等人[5]研究了这种性能与成本的关系，以及四个独立云计算平台的网络和持久存储性能。为了测量CPU性能，运行了一组来自SPECjvm2008的基于Java的基准测试任务。结果表明，相同价格范围内的某些实例类型可以使彼此的性能翻一番，但成本差异不相等还确认了较高层实例比较低层在更快的时间框架内完成基准测试，即使在单线程运行中也是如此。这表明在高层实例中运行的CPU可能不仅具有更多的内核，而且可能以更高的时钟速度运行Chhetri等人[3]开发了一个名为“Smart CloudBench”的框架该框架通过将应用程序堆栈部署到云基础设施上，并测量相同工作负载的性能和资源利用率来产生结果这被宣传为比运行简单的计算基准更好地评估云基础架构虽然这听起来像是一个很有前途的工具，可以在部署应用程序之前对几个不同的云提供商进行基准测试，但该工具似乎并没有提供给公众使用。2.1SPEC JVMSPECjvm2008是一个用于对Java Java Java编程环境（JRE）的性能进行基准测试的工具。该基准测试模拟了一些现实生活中的应用程序，这些应用程序通常具有昂贵的工作负载，例如加密和科学功能。通过使用SPECjvm2008获得的结果是底层硬件系统的代表重要的是，基准测试使用并强调了现代多核处理器。不同的实验提供了对许多系统方面性能的评估，例如内核和处理器的数量、这些处理器的频率、整数和浮点运算、缓存层次结构和内存子系统[8]。然而，对磁盘读/写的测试有限，没有任何网络测试[9]。SPECjvm2008在充分强调系统内的硬件方面可能不是最有效的，但它具有巨大的互操作性，因为该要求基于系统上存在的JRE。默认情况下，套件中的每个测试最初作为预热运行两分钟，26A. 卡特莫尔，M.Forshaw/Electronic Notes in Theoretical Computer Science 340（2018）23四分钟后进行测试。3执行从云VM收集性能结果涉及几个不同的标准。首先，我们必须获取一个新的VM来执行我们的基准测试，以确保我们以干净的状态运行。然后可以在实例上运行测试套件，并收集结果。对于最初的实现，SPECjvm2008被选为基准测试套件，但它的目的是为未来的迭代，以促进测试套件的选择。最后，在提取结果数据后，必须完全删除云服务，以防止留下任何剩余组件的额外成本入侵微软的Azure平台被选为第一个收集结果的候选平台。实例的供应最初相对简单。 这通过对Azure SDK的几个API调用来完成。首先，必须在正确的区域中创建托管服务，然后允许创建新的VM作为此服务的部署，从而需要指定名称，要使用的映像鉴于SPECjvm2008被选为要使用的基准测试套件，因此必须首先将其与Java可编程环境（JRE）一起安装在我们新配置的VM上。安装有多种选择，第一种是在配置每个虚拟机时下载并安装这些组件。然而，这为每个实例的初始化创建了额外的开销，因此创建了一个自定义VM映像[2]，用于预安装所需组件的地方为了便于使用，此映像基于编写本文时Azure提供的标准Ubuntu 14.04映像要运行SPECjvm2008，必须从安装文件夹中运行命令。pythonparamiko包用于通过Secure Shell（SSH）连接连接到VM，然后可以在VM内执行基准测试。但是，要通过SSH连接，必须正确设置VM以接受SSH密钥，并且必须可以从默认SSH端口（22）访问VM到确保基准测试运行到完成时，在执行的输出流上进行阻塞调用，等待命令退出或通道关闭。一旦返回，基准测试就完成了，结果文件将使用SFTP会话复制到原始机器。最后一步是通过删除托管的服务和部署以及关联的数据磁盘来释放虚拟机。这个过程与Amazon的EC2平台非常相似值得注意的是，这个包需要更少的代码行来完成简单的任务，例如在一个函数调用中从预定义的映像创建特定的VM层。然而，应该注意的是，两个平台及其相关的软件包都有一些设置这必须在以编程方式访问服务之前完成。这包括为Azure创建服务管理证书，A. 卡特莫尔，M.Forshaw/Electronic Notes in Theoretical Computer Science 340（2018）2327文件或从AWS CLI for EC2运行configure命令图1.一、结果收集过程的流程初始实现将遍历不同的实例大小，以串行方式执行这些操作基准本身的运行时间约为2.25小时，取决于启动测试完成的速度。对于每种实例类型都有多次重复，因此按顺序完成基准测试所花费的时间很长。最终的解决方案是利用多线程来克服这个问题。每个线程都存储在一个池中，并管理在单个实例上运行基准和收集结果默认情况下，Azure对托管服务的数量有限制，一次只允许20个。只有在不违反此限制的情况下，新线程才能实例化，并且它们在解除分配关联的VM实例后处理自己从池中的移除。也使用类似的方法从Amazon的EC2收集结果，但使用更高的默认唯一实例限制30。如果实例未能提供，则在尝试运行基准测试时将失败。此错误已得到处理，创建的所有资源都将被删除，线程将等待5分钟，然后再尝试分配。一旦重试计数超过预设的最大值，任何相关的资源被删除，线程被终止。4评价4.1性能性能结果通过第3节中解释的方法提供。每种VM实例类型都经过5次不同的迭代测试，每次运行都提供一个新的VM，以指示实例之间的性能变化微软选择不同的实例类型是为了覆盖可能影响从基准测试运行中获得的分数的广泛范围。总的来说，这包括几个通用目的，28A. 卡特莫尔，M.Forshaw/Electronic Notes in Theoretical Computer Science 340（2018）23实例类型，以及各种定价层的计算优化的VM。术语“层”在整个过程中用于描述特定系列的不同实例或级别。附录A表A.1和A.2中概述了所用不同实例的规范。4.1.1Azure结果收集的第一组结果在Azure表（表1）中详细说明。当查看A系列，基本通用层实例时，正如预期的那样，总体得分随着我们从最低层到最高层的移动而增加（图2）。这些实例类型的成本与硬件规格（虚拟内核和内存）的成本增加相同。但是，从一个实例类型到另一个实例类型，复合结果的增加并不遵循这种模式。如果基准测试是高度并行的，根据Amdahl基础A2级实例得分比基础A1增加了2倍以上，核心数量，内存和价格也增加了一倍。这是不寻常的，因为它表明线程数量增加一倍会导致性能增加一倍多一点。尽管实例上的内存也增加了，但提供给测试中的JRE的内存量仍然是1GB。这可能是一个错误的结果，为Basic A2提供的实例可能只是比Basic A1的实例稍微快一些，但是如果不运行更多的迭代，就不可能证实这一说法。当转向A3和A4变体时，由于成本和核心数量的增加，性能的提高较少。A4的综合结果仅为有效率的84%，如果增加内核数量将性能提高相同的系数。然而，SPECjvm2008基准测试中的如果从综合得分中排除此测试，以便直接从通过线程数进行验证的测试中进行比较，则与每个核心性能的A1相比，可以获得97%的值。这更接近于加速的预期值表1Azure A系列在每个实例类型的5次迭代中的平均性能VM大小编译器压缩机加密德比mpe-gau-diosci-marklargesci-marksmall串行启动太阳-太阳流XML总的来说A121.3113.0415.1425.919.905.7818.1711.505.475.6337.6812.80A263.9428.9231.5450.6820.5410.4839.0724.507.4411.5178.6826.24A3124.5658.8164.7989.2940.6517.6376.6547.198.1322.55153.2647.89A4221.47120.44129.10160.0980.6630.99157.9587.678.0443.63279.2385.66D系列虚拟机是Azure这些处理器比A系列变体更快，这应该会导致更高的性能，同时保持核心数量相同。结果（表2）表明，A. 卡特莫尔，M.Forshaw/Electronic Notes in Theoretical Computer Science 340（2018）2329图二、Azure平均基本实例性能结果（含方差）事实上，每一个D系列的得分几乎是同等基本层模型的三倍。事实上，性能提升如此之大，以至于4核标准D3的性能比8核基本A4高出32%，同时每个虚拟机的成本也降低了0.044美元/小时。与基本A3相比，双核标准D2的性能提高了33%，每台虚拟机的成本降低了0.022美元/小时还收集了D系列的高内存变体标准D11-13的性能结果，其中创建了具有更多内存的JRE以进行测试。虽然额外的内存似乎对产生的性能结果没有任何影响，但标准D13系列与其对应产品D4相比，在不同迭代之间显示出大量的可变性（图3）。这可能在某种程度上是每次迭代发生的时间的结果，因为在成功提供D13实例方面存在一些困难。缺乏性能优势可能是由于JRE提供的内存远远超过所需的内存，而这些类型的VM没有提供额外的内存-“对于在我们测试过的所有JRE中，400 MB对于具有2个硬件线程的系统来说是足够的”[ 10 ]。30A. 卡特莫尔，M.Forshaw/Electronic Notes in Theoretical Computer Science 340（2018）23表2Azure D系列在每个实例类型的5次迭代中的平均性能VM大小编译器压缩机加密德比mpe-gau-diosci-marklargesci-marksmall串行启动太阳-太阳流XML总的来说D157.8734.3438.5061.0625.2615.9348.0029.4514.1114.6195.5133.08D2155.6768.3277.09116.6750.4227.9997.3858.6618.0528.09186.1363.89D3306.36135.30150.47170.2597.5745.50199.49109.3019.5357.11353.39112.94D4549.86271.01290.43414.07188.9271.54397.99209.1819.12112.64679.45206.53D11155.8066.4676.45112.3048.6028.2398.5356.7117.0528.02180.5962.64D12311.39136.41152.10206.5997.9346.41198.56112.1419.5556.97356.60116.38D13546.31257.19300.84348.70195.9568.33381.48207.2219.81115.25703.06202.97图3.第三章。Azure平均标准实例性能结果（含方差）Azure还提供了一个具有更强大CPU的D系列的新变体，名为Dv2系列，据称比原始D系列快35%[6]。基准测试结果（表3）显示，对于SPECjvm2008基准测试，基本通用模型的性能大大提高，在不同层次上的性能比D系列提高了约43%。单核心标准D1 v2型号的性能是同等单核心基本A1的近4倍，而每小时的成本不到两倍。事实上，这个单核Dv2模型的性能与A. 卡特莫尔，M.Forshaw/Electronic Notes in Theoretical Computer Science 340（2018）2331基本的A3 4核机器，而每小时的成本不到一半。其他Dv2层也是如此，双核变体的得分仅略低于基本A4 8核VM，同时成本也大幅降低。在比较D系列与Dv2系列的性能时，成本非常重要。虽然这两个系列的规格对于每个层都是相同的，但是在v2系列中升级了CPU，所有Dv 2系列的成本/小时都低于同等的D系列。这使得Dv2系列的性能提升对用户更加有利，因为利用这种速度没有额外的成本。表3Azure Dv2系列每个实例类型跨5次迭代的平均性能结果VM大小编译器压缩机加密德比mpe-gau-diosci-marklargesci-marksmall串行启动太阳-太阳流XML总的来说d1 v282.5949.0655.9185.4336.5119.8469.4745.9419.8421.83151.0747.59d2 v2230.5598.84113.81160.8472.5232.95139.1490.9625.2641.50284.2891.45d3 v2446.80183.52216.06242.91135.6847.22268.74164.4927.9077.89535.10156.33d4 v2846.63370.90422.39615.61267.0464.25522.43317.2327.72157.771048.73286.37d11 v2233.1396.07112.59167.9870.6535.96138.4086.6425.3039.61278.9291.14d12 v2444.79183.70215.07281.57136.9250.54267.60164.7327.9478.24532.88159.94d13 v2575.80367.98412.32588.54266.9262.29509.81311.8627.92156.941054.62272.914.1.2Amazon Elastic Compute Cloud结果第二组数据（表4）是从Amazon的EC2收集的，在几个T2通用实例、新一代通用M4实例以及一些计算优化的当查看T2实例的结果时，可以看到从一个层到下一个层的性能增加，这通常是在VM的硬件规格也增加时预期的。然而，从t2.micro到t2.small，内核数量保持不变，而内存增加。尽管如此，但JRE为这两个基准测试运行提供了相同的内存量，因此容量的增加不应该影响运行的结果t2.medium和t2.large虚拟机之间的性能也提高了约50%，其中只有2个内核可用（图4）。这种性能的提高很可能是由于T2实例作为可爆发性能实例的性质[1]。虽然这些层之间的核心数量保持不变这种爆破能力将对基准测试结果产生直接影响。然而，性能的最大提升是在t2.small的单核系统和双核t2.medium实例类型之间切换时，后者的得分几乎是前者的两倍，而成本/小时则增加了一倍。较新的通用M4实例类型以2核和8GB内存容量的基准规格开始，与其他大型实例类型一样。这个m4.large实例仅比同等的t2.large实例高出12%，而成本从0.112美元增加到0.132美元增加了17%。性能差异如此微小的原因可能是T2的突发性能。32A. 卡特莫尔，M.Forshaw/Electronic Notes in Theoretical Computer Science 340（2018）23表4Amazon EC2在每个实例类型的5次迭代中的平均性能VM类型编译器压缩机加密德比mpe-gau-diosci-marklargesci-marksmall串行启动太阳-太阳流XML总的来说C4大型156.5568.6670.71136.1749.2628.46106.1255.3825.4128.05179.6066.31c4超大311.31136.74143.20261.1799.6354.34211.10109.6730.6555.99357.84125.58c42xlarge556.12276.84287.60504.95198.1382.04410.20211.2232.95112.61717.18227.19m4大型138.1059.9759.49117.5941.3126.2189.8247.4421.9123.80153.3957.18m4超大270.11118.08119.11224.2983.6948.03182.1492.8126.1847.56303.43107.35m42xlarge521.63238.94237.17437.86167.4675.07354.09180.7427.9394.90608.58196.38t2micro81.4047.0439.1415.493.592.186.925.2719.782.1113.4711.08t2小74.4547.4948.6437.446.994.2313.848.4919.204.1225.0417.38T2医学209.8393.90104.2587.8413.348.1927.7415.6425.488.2549.0034.67t2大228.4393.14110.68179.1639.3212.2941.0327.5626.3012.1085.5151.13每个T2 VM在每个小时开始时都会收到CPU信用，这允许它们突破基线核心使用率[1]。完整的基准测试运行时间大约为2.25小时，并且可能使用几乎100%的可用时间。对于运行的前两个小时，基准测试将用完可用的信用，并在剩余的时间内以基线运行，然后在每小时的边界处提供更多的信用。对于仅使用25%的时间的最后一个小时时隙，基准可以能够在基准的剩余持续时间内利用可用信用爆发。如果在突发时，此t2.large实例的性能高于m4.large实例的性能，但在没有可用信用且在基线运行时，其性能要低得多，则预期性能将在所看到的区域内。在基准测试开始时运行的启动和编译器测试，虽然信用可用于T2实例，但T2实例的结果比M4更好，而其他测试（如scimark和serial）在M4实例上具有更好的性能。如果基准测试在具有高利用率的整个虚拟机小时时隙上运行，则由于在第三个小时内用完信用并且在该小时的剩余时间内以基线运行，亚马逊在C4系列中也有一个计算优化的实例选择，它具有不同系列中性能最高的CPU总体而言，这些产品在每种实例类型的基准测试中的性能比M4系列高出约16%，同时成本降低约10%。成本降低最有可能是由于计算优化的变体的内存容量不到通用M4的一半。由于基准测试不需要大量内存，因此M4实例的额外内存容量不会对结果产生太大影响。高内存消耗的工作负载在M4实例上的性能可能会比C4系列更好，因为与获得的内存容量相比，改进的CPU将C4系列与容量相似的T2实例（在本例中为c4.large和t2.medium）进行比较时，性能提高不到两倍，A. 卡特莫尔，M.Forshaw/Electronic Notes in Theoretical Computer Science 340（2018）2333图四、带方差的EC2 t2实例平均性能结果成本/小时的两倍以上。如果这些实例通过不包括单线程启动测试的分数进行比较，则性能/成本几乎相等。从一个C4实例移动到下一个实例，性能结果并不能完全跟上成本和核心数量的增加。然而，当比较没有单线程“启动”测试的影响的总体4.1.3Azure和EC2两个云提供商之间类似规格的VM实例的结果显示，某些固定实例的性能几乎相同（图5）。其中一个例子是Standard D2和m4.large，这两种2核实例类型分别具有7GB和8GB内存，平均综合得分在60± 3以内在Standard D3和m4.xlarge之间也可以看到类似的结果，Azure的D3再次表现出色。尽管如此，Azure的34A. 卡特莫尔，M.Forshaw/Electronic Notes in Theoretical Computer Science 340（2018）23更新的优化计算Dv2系列也优于EC2等效产品C4实例类型，双核D2 v2的结果比等效的c4.large高38%，成本仅增加23%。然而，其他D2 v2实例的性能增长与成本/小时的增长更成比例。Azure的更高层次的操作系统的主要好处M4或C4实例类型都不提供单核计算机，而Azure具有D系列标准D1和Dv2系列标准D1 v2。对于仅设计为在单线程中运行的任何工作负载，如果首选这些工作负载在较新的计算优化或通用EC2实例上运行，则应将其批量加载到系统上，以充分利用可用的虚拟核心。图五、Azure和EC2的性能比较Amazon的可突发T2实例类型对于较低层实例表现良好。Azure单核t2.small的性能优于标准A1，同时每小时仍便宜0.016美元。然而，由于正在运行的任务的性质和基准测试执行的长度，所获得的结果可能偏向于支持突发性能实例;如第A. 卡特莫尔，M.Forshaw/Electronic Notes in Theoretical Computer Science 340（2018）23354.1.2. 当T2实例具有可用的CPU信用时，突发性能很高，在初始编译器测试中与优化的计算D2 v2 Azure实例类型和A4 8核类似，成本更低。出于这个原因，如果性能要求是可变的，并且遵循更多的“突发”模式，则T2将在成本方面表现最佳如果工作负载在很长一段时间内具有较高的计算要求，则更高的核心计算优化机器可能更好，假设工作负载在多个线程上运行。如果此工作负载需要很大的利用率，但它是单线程的，则更新的更高时钟速度的实例类型将带来更好的性能。4.1.4扩展测试某些工作负载可能是单线程的，因此无法从虚拟机运行的额外内核中获益。这限制了当前云计算平台上这类任务的选项数量，因为多核系统的价格代表了从额外核心获得的性能。但是，可以将多个单线程任务批量加载到多核实例类型上。如果多核实例上的单个线程的性能高于单核系统的性能，并且每个核的价格相同，则可能值得在多核系统上每个核加载单个线程作业以利用更高的性能。SPECjvm2008支持在单线程模式下运行[10]，因此已经收集了D系列和Dv2系列多核变体的性能结果。由于之前收集的结果没有受到高内存实例类型的严重影响，因此D11-13 VM类型已被排除在测试过程之外。表5Azure在每个实例类型的5次迭代中的单线程性能结果平均值VM大小编译器压缩机加密德比mpe-gau-diosci-marklargesci-marksmall塞里亚尔启动太阳-太阳流XML总的来说D155.4234.2236.9563.3224.6315.6448.1527.9913.7714.2089.7132.32D283.3935.0739.4066.2925.8216.2649.2531.1218.1628.5597.9738.14D381.3735.1639.0362.2425.1516.8451.8828.4820.3752.8193.9440.15D482.2034.0739.0966.5325.0116.3549.2429.7220.0952.6595.6440.17d1 v280.3947.9955.5296.5436.2920.3467.4743.1020.6920.91140.5947.33d2 v2117.7648.9155.3283.9536.0122.0667.5943.5624.5538.64137.5252.36d3 v2120.1748.8657.3192.2536.0721.8770.0044.0827.2370.43144.3857.05d4 v2117.3147.5257.1192.1736.2422.6069.3044.1527.2971.10141.5356.87在大多数测试中，特定系列的不同VM类型似乎具有非常相似的单线程性能。这很可能是由于一个系列中的不同实例层是从相同的硬件配置的，而虚拟化技术则位于顶部。CPU的最大时钟速度将是相同的，从而导致几乎相同的单线程性能。然而，除了最大的实例类型D4之外，“sun millow”测试似乎从一个实例到下一个实例都有所改进。这是由于测试的性质，其中每个硬件线程使用一个4线程的捆绑。当在单线程模式下运行时，测试仍然创建4个线程，随着硬件线程数量的增加，每线程增加，最多4个核心[8]。D4类36A. 卡特莫尔，M.Forshaw/Electronic Notes in Theoretical Computer Science 340（2018）23图第六章Azure单线程平均性能结果与方差实例具有8个核心，因此除非引入第二个捆绑包，否则不会更优化地执行。这对结果有负面影响，因此，在计算总体数值时，也删除了日光测试。当将D系列与Dv2系列作为一个整体进行比较时，所有测试的性能都大幅提高。这是Dv2系列中改进的新CPU的直接结果，相当于近40%的性能提升。但是，在对一个标准D3实例类型的测试过程中出现了一个异常值。在所有测试中，基准测试结果均显著高于相同层级和系列中的其他实例，约高出40%（图6）。事实上，这个测试实例显示的结果与Dv2系列中的实例类型非常相似。在未进行进一步检测的情况下，很难确定该结果的根本原因另一种扩展测试的方式是随着时间的推移测量性能其目的是查看当新实例化的实例最初表现不佳时，性能是否会随着时间的推移而提高，或者是否会持续降低性能。但是，在配置实例之后，并没有运行整个基准测试，而是使用一个测试来指示A. 卡特莫尔，M.Forshaw/Electronic Notes in Theoretical Computer Science 340（2018）2337VM执行。之所以选择SPECjvm2008基准测试套件中的压缩测试，是因为它在迄今为止的测试中很好地代表了底层系统的功能。测试本身也与线程数量近似线性地扩展[8]，这应该在多核机器上提供更好的性能估计。为了测量实例随时间推移的性能，在10个单独的标准D1 v2实例上运行了这个单一的结果可以在表6中看到，其中倒数第二列表示第一次迭代与所有后续迭代之间的最大差异，以及最后一列与平均值的差异表6压缩测试在10个不同的实例上每隔10分钟运行一次实例Iteration1Iteration2Iteration3Iteration4Iteration5Iteration6平均年龄最大下降最大增量从平均年龄151.1951.8651.6450.4251.9551.6251.45-0.770.760.26251.9750.4851.7252.1551.0151.3951.45-1.490.180.52349.450.2449.8850.0349.7550.2749.9300.870.53447.848.3747.0547.5847.4348.8147.84-0.751.010.04548.7751.3750.2951.0850.3550.3550.3702.61.6649.748.9348.8549.8548.4848.8149.1-1.220.150.6751.7151.2751.5651.2350.4250.8751.18-1.2900.53849.6450.3352.0550.6551.6750.5850.8202.411.18947.6849.1649.5549.1549.7548.9449.0402.071.361050.2649.9748.7449.0749.6849.249.49-1.5200.7750.07-0.71.010.74对于这组测试，压缩测试的输出在所有方面都非常相似一些实例在所有6次迭代中保持相对一致，例如实例编号3和7，运行之间的最大结果变化分别为0.84和0.81。其他的执行更不稳定，例如实例5，从第一次迭代到第二次迭代，压缩结果增加了2.60。实例4与其他实例相比表现得特别差，在第三次迭代中得分最低，48.81.一半的实例没有产生那么低的结果，另外三个实例的最低分数也没有远低于这个值。性能较高的实例1、2和7的得分均高于50.42，平均得分大于51.18。然而，这组测试的目的是评估第一次测试迭代与其余结果的关系。在40%的情况下，最初的测试迭代是最低的分数，其中三个测试的性能提高了2.00分以上。然而，在两个实例结果中，初始测试运行结果是这段时间内最高的，性能比此结果下降了1.52。从初始结果到整个虚拟机的平均得分的差异 结果的范围从0.04到1.60，其中初始结果对实例的性能给出了良好的指示，而平均值大于初始结果所指示的值。这些与初始结果的差异表明，很难从初始读数判断实例;在某些情况下，这是可行的38A. 卡特莫尔，M.Forshaw/Electronic Notes in Theoretical Computer Science 340（2018）23好吧，但其他人不会。从一个实例到下一个实例的可变性将使得这种方法在使用它之前测量VM性能是不切实际的。为了改进这种方法，初始测试可以运行更长的持续时间，以尝试更好地表示实例的随着时间的推移，不同的VM类型也可能执行更少或更多的任务，因此更高的实例层可能会产生更有用的结果。5结论在整个研究过程中，我们的目的是创建一个基准测试工具来收集云基础设施的性能信息，这些信息反过来可以用于做出更好的调度决策。该工具旨在允许直接比较一个虚拟机与另一个虚拟机的计算性能，而不考虑服务提供商。在撰写本文时，所介绍的系统可能只支持SPECjvm2008测试套件，但最终目标是让该工具充当其他基准测试软件的工具 虽然其他人，[5]，[3]，执行类似的实验，这里所涵盖的，我们的目标是提供这个工具作为一个可用的开源系统，供其他人使用3。该工具已被用于测量来自两个不同云服务提供商的各种实例类型的云计算，据观察，成本的增加并不总是反映在更高的计算性能。引用[1] Amazon，Amazon EC2实例类型，https://aws.amazon.com/ec2/instance-types/，访问时间：2017-03-15。[2] Avanessians，C.，Azure VM镜像，https://azure.microsoft.com/en-us/blog/vm-image-blog-post/，访问时间：2017-04-16。[3] Chhetri，M. B、S. Chichin，Q. B. Vo和R. Kowalczyk，Smart414-421[4] 库珀湾F.、A. Silberstein，E.塔姆河，巴西-地Ramakrishnan和R. Sears，Benchmarking cloud servingsystems with YCSB，in：Proceedings of the 1st ACM symposium on Cloud computing，ACM，2010，pp.143-154.[5] Li，A.， X. Yang， S.Kandula和 M.Zhang， CloudCmp： 比较 公 共云 提供 商 ， 收录 于 ：第 10届 ACMSIGCOMM互联网测量会议论文集，ACM，2010年，第10页。1-14号。[6] Microsoft，Azure Virtual Machines Pricing，https://azure.microsoft.com/en-gb/pricing/details/virtual-machines/，访问时间：2017-04-16.[7] Mohamed，S.，M. Forshaw，N. Thomas和A. Dinn，分布式基于事件的系统的性能和可靠性评估：动态代码注入方法，第8届ACM/SPEC性能工程国际会议（ICPE），2017年。[8] 希夫，K.， K. 周，Y. Wang）和雅江翠雀花（D. Petro