动态QoS Web服务托管环境中的随机模型与资源分配

理论计算机科学电子笔记151（2006）77-95www.elsevier.com/locate/entcs随机模型在动态QoS Web服务托管环境中的应用Charles Kubicek查尔斯·库比切克1，2纽卡斯尔大学东北区域电子科学中心英国摘要在网格环境中为其他组织和用户托管Web服务的数据中心必须提供服务质量（QoS）要求，以确保部署的服务按需执行。由于数据中心托管的服务会收到不可预测的需求率，因此必须将服务器动态分配给过度使用的服务池，以避免违反QoS要求。这项工作描述了如何使用基于成本的随机模型资源分配的数据中心中间件，以平衡服务器的利用率，以及如何使用该模型，使数据中心，以满足QoS的要求。 随机QoS模型的QoS模型进行了比较，并在一些实验中被证明是最有效的保留字：服务质量，动态资源分配，随机建模。1引言随着基于网格的技术变得越来越普遍，提供托管服务的数据中心正被组织用来运行计算密集型应用程序和托管服务。数据中心可以与其客户协商协议，为部署的服务提供特定的服务质量（QoS）级别，这些级别在服务级别协议（SLA）中正式指定。SLA为数据中心客户提供保证，确保来自其客户的请求将获得一定级别的服务。数据中心必须应对托管的每个服务的不可预测的需求为了避免某些服务的暂时过载和其他服务的负载不足，数据中心可以1这项工作是作为由英国电信和东北区域电子科学中心资助的合作项目GridSHED（网格调度和托管环境开发）的一部分进行的。2电子邮件：charles. ncl.ac.uk1571-0661 © 2006 Elsevier B. V.在CC BY-NC-ND许可下开放访问。doi：10.1016/j.entcs.2006.03.01378C. Kubicek/Electronic Notes in Theoretical Computer Science 151（2006）77动态地将计算资源分配给正在经历高需求的服务，而远离那些没有需求或需求很少的服务我们的目标是制定有效执行这种动态再分配的政策。这些政策是基于[9，6]中研究的随机优化模型这项工作表明，某种启发式切换规则接近最优。在本研究中，我们已经实现了启发式在一个真实的环境。它的性能进行了测量，并与更简单的资源分配政策进行了比较。最近提出的一种在网格系统中提交作业的方法涉及在服务提供者上部署应用程序，然后将其作为Web服务提供[2，12]，这些Web服务可以由授权方使用SOAP[11]调用我们在系统中采用这种作业提交方法，以便传入的作业是指向服务器上托管的Web服务的SOAP同时还介绍了一种基于用户需求的Web服务上传和动态部署的方法。我们描述了三种方法来扩展系统，以满足QoS的要求。首先，我们描述了如何持有成本值所使用的启发式重新分配的决定可能会被操纵，有利于作业类型具有更好的QoS。然后，我们使用QoS比率计算和QoS百分位数计算来分析作业的响应时间该方法进行了测试，使用的系统与工作提交模式类似，在一个真正的工作提交系统中观察到的实现。数据中心的利用率不足和QoS问题都已得到研究，并提出了许多解决方案。使用负载预测的模型表明，即使在峰值到达率下，也可以通过重新配置不同的参数来满足QoS要求[8]。另一个模型[10]表明，通过使用到达率、服务时间和CPU利用率测量在数据中心的应用程序之间切换服务器，可以节省大量资源。预测方法也被用于动态调整应用程序的资源共享[3]。其他工作表明，服务器在加入新的服务器池时可能会加载新的操作系统[4]。其他报告的工作从本文中的工作，因为我们假设网格式的工作，这是长期运行和计算密集型。2系统架构2.1资源供应模型所提出的资源管理系统为包含多个服务器的系统模型提供动态供应能力，所述多个服务器一起处理对多个托管服务的请求，所述多个托管服务的数量可以随着服务被部署和移除而随时间改变。发送到服务的每个SOAP消息都是一个作业。作业到达并根据所请求的服务被分配作业类型i，其中i = 1，2，.，m。然后，作业被路由到与服务相关联的队列，其中，在给定时间，类型i的作业的队列大小被给定为ji。假设所有队列都是无界的，并且仍然可以看到当前正在服务的作业C. Kubicek/Electronic Notes in Theoretical Computer Science 151（2006）7779在一个队列中。在专用于处理类型i的作业的池中存在多个服务器ki，其中系统中的服务器的总数被给出为：k1 + k2 +... +km=N服务器可以在硬件和软件上不同，并且可以具有不同的容量，但是类型i的服务器必须正确地被确认为服务类型i的作业。池中的服务器在地理上可能是不同的，并且驻留在提供适当网络和安全基础设施的不同站点。测量作业类型i到达之间的间隔，平均到达率以λ作业每秒给出。每个作业的服务时间也被测量，作业类型i的平均服务率以μ作业每秒给出。使用最后x个作业的窗口的测量来评估平均值，其中x可以由系统管理员定义。因此，较大的x值将以较长的处理时间为代价我们还考虑了在队列中保持一个作业的成本，用ci表示在一个时间单位内保持一个类型i的这种成本可能反映了一种工作类型对另一种工作类型的重要性。虽然在服务部署之后，服务器到池的分配可能是静态的，但我们感兴趣的是服务器可以在池之间连续切换的情况当前由要切换池的服务器提供服务的所有作业都必须暂停，从服务器中删除，并置于其队列的前面，处于等待状态。如果环境允许并且作业状态被保存，或者作业的任何先前处理被取消，则作业可以被检查点化系统不测量已取消作业的处理时间将服务器从池a切换到池b所需的时间，平均为1/1000ab。在该时间间隔内，服务器无法处理任何类型的作业。由于不同的作业可能具有不同的硬件和软件依赖性，因此可能存在对哪些服务器可以属于某些池的限制虽然动态修改硬件以匹配目标池可能非常困难，但在切换期间动态重新配置软件是可能的。2.2合并系统服务器集群被划分为与执行类型i的作业的服务相关联的概念池，并且中央管理组件从每个池收集实时数据以做出重新分配决策。每个概念池由与每个服务器通信的池管理器管理，群集管理器与每个池通信。该架构如图1所示。节点管理器在能够处理作业的每台服务器上运行，并对其主机进行调整，以允许其切换池。池管理器和调度传入作业，跟踪其池中的服务器，并参与协调服务器到其他池的切换。可通过使用第6节中讨论的现有资源管理系统来完成调度和调度。Cluster Manager根据作业类型将提交的作业分派到相应的池中，并存储有关要在切换策略中使用的到达率的信息。群集管理器从每个池管理器接收信息，80C. Kubicek/Electronic Notes in Theoretical Computer Science 151（2006）77与存储的数据相结合以做出重新分配决策。群集管理器在服务器切换期间充当两个池之间的协调器将作业分派到池是一项微不足道的任务，不需要进行调度，因为作业在每个池管理器中排队和调度，因此队列不太可能在群集管理器中堆积。池管理器之间的分布式排队和调度有助于分散系统上的负载。群集管理器和池管理器一起持续监视系统中的事件，包括作业到达时间以及每种作业类型的排队和处理时间，这允许群集管理器对池之间的服务器切换做出明智的决策池化系统使集群管理器无需保持系统中每台服务器的更新信息，以用于重新配置决策，这大大提高了系统的可扩展性，这在数据中心中至关重要。群集管理器中的策略管理器组件包含做出服务器切换决策的策略。策略管理器可以访问系统收集的所有实时和最新数据，并且可以在任何时候被调用以产生服务器切换决策，当然也可以是无切换。当前加载的策略可以在运行时期间改变，并且策略相关参数可以改变，诸如用于做出服务器切换决策的系统测量的窗口大小。3资源分配启发式为了确定服务器何时应该在概念池之间切换，使用了从随机数学建模导出的资源分配启发式策略[9]。启发式策略计算出接近最优的N个服务器分配到m个池，同时考虑到切换成本。一个最优的切换策略将从排队、到达率和响应三个方面分析系统的当前状态Fig. 1.池化架构C. Kubicek/Electronic Notes in Theoretical Computer Science 151（2006）7781时间，并返回此时可以做出的最佳服务器切换决策。最优策略已被证明是复杂的评估，虽然启发式的政策已被证明是执行良好的最优策略相比，在启发式策略是与中间件一起开发的，并且共享一些相同的假设，特别是假设长时间运行的作业将导致队列形成。启发式还假设一个服务器一次处理一个作业，这对于具有多于一个处理器的服务器可能不是真的，并且假设每个服务器具有相同的处理能力，这在数据中心中不太可能是真的启发式背后的想法是计算任何两个池a和b之间适当定义的成本不平衡Vab。当对应的Vab对于任何一对池具有最大正值时，服务器从池a切换到池b。计算详情见图2。选择Vab的这种特殊形式的原因在[9，6]中解释。该启发式已被用于另一个相关的系统[6]，该系统表明，启发式可以重新分配资源的方式，减少响应时间，作业处理系统在一个实验中，1000个3种不同作业类型的作业被提交到9个服务器的集群中，其中3个服务器池处理这些作业。作业类型的处理时间分别为20、30和40秒，系统收到的总操作负载为70%。负载由三种作业类型的请求组成，其中一种类型占总负载的80%，其他类型各占10%实验进行了两次，一次启用服务器切换，另一次禁用切换，其中每个作业类型静态分配3台服务器。作业类型的到达率在每100次作业提交后改变这确保了服务器可以在池之间切换图3显示了实验的结果，其中可以看到切换时的响应时间比不切换时的响应时间要短。3.1启发式假设为了有效地将启发式应用于数据中心中间件，必须改变启发式的某些方面，但是由于启发式已被证明使切换决策非常接近最优解，因此尽可能少地进行改变将符合我们的利益。在多处理器服务器的环境中，一台服务器一次处理一个作业的假设不成立。如果该策略假设每个服务器一次处理一个作业，而实际上一些服务器同时处理多个作业，则这将导致基于不正确知识的切换决策，降低系统的性能一种解决方案是确保每个服务器一次只运行一个作业，这是一种资源浪费，因此改变了将启发式应用于所获得的系统数据的方式。为了将启发式算法应用于具有多个处理器的服务器，我们为启发式算法提供池中能够处理作业的处理器数量82C. Kubicek/Electronic Notes in Theoretical Computer Science 151（2006）7712345P从← null P到← nullV←0我在PA。甲类及乙类工作的税务局Vab=c b.KCAJj+[λ−μmin（k，j）]-1Bζ甲乙丙B bBBΣ一+[λ−μmin（k−1，j）]1ζ甲乙丙a a一B67891011121314如果Vab> VV← VabP从←a P到← b如果结束，则结束如果V >0从P从切换到池P到end if上述表达式中的参数为：ci池i的持有成本。k是池i中存在的服务器的数量。ji是池i处的队列大小。λi是池i的到达率。1/μi是池i中作业的平均服务时间。1/tlab服务器从池a切换到池b的平均切换时间。K是适当选择的整数，以阻止过多的切换（例如，K=5）图二、资源分配策略的伪代码服务器的数量。当试探法做出切换决定时，将要丢失服务器的池管理器被告知该切换，并以其选择丢失的服务器上的处理器数量进行响应。然后重新计算策略，将图2第5行的ka−1替换为：ka−P，其中P是服务器上要切换的处理器数量。利用启发式算法中的新值，可以计算出在没有给定处理器数量的情况下源池的总持有成本为策略提供处理器数据的另一种方法是集群管理器跟踪服务器内的处理器，并使用该策略来测试最佳交换机，而不必与任何池管理器通信，尽管这种方法在具有许多池管理器的系统中不可扩展。C. Kubicek/Electronic Notes in Theoretical Computer Science 151（2006）7783600500400300200100011点12点13点14点提交时间图三.在具有9台服务器的系统中，有和没有服务器重新分配的情况下，三种不同作业类型的响应时间。群集池和具有多个处理器的服务器，并且不符合使群集管理器不必存储和处理单个服务器数据的原始另一个不成立的假设是所有服务器都具有相同的处理能力。虽然这是不正确的，但该模型测量每个作业的处理时间，并计算给定窗口中的平均值，以确定用于启发式的值。这个平均值的计算可以平衡处理器速度的任何相对差异。4QoS指标和实施提供QoS的数据中心必须指定它实施哪些QoS指标，以及如何指定和测量这些指标。数据中心提供的QoS既被将其应用程序部署为服务的客户感知我们将专注于通过制定资源分配策略为部署其应用程序的客户下面列出了可能感兴趣的两个QoS度量平均响应时间;作业到达和离开系统之间的测量时间，本质上是排队时间和处理时间之和（以秒为单位）。响应时间百分比界限;指定给定百分比的作业必须在给定时间内完成例如，要求可以是95%的响应时间小于5秒。之所以使用平均响应时间，是因为客户或数据中心不可能保证每个作业始终满足给定的时间要求，无需切换40秒30秒20秒40秒30秒20秒与切换响应时间（秒）84C. Kubicek/Electronic Notes in Theoretical Computer Science 151（2006）77更合理的做法是规定一段时间内的平均数使用百分位数是一个更严格的测量，因为大量的作业必须在时间要求内完成，而与平均响应时间测量一样，未能达到目标的较大作业集可以由在目标时间内达到目标的较小作业集补偿。可以使用移动窗口来监视最后x个作业以完成执行。然后可以从窗口中取平均值，也可以取违反百分位界限的作业的百分比如果在计算平均响应时间时，x的值相对较小（例如5个作业），则系统可以对响应时间的变化快速做出反应，然而，如果x的值太小，则平均值可能不够准确，系统无法做出正确的决定。当计算响应时间百分比界限时，可能需要更大的窗口（例如，20个作业），以确保系统不会由于高比例的作业不符合要求而以极端方式做出反应，而实际上只有一个作业需要太长时间才能完成。我们的目标是通过基于QoS目标分配服务器来为Web服务提供响应时间QoS，以及必要时提供其他系统信息。提出了三种QoS模型，前两种模型测量并对观察到的QoS性能做出反应，最后一种模型使用资源分配启发式。我们假设一个QoS策略应用于所有池（池集不能有不同的策略），并且为每个池设置了适当的QoS值，即使它是默认值。4.1QoS策略1：平均响应时间策略第一种策略根据平均测量服务时间和目标响应时间之间的相对差异测量的QoS性能来切换服务器，并将服务器从具有最高比率的池切换到具有最低比率的池测量的响应时间和目标响应时间之间的差异表示为偏差[8]，可以是正的或负的，响应时间使用最后x个作业完成的窗口进行监控，作业窗口的大小可以如前所述变化。可以随时测量偏差并对其采取行动，并且如果存在负偏差，则服务器从具有高正偏差的池（仅当存在时）切换到具有负偏差的池。如在原始资源分配模型中，一次可以切换一台机器，并且如果计算偏差，则通常多台机器将在短时间内到达池中以处理负QoS偏差。只监测的方法不试图分析排队长度，因此只有在响应时间增加后才能观察到服务需求的增加。计算的伪代码如图4所示。4.2QoS策略2：百分位策略Percentile Policy测量每个池中已达到其响应时间目标的作业的百分比，并使服务器从百分比最高的池切换到百分比最低的池。用于通过百分位策略确定服务器切换的伪代码如图5所示。我们假设C. Kubicek/Electronic Notes in Theoretical Computer Science 151（2006）77851234567891011121314151617Rmax<$−∞Rmin<$∞Pmax<$ nullPmin<$ null对于所有池i= 1：M，R←w− T我我我如果Ri RminRmin←RiPmin←i否则，如果Ri>RmaxRmax<$RiPmax<$i如果结束，则结束如果R最小为0从Pmax切换到Pminend if我不是见图4。 平均响应时间策略一个函数，在给定响应时间目标和最近作业响应时间窗口的情况下，计算在响应时间目标内完成的作业的百分比4.3QoS策略3：保持成本权重（HCW）策略一种基于QoS提供服务器的方法涉及选择第3节中描述的动态分配策略的成本值，使得服务器的最终动态分配有利于具有高QoS要求的池，而牺牲具有低QoS要求的池。目标响应时间与平均服务时间的比率可以作为“标准化”目标。标准化的目标越小，就越难达到，因此与之相关的成本也就越大。因此，HCW政策被定义为图2的资源分配启发式，持有成本由下式给出：（一）c=1iμ T我我其中μi是作业类型i的服务速率，Ti是作业类型i的目标响应时间。86C. Kubicek/Electronic Notes in Theoretical Computer Science 151（2006）771234567891011121314151617P ermax<$−∞P ermin<$∞Pmax<$ nullPmin<$ null对于所有池i= 1：M，P eri← InW indow（TarRTi，W ini）如果Peri TarPeriP ermin←（P eri−TarPeri）Pmin← ielse ifP eri> TarPeriP ermax←（P eri−TarPeri）Pmax←i如果结束，则结束如果P ermin0从Pmax切换到Pminend if图五、百分位数策略的伪代码5执行开发了一个原型系统GridSHED（Grid Scheduling Hosting Environment Design）.每个池运行一个资源管理系统（RMS）的实例，该系统对作业的执行进行排队、调度和管理。大多数RMS具有主从架构，其中一台主机充当群集的主主机，并控制许多从主机。系统中的所有组件都是使用Java实现的，之所以选择Java，是因为它具有跨平台的特性，可以满足异构数据中心的要求在整个系统中采用了一种插件结构，它允许使用核心系统组件的不同实现，如Web服务容器、RMS、数据库和组件通信系统，它允许以松散耦合的方式将新的和更新的技术集成到系统中。在用于测试的实现中，选择Java RMI用于分布式组件通信，因为所有组件都在同一基础架构内并受其控制，因此认为没有必要使用Web服务，并且Web服务设计用于跨组织边界的通信当前的实现使用Condor [7]作为RMS，但其他RMS可以包装在GridSHED RMS接口中，并用作排队和调度系统。用户可以将由二进制程序、输入数据和提交脚本组成的作业提交到启用Condor的集群，作业将根据提交脚本中指定的要求在合适的服务器上执行。C. Kubicek/Electronic Notes in Theoretical Computer Science 151（2006）7787也可以提交一批作业，称为集群，它由一个二进制程序和许多不同的输入数据集组成，这导致提交具有不同参数的Condor池有一个中央管理器，可以从池中任何允许的主机提交许多主机和作业。一种名为Class-Ads的匹配机制用于将排队的作业与可用资源进行匹配，并将执行结果发送回提交作业的机器。选择Condor是因为它在其控制下的池之间切换服务器时的灵活性和速度。该系统也被证明是高度可扩展的，尽管所有的匹配都发生在中央管理器上。Condor的一个缺点是，它没有一个可以用来监听特定事件的通知系统，因此从Condor获得的所有数据都是在一个设定的时间间隔内轮询的。Condor是跨平台的，允许基于Java的GridSHED系统在所有支持的Condor平台上运行，无需或只需很少修改。服务器上的处理器数量可以很容易地从Condor中获得，使用完全相同的通过Condor接口，池管理器可以提交作业并查询队列，节点管理器可以重新配置Condor守护进程并收集统计信息。新的Condor主机可以根据需要添加和删除，而Condor center-tral管理器可以探测队列，并连续匹配作业到可用的主机，而不会因添加和删除服务器而中断。节点管理器可以配置在其主机上运行的condor守护进程以中央管理器模式这将为新部署的服务生成一个新的Condor池。见图6。 系统架构组件88C. Kubicek/Electronic Notes in Theoretical Computer Science 151（2006）77要获取状态更新，池管理器会以设定的间隔轮询Condor，并在更改时更新其当前池状态。然后，群集管理器以一定间隔轮询每个池管理器，如果有任何新的状态数据，则将其返回给群集管理器。选择这种轮询方法是因为有时候condor命令会阻塞，如果来自Cluster Manager的轮询直接导致对Condor的轮询，Cluster Manager可能会阻塞，这会降低系统的速度5.1Web服务集成通过集群管理器到系统的Web服务接口是使用Apache Tomcat Web应用程序容器中的Apache Axis [1]托管实现的。所有SOAP消息都发送到Cluster Manager Web服务，尽管消息发送方使用的端点URL似乎是目标服务的端点。每个SOAP消息都由全局处理程序拦截并定向到Cluster Manager Web服务，而用户指定的原始服务目标保存在SOAP标头中。然后，集群管理器从其已部署服务的存储中获取当前处理目标服务的消息的池管理器的地址，然后将消息转发到池管理器。当SOAP消息到达池管理器时，消息被包装在Condor作业中，并提交给Condor进行排队和调度。当Condor执行作业时，一个简单的客户端程序将SOAP消息发送到本地主机上运行的服务（部署过程确保服务安装在池中的每个服务器上）。在完成SOAP消息执行后，请求通过池管理器和集群管理器发送回原始调用程序，这允许为每个作业收集有关服务和总响应时间的数据。Web服务代码存储用于存储可以自动安装在服务器上的Web服务代码。Web服务与任何依赖项一起打包并上传到代码存储。当未部署的服务的SOAP消息到达时，群集管理器会咨询代码存储库以查看该服务是否可用于部署，如果代码存储库对目标服务一无所知，则会向用户返回错误。如果服务代码存在于代码存储中，则群集管理器指示负载最小的池管理器将其服务器之一重新配置为能够处理新部署的Web服务的作业的新池管理器。5.2服务器切换如果需要进行切换，资源分配策略将返回源池和目标池。群集管理器首先向源池管理器发送一条消息，指示它需要重新配置服务器，然后池管理器返回有关选择进行切换的服务器的池管理器将池中的服务器集存储在堆栈数据结构中，以便在池中最长时间的服务器不会被切换出来，这使得长时间运行的作业有机会完成，而不必挂起或检查点。群集管理器可能具有C. Kubicek/Electronic Notes in Theoretical Computer Science 151（2006）7789重新计算交换机决策（如果源池管理器返回一个具有多个处理器的服务器池管理器通过向服务器上的节点管理器发送目标池管理器地址和要安装的新Web服务的名称，完成此操作后，将通知群集管理器，然后向目标池管理器发送重新配置服务器的详细信息，然后将其添加到池中6测试数据为了生成的作业提交模式是接近的模式，收到一个真正的作业提交系统，批调度系统在我们的校园使用进行了研究。结果发现，用户倾向于在一个会话中提交作业，该会话由多个连续的集群作业提交组成，每个集群在数周内提交多达数千个作业，然后用户将在数月内不提交作业单个作业大小范围从5秒到2分钟。这些发现表明，会话是均匀分布的，作业的执行时间也是在所描述的系统中，作业或SOAP消息不能像Condor这样的标准作业提交系统那样作为集群提交。但是，通过在短时间内发送大量SOAP消息，可以以效率较低的方式实现相同的效果，尽管SOAP消息仅包含参数和数据，而不是像作业集群中那样包含二进制文件7实验结果第4节中列出的QoS策略分别用于相同工作负载下的不同实验，以测量在目标响应时间内完成的作业百分比三个Web服务部署在一个8台服务器的集群上，每台服务器包含4个处理器，总共有32个处理器。Web服务进行任意的数学计算以在调用时生成负载，每个服务执行计算的时间在发送给服务的SOAP消息中指定当QoS策略指示时，服务器在每个服务池之间切换，并且实现要求至少一个服务器始终必须在池中。针对这三种QoS策略分别进行了两组实验，一组使用严格的响应时间目标，另一组使用更宽松的目标，以观察在更严格的目标下性能如何变化。在每个实验中，总共有1000个作业通过三个不同的作业流发送作业或SOAP消息以给定的平均到达率提交，该平均到达率根据作业提交模式以编程方式改变，以尝试模拟真实世界的作业提交模式。使用两种不同的到达率确定策略90C. Kubicek/Electronic Notes in Theoretical Computer Science 151（2006）77会话作业提交策略根据第7节中描述的作业提交模式设置到达率。为了在合理的时间范围内测试系统，观察到的作业提交模式被缩小，因此会话之间的时间是几分钟而不是几个月，并且提交会话包括几秒钟的高作业到达率。到达间隔和作业时间的平均值都是使用均匀分布确定的，这似乎与实际用户的观察行为相匹配，实际用户的作业时间、会话之间的时间和提交会话期间的到达率间隔具有上限和下限。然后，流在计算的等待时间内不发送作业，然后在给定的提交时间内以指定的到达率发送作业。分阶段作业提交策略以不同的到达率阶段发送恒定的作业流，以模拟接收持续负载的服务根据由x个作业组成的阶段窗口改变阶段，其中x在配置文件中设置到达间隔由指数分布确定，该指数分布捕获多个独立方的到达模式两种作业类型使用会话作业提交策略提交，一种使用分阶段作业提交策略提交。可以推断，对于接收使用Session策略发送的作业的Web服务，响应时间目标将更难满足，因为与使用Phased策略提交的作业相比，最后一批提交的作业将在更长的队列中等待更这表明，通过会话策略发送的两种作业类型的目标响应时间应高于通过分阶段策略发送的作业。在第一组测试中，QoS目标是宽松的，而在第二组测试中，它们是严格的。通过会话提交策略接收作业的Web服务的目标响应时间被设置为指定平均作业时间的10倍。使用阶段作业提交策略接收作业的Web服务的目标响应时间被设置为平均作业时间的5倍，因为作业自然会更快完成。在第二组实验中，使用会话作业提交策略接收作业的Web服务的目标响应时间被设置为平均作业长度的5倍，使用阶段作业提交策略接收作业的Web服务的目标响应时间在每个测试中，每个作业类型具有相同的到达率模式和作业服务;这些详细信息显示在下表中。图7显示了作业类型1的基于阶段的作业提交特征，图8显示了作业类型2和3的图9显示了实验中每种作业类型的平均运行负载32个处理器的总操作负载为80.12%。相到达率（每秒作业数）作业时间（秒）阶段窗口（作业）10.03418010020.016718010030.0167180100图7.第一次会议。作业类型% 1的分阶段作业提交策略参数C. Kubicek/Electronic Notes in Theoretical Computer Science 151（2006）7791作业类型到达率（每秒作业数）作业时长（秒）提交时间（秒）会话间隔时间（秒）2115060500313060500图8.第八条。作业类型2和3的会话作业提交策略参数作业类型平均到达率（每秒作业数）作业时间（秒）O型密封载荷10.0221804.0420.121501830.12303.6总计：25.64见图9。 平均工作负荷7.1严格的响应时间目标测试结果以下结果是针对更严格的目标响应时间测试的。图10显示了百分位数策略的结果，图11显示了平均响应时间策略的结果，图12显示了QoS启发式策略的结果百分位数策略，作业类型1长度：180秒，目标450作业类型2：150秒，目标750作业类型3：30秒，目标150210-1-2-3测试运行期间的百分比策略、池大小和队列长度40353025201510501801601401201008060402000 200 400 600 8001000已完成作业（一）0 1e+06 2e+06 3e+06 4e+06 5e+06 6e+06 7e+06测试开始（b）第（1）款图10个。具有严格目标的百分比策略测试测量Percentile策略错过了大多数目标，只有在队列上升到一个显著水平后，才为服务于作业类型1的池分配服务器这一政策似乎也导致了许多不必要的切换，如图10（b）中池大小的不断波动所示。基于比率的切换方法也错过了大多数目标，但服务器没有切换多达基于百分比的切换策略，这有利于系统的效率。HCW策略似乎比其他策略执行得更好，并且服务器似乎在队列增加时被分配到服务作业类型1的池。图13显示了与目标到达率匹配的作业的百分比; HCW策略具有最高的匹配作业数，百分位数策略表现较差，而平均响应时间策略表现更差。对于类型1的作业（使用分阶段提交提交的作业类型），HCW策略的性能比其他两个作业类型2（长度：150秒）作业类型3（长度：30秒）作业类型1（长度：180秒）处理器池队列大小目标响应时间和测量响应时间之间的平均相对差处理器池队列大小92C. Kubicek/Electronic Notes in Theoretical Computer Science 151（2006）77处理器池队列大小作业类型2（长度：150秒）作业类型3（长度：30秒）作业类型1（长度：180秒）处理器池队列大小处理器池平均响应时间策略，作业类型1长度：180秒，目标450作业类型2：150秒，目标750作业类型3：30秒，目标1501.510.50-0.5-1-1.5-2-2.5-30 200 400 600 800 1000已完成作业（一）测试运行期间的平均响应时间策略、池大小和队列长度401803516030140120251002080156010405200 00 1e+06 2e+06 3e+06 4e+06 5e+06 6e+06 7e+06测试开始（b）第（1）款见图11。具有严格目标的QoS成本权重启发式，作业类型1长度：180秒目标450 QoS成本权重启发式，测试运行期间的池大小和队列长度作业类型2：150秒目标750作业类型3：30秒目标1504023513025020-11510-2514012010080604020-30 200 400 600 8001000已完成作业（一）0 001e+062e+063e+064e+065e+066 e +06测试开始（b）第（1）款图12个。 持有成本加权策略测试具有严格目标的度量模式政策。从图12（a）中可以看出，作业类型1的测量响应时间和目标响应时间之间的相对差异很少低于-0.5，因此大多数作业都没有其他策略失败的作业那么晚。作业类型百分比政策平均响应时间策略启发式策略1百分之八十六点三百分之五十九点二31.3%26.5%7.1%百分之七十五点六3百分之三十三点八44.8%41.5%平均百分比：42.2%37.0%百分之四十九点五图13岁使其目标到达率与严格目标相匹配的作业百分比作业类型2（长度：150秒）作业类型3（长度：30秒）作业类型1（长度：180秒）目标响应时间和测量响应时间之间的平均相对差目标响应时间和测量响应时间之间的平均相对差处理器池队列大小队列大小C. Kubicek/Electronic Notes in Theoretical Computer Science 151（2006）77937.2宽松的响应时间目标测试结果接下来的几组结果是针对使用更宽松的目标响应时间执行的实验，因此可以预期所有策略的性能都比使用更严格的目标时更好。百分位数政策在目标放宽的情况下表现更好，尽管其中一种工作类型在超过75%的测试时间内未能达到其目标平均响应时间策略的性能优于百分位数策略94C. Kubicek/Electronic Notes in Theoretical Computer Science 151（2006）77作业类型2（长度：150秒）作业类型3（长度：30秒）作业类型1（长度：180秒）处理器池队列大小作业类型2（长度：150秒）作业类型3（长度：30秒）作业类型1（长度：180秒）池队列大小处理器池基于QoS百分比的切换，作业类型1长度：180秒，目标900作业类型2：150秒，目标1500作业类型3：30秒，目标3001.510.50测试运行期间的百分比策略、池大小和队列长度40353025201525020015010010-0.5505-10 200 400 600 8001000已完成作业（一）0 00 1e+06 2e+06 3e+06 4e+06 5e+06 6e+06 7e+06测试开始（b）第（1）款图十四岁放宽目标的百分比政策测试测量平均响应时间策略，作业类型1长度：180秒目标450平均响应时间策略;测试运行期间的池大小和队列长度作业类型2：150秒目标750作业类型2：30秒目标150401.535130池大小队列大小200150250.520 100015-0.510 505-100个0 200 400 600 8001000已完成作业（一）0 1e+06 2e+06 3e+06 4e+06 5e+06 6e+06 7e+06测试开始（b）第（1）款图15. 具有宽松目标的虽然服务器似乎已经以更平滑的方式切换了池，但在服务器开始切换到池之前，队列大小不得不增加。QoS成本权重启发式，作业类型1长度：180秒，目标900作业类型2：150秒，目标1500作业类型2：30秒，目标3001.210.8QoS成本权重启发式;测试运行期间的池大小和队列长度12035301000.60.40.2025802060154010520-0.20 200 400 600 8001000001e+062e+0603e+064e+065e+066e+06已完成作业作业类型2（长度：150秒）作业类型3（长度：30秒）作业类型1（长度：180秒）目标响应时间和测量响应时间之间的平均相对差目标响应时间和测量响应时间之间的平均相对差目标响应时间和测量响应时间之间的平均相对差处理器池处理器池队列大小队列大小队列大小C. Kubicek/Electronic Notes in Theoretical Computer Science 151（2006）7795（一）测试开始（b）第（1）款图十六岁持有成本加权策略测试具有严格目标的度量HCW策略确保所有作业都满足其目标响应时间，并且服务器及时切换以处理传入作业。图17显示了与目标到达率匹配的作业的百分比96C. Kubicek/Electronic Notes in Theoretical Computer Science 151（2006）77作业类型百分比政策平均响应时间策略启发式策略1百分之九十八点九百分之九十八点九百分百240.1%百分之六十七点三百分百3百分之七十五点八百分之八十四点八百分百平均百分比71.6%百分之八十三点七百分百图十七岁达到放宽目标的职位百分比目标响应时间宽松。这一次，百分位数策略是最差的，这似乎表明百分位数策略在更严格的响应时间目标下表现得更好。8结论我们已经展示了一个随机的资源分配模型可以应用到一个Web服务托管环境，其中包括QoS的作业响应时间。比较了不同的服务质量方法，并证明了基于响应时间目标的随机模型的成本设置方法是最好的方法。实验结果表明，与平均响应时间和百分位数策略相比，成本加权策略能够更有效地分配服务器，以满足需求和响应时间目标。平均响应时间