CN108053026B - 一种移动应用后台请求自适应调度算法 - Google Patents

一种移动应用后台请求自适应调度算法 Download PDF

Info

Publication number
CN108053026B
CN108053026B CN201711299377.1A CN201711299377A CN108053026B CN 108053026 B CN108053026 B CN 108053026B CN 201711299377 A CN201711299377 A CN 201711299377A CN 108053026 B CN108053026 B CN 108053026B
Authority
CN
China
Prior art keywords
requests
request
background
hour
minute
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201711299377.1A
Other languages
English (en)
Other versions
CN108053026A (zh
Inventor
陈艳姣
林龙
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Wuhan University WHU
Original Assignee
Wuhan University WHU
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Wuhan University WHU filed Critical Wuhan University WHU
Priority to CN201711299377.1A priority Critical patent/CN108053026B/zh
Publication of CN108053026A publication Critical patent/CN108053026A/zh
Application granted granted Critical
Publication of CN108053026B publication Critical patent/CN108053026B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/04—Architecture, e.g. interconnection topology
    • G06N3/045—Combinations of networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/08—Learning methods

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Computational Linguistics (AREA)
  • Biophysics (AREA)
  • Evolutionary Computation (AREA)
  • General Health & Medical Sciences (AREA)
  • Molecular Biology (AREA)
  • Computing Systems (AREA)
  • Biomedical Technology (AREA)
  • Artificial Intelligence (AREA)
  • Mathematical Physics (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本发明公开了一种移动应用后台请求自适应调度算法，为了解决移动应用程序中后台接收的用户请求负载波动幅度过大的问题，通过采用后台调度机制对延迟容忍的请求和延迟敏感的请求进行后台资源再分配，可以让后台能够提供更充分、更低成本、更少浪费的请求处理能力。本发明实现了云服务器端和用户移动设备端的原型，利用机器学习算法和历史数据预测未来需求，基于预测的未来需求形成最小化成本的优化问题，规划长期的最佳后台处理能力，在此基础上根据延迟容忍度和请求到达时间为用户分配后台处理能力。

Description

一种移动应用后台请求自适应调度算法
技术领域
本发明属于移动互联网领域，尤其涉及基于云端的移动应用的后台请求自适应调度算法。
背景技术
2016年，全球的移动应用下载量约1490亿次，这个数字在2021年将达到3530亿次。为了争取更高的市场份额和利润，应用开发者纷纷寻求以更低的成本保证服务质量的途径和方法。
移动应用程序开发包括两个主要部分：前端设计和后台支持。应用程序的前端是用户在移动设备上可见的和可操作的部分，不同的应用具有不同的前端设计。应用程序的后台支持其前端功能的实现，当用户与应用程序交互时，前端用户请求都需要经由后台处理，因此后台配置是应用开发者所要考虑的基本问题之一。开发人员可以将移动应用的后台搭建在基础设施即服务(Infrastructure-as-a-Service，IaaS)的云端构建后台(如亚马逊的弹性计算云EC2、微软的Azure和谷歌的App Engine)，也可以简单地使用移动后端即服务(Mobile-backend-as-a-Service，MBaaS)。在前一种情况下，开发人员可以有偿使用服务器实例来构建自己的后台，比如一个配置12GiB的RAM和4个vCPU的x1.16xlarge实例每小时收费为6.669美元(美国东部俄亥俄)。在后一种情况下，开发人员可以通过MBaaS供应商提供的按请求数量收费的服务来访问后台，但是此类服务规定了单位时间内的最大请求数，这可能导致超出限制的请求被丢弃。为了保证服务质量，开发人员可以租用更多dyno或更高级的MbaaS，但这意味着需要支付更昂贵的费用以及不必要的资源浪费。
在后台配置中，后台接收的用户请求速率在时刻变化，但是开发人员不能过于频繁地改变后台服务器的配置或者短时间内调整云端的服务器能力。虽然有些服务平台提供自动缩放机制(autoscaling)，但是该机制通过启动或关闭服务器实例来增加或减少后台容量，产生较大的延迟，影响服务质量，并为开发人员带来较大的经济损失和资源浪费。
为了解决云平台面临的动态流量负荷，许多现有工作提出可以对云后台资源的进行动态配置，来迎合部署在云端的移动应用的服务性能要求。许多现有工作也对后台接收的请求进行重新调度，从而使各类请求能够最大程度地满足各种服务等级协议。除此之外，各种针对流量负荷和后台资源需求的预测技术也被相继提出，它们也被用来实现基于云平台的预测性缩放机制。
发明内容
本发明针对现有技术的不足，提出一种移动应用后台请求自适应调度算法。
本发明的技术方案为一种移动应用后台请求自适应调度算法，包含以下步骤：
步骤1：基于机器学习算法预测未来需求，实现方式如下，
依据延时容忍度将请求划分为K类。云端服务器存储每一分钟的每类请求数量作为历史数据。在预测下一小时第i分钟的k类请求的数量
Figure BDA0001500915760000021
时，根据时间相近原则和时间周期性原则，将前一个小时和前两天同一个小时的历史数据作为输入，即
Figure BDA0001500915760000022
利用训练集数据做训练，验证集数据做验证得到机器学习的预测模型。机器学习算法可选择逻辑回归模型(Logistic Regression，LR)，单隐层多层感知器模型(single-hidden-layerMultilayer Perceptron，sMLP)，深度信念网络模型(Deep Belief Networks，DBN)和卷积神经网络模型(Convolutional Neural Networks，CNN)。其中深层学习算法,包括CNN和DBN，能有更好的预测结果，但比LR和sMLP等简单机器学习算法需要更长的训练时间。
步骤2：根据采用步骤1所得未来需求的
Figure BDA0001500915760000023
值，得出当前小时最佳固定后台容量，实现方式如下，
假设当前小时第i分钟的
Figure BDA0001500915760000024
个请求中会被推迟到第j分钟的比例为
Figure BDA0001500915760000025
其中，
Figure BDA0001500915760000026
表示不被推迟的比例。在第j分钟处理的请求表示为Nj，包括之前推迟到第j分钟内和在第j分钟内产生的请求，即
Figure BDA0001500915760000027
为了满足后台容量大于峰值要求，即N≥maxj∈[1，60]Nj。
为了减少请求延迟对用户体验的影响，开发人员根据请求的类型k和延迟分钟数j-1来定义
Figure BDA0001500915760000028
的上限为
Figure BDA0001500915760000029
以此来控制某种类型的请求可以被推迟的数量和时长。最佳后台容量N的值由云端通过解决优化问题
Figure BDA00015009157600000210
得到，其约束条件为
Figure BDA00015009157600000211
Figure BDA00015009157600000212
解决该优化问题可采用现有的经典算法或近似算法。每小时在运行步骤1的机器学习预测算法后更新最优后台容量，该后台容量在一小时内保持不变。
步骤3：根据采用步骤2所得的最佳后台容量进行云端资源调整和实时请求调度：后台首先根据最佳后台容量得到下一个小时所需要的服务器个数，之后在下一个计费小时之前提前启动或关闭服务器，来最优化后台容量；云端服务器将每分钟分成T个时隙，每个时隙总的用户请求上限为N/T；后台根据移动应用的请求的延迟容忍度，为每个请求分配一个初始的处理优先权；延迟敏感的请求将得到较高的优先权，而容忍度高的请求将得到较低的优先权；在每个时隙τ，后台接收的请求状态包括：
新到状态：在时隙τ内新收到的用户请求；
挂起状态：在时隙τ内没有处理而挤压的用户请求；
处理状态：在时隙τ内正在处理的用户请求；
完成状态：在时隙τ内完成处理的用户请求。
在上述的一种移动应用后台请求自适应调度算法，步骤3中，在每个时隙τ的开始阶段，R(τ)个请求处于处理状态，F(τ)个请求刚到达后台，P(τ)个请求正处于挂起状态。如果没有请求被挂起，则N/T-R(τ)个拥有较高优先权的新到请求被处理，而F(τ)+R(τ)-N/T个请求被挂起。如果已有P(τ)个请求正处于挂起状态，N/T-R(τ)个拥有较高优先权的新到和挂起请求被处理，剩余的新到请求将被挂起，一同等待下一个时隙到来。对于拥有相同优先权的请求，先到达后台的请求将优先被处理，而挂起请求的优先权将随着时间增加。在每个时隙之后，θR(τ)个请求处理完成，而(1-θ)R(τ)个请求将继续处于处理状态。
而且，移动应用后台请求自适应调度算法，其特征在于，机器学习模型的参数选择如下，单隐层多层感知器模型的神经元数量为1000，深度信念网络模型有三层隐层，每个隐层包含1000个神经元，卷积神经网络模型包含两个卷基层和一个全连层，每层包含500个神经元。
本发明利用不同用户请求有不同延迟容忍性的特征，通过缓存延迟容忍的用户请求，减少用户请求的峰值，通过预测未来产生的用户请求，规划所需的最佳后台容量，从而降低了移动应用开发者的成本，提高了服务质量和云资源利用率。
附图说明
图1是本发明的架构图。
图2a是本发明实施例的机器学习逻辑回归模型图。
图2b是本发明实施例的机器学习单隐层多层感知器模型图。
图2c是本发明实施例的机器学习深度信念网络模型图。
图2d是本发明实施例的机器学习卷积神经网络模型图。
图3是本发明实施例的机器学习单层模型预测精度对比图。
图4是本发明实施例的机器学习模型的训练时间对比图。
图5是本发明实施例的后台容量需求的对比图。
图6是本发明实施例的后台费用的对比图。
图7是本发明实施例的后台效用的对比图。
图8是本发明实施例的请求未超时的比例图。
具体实施方式
本发明主要根据移动应用用户请求延迟容忍度的不同，提出一种调度用户请求的方法，通过缓存延迟容忍的请求，降低用户请求的波动幅度。本方法利用机器学习方法预测未来请求的数量，从而得出最佳后台容量，然后实时根据每个用户新产生的请求，后台调度处理请求。通过本发明的请求调度算法，应用开发商可以以更低的成本保证服务质量，提高后台资源利用率。
参见图1，实施例以在亚马逊云端服务(Amazon Web Service,AWS)上实现的调度算法(命名为Razor)为例对本发明的流程进行一个具体的阐述，如下：
步骤1：基于机器学习算法预测未来需求。依据延时容忍度将请求划分为K类。云端服务器存储每一分钟的每类请求数量作为历史数据。在预测下一小时第i分钟的k类请求的数量
Figure BDA0001500915760000041
时，根据时间相近原则和时间周期性原则，将前一个小时和前两天同一个小时的历史数据作为输入，即
Figure BDA0001500915760000042
利用训练集数据做训练，验证集数据做验证得到机器学习的预测模型。机器学习算法可选择逻辑回归模型(Logistic Regression，LR)，单隐层多层感知器模型(single-hidden-layer Multilayer Perceptron，sMLP)，深度信念网络模型(Deep Belief Networks，DBN)和卷积神经网络模型(Convolutional Neural Networks，CNN)。其中深层学习算法,包括CNN和DBN，能有更好的预测结果，但比LR和sMLP等简单机器学习算法需要更长的训练时间。
实施例的具体实施过程说明如下：
通过AWS关系数据库服务(Relational Database Service,RDS)建立和操作MySQL数据库，存储历史数据。利用JavaScript程序语言在AWS弹性计算云(Elastic ComputeCloud,EC2)上构建服务器，进行未来请求预测。
机器学习算法预测模型每天训练更新一次，针对每种类型的请求训练一个预测模型，即总共K个预测模型。每个数据的输入为向量
Figure BDA0001500915760000043
输出为
Figure BDA0001500915760000044
即所有用户第i分钟产生的总的k类请求的数量。进行模型训练时，训练集包含50000个历史数据点，验证集包含10000个历史数据点，测试集包含10000个历史数据点。训练好的第k个预测模型在当前日的每个小时对下一个小时内每分钟的k类请求的数量进行预测，即每个模型进行60次预测。由于机器学习算法的输出为不连续的值，将输出
Figure BDA0001500915760000051
离散化为10级，第一级表示请求数量为0～1000，第二级表示请求数量为1001～2000，以此类推，第十级表示请求数量为9000以上。同时，将输入归一化，即
Figure BDA0001500915760000052
在进行训练时，对训练数据进行分批处理，每100个数据为一批。在用第m批数据对已有的训练模型进行再训练时，如果预测准确度提高的程度小于δ％时，则停止训练；如果预测准确度提高的程度大于或等于δ％时，则继续训练，直到所有50000个训练集数据用完为止。
实施例的机器学习模型如图2所示，
LR：如图2a所示，假设输入向量为x，随机变量Y为i的概率为
Figure BDA0001500915760000053
Figure BDA0001500915760000054
其中矩阵W和向量b是根据历史数据通过例如随机梯度下降算法学习得出的模型参数。根据训练模型，一个新的输入x在i取值为最高概率时的结果即预测结果，例如ypred＝argmaxiP(Y＝i|x，W，b)。
sMLP：如图2b所示，假设输入向量为x，隐藏层为h(x)＝Φ(w(1)x+b(1))，其中Φ(·)为非线性函数，计算输出层为y＝softmax(w(2)h(x)+b(2))。模型参数w(1)，b(1)，w(2)，b(2)通过学习历史数据得到的。
DBN：如图2c所示，通过一系列限制型玻尔兹曼机(Restricted BoltzmannMachine，RBM)将输入层进行转化，然后进行逻辑回归。DBN与sMLP的不同点在于其采用了一种新的训练策略，先用无监督的训练通过贪婪算法对RBMs进行预训练，再用监督训练细调所有参数。
CNN：如图2d所示，CNN为MLP的一个变种，利用空间局部性来加快训练过程。在MLP中，邻近层的神经元是完全连接的，而CNN为了减少需要学习的参数，实行本地连接模式。
实施例在建立上述机器学习算法模型时，其参数选择如下，sMLP的隐层由1000个神经元构成，DBN由三个隐层构成，每个隐层由1000个神经元构成，CNN由两个卷基层和一个全连层构成，每个卷积层和全连层均由500个神经元构成。
对于实施例的机器学习算法的评估通过模拟产生的历史数据进行，模拟产生的过程如下。假设有100个用户。首先，生成1440个具有昼夜模式(工作时间需求低，闲时需求高)的值代表一天内(24小时)平均每个用户每分钟(一小时60分钟)的请求数量。然后，在平均值上分别加微量噪音作为每个用户每分钟真实产生的请求数量。最后，将所有用户的请求数量相加得到每分钟总的请求数量。在配有3.6GHz的Inter Core i7-4790CPU和8GB内存的戴尔台式机上运行机器学习算法实施例的预测精确度如图3所示，训练时间如图4所示。其中，简单的机器学习算法LR和sMLP的预测准确度普遍小于深度学习模型DBN和CNN，但是所需的训练时间远小于深度学习模型DBN和CNN。
步骤2：根据采用步骤1所得未来需求的
Figure BDA0001500915760000061
值，得出当前小时最佳固定后台容量。假设当前小时第i分钟的
Figure BDA0001500915760000062
个请求中会被推迟到第j分钟的比例为
Figure BDA0001500915760000063
其中，
Figure BDA0001500915760000064
表示不被推迟的比例。在第j分钟处理的请求表示为Nj，包括之前推迟到第j分钟内和在第j分钟内产生的请求，即
Figure BDA0001500915760000065
为了满足后台容量大于峰值要求，即N≥maxj∈[1，60]Nj。
为了减少请求延迟对用户体验的影响，开发人员根据请求的类型k和延迟分钟数j-1来定义
Figure BDA0001500915760000066
的上限为
Figure BDA0001500915760000067
以此来控制某种类型的请求可以被推迟的数量和时长。最佳后台容量N的值由云端通过解决优化问题
Figure BDA0001500915760000068
得到，其约束条件为
Figure BDA0001500915760000069
Figure BDA00015009157600000610
解决该优化问题可采用现有的经典算法或近似算法。每小时在运行步骤1的机器学习预测算法后更新最优后台容量，该后台容量在一小时内保持不变。
实施例的具体实施方案如下：
一种基于Web的，利用JavaScript程序语言开发的网页应用进行说明。该应用共有6种不同的请求，包括1)静态资源请求、2)网页请求、3)数据库查询、4)数据库插入、5)数据库删除、6)数据库更新。其中1)～2)种被划分为类型1请求，为延迟敏感的请求，3)为类型2请求，4)为类型3请求，5)为类型4请求，6)为类型5请求，为不同延迟容忍的请求。
实施例中对请求延迟的上限定义为，类型1的请最高延时为10秒，类型2的请最高延时为30秒，类型3的请最高延时为60秒，类型4的请最高延时为90秒，类型5的请最高延时为120秒。
对实施例的评估通过仿真数据和真实数据两部分进行，其中仿真数据与机器学习算法的模拟产生的数据相同，得出的最佳后台容量如图5所示，其中基准曲线为满足当前小时在不延迟任何请求情况下的请求量峰值的后台容量。如图6所示，本发明所花费的后台租用费用降低最高可以超过25.4％。后台容量的利用效率如图7所示，仿真结果显示后台容量利用效率在不同测试数据集上最高可以可提高54.9％。
步骤3：根据采用步骤2所得的最佳后台容量进行云端资源调整和实时请求调度。后台首先根据最佳后台容量得到下一个小时所需要的服务器个数，之后在下一个计费小时之前提前启动或关闭服务器，来最优化后台容量。云端服务器将每分钟分成T个时隙，每个时隙总的用户请求上限为N/T。在每个时隙τ，后台接收的请求状态有四种：新到状态、挂起状态、处理状态和完成状态。后台根据移动应用的请求的延迟容忍度，为每个请求分配一个初始的处理优先权。延迟敏感的请求将得到较高的优先权，而容忍度高的请求将得到较低的优先权。在每个时隙τ的开始阶段，R(τ)个请求处于处理状态，F(τ)个请求刚到达后台，P(τ个请求正处于挂起状态。如果没有请求被挂起，则N/T-R(τ)个拥有较高优先权的新到请求被处理，而F(τ)+R(τ)-N/T个请求被挂起。如果已有P(τ)个请求正处于挂起状态，N/T-R(τ)个拥有较高优先权的新到和挂起请求被处理，剩余的新到请求将被挂起，一同等待下一个时隙到来。对于拥有相同优先权的请求，先到达后台的请求将优先被处理，而挂起请求的优先权将随着时间增加。在每个时隙之后，θR(τ)个请求处理完成，而(1-θ)R(τ)个请求将继续处于处理状态。
实施例具体的实施过程说明如下：
根据步骤2中得到的每个小时内需要满足的最佳后台容量，将后台容量和后台实例个数进行转换。在亚马逊的EC2中，开发者仅使用实例50％的处理能力作为整个实例的处理能力，而且需要测试单个实例的单位时间处理请求的速率。当使用的实例的cpu使用率稳定达到50％时，记录每分钟被处理的请求个数，作为单个实例的处理速率。利用此关系得到实例个数与请求处理速率的关系，使用此关系能够将预测最佳后台容量进行计算得到所需要的后台实例个数。
如果下一个小时所需要的最佳实例个数和当前小时的一致，则开发者无须改变当前的实例个数。如果下一个小时所需要的实例个数比当前小时的少或者多，开发者能够根据上述所得的最佳实例个数减少或者增加实例个数。在选择减少实例个数的时候，Razor能够帮助开发者做出最优决策。Razor实时监控每个运行实例的运行状态和收费周期，能够选择最早到达收费周期的实例进行关闭操作。在实现过程中，选择使用小时为后台实例调整周期，并且考虑到实例在开启和关闭的时候有一段延迟，因此在开启或关闭实例时，需要提前一段时间，在实践中使用10分钟提前量。
将每分钟分成T＝60个时隙，每个时隙1秒钟。用户产生新的请求后，直接发送到移动应用的后台。请求调度算法根据请求的延时容忍度为新到来的请求分配处理优先级，在实施例中，静态资源请求和网页请求优先级为10，数据库查询优先级为30，数据库插入优先级为60，数据库删除优先级为90，数据库更新优先级为120。在后台，Razor维护着一个挂起队列，当前秒挂起队列为空，且当前秒处理能力有余时，拥有较高优先权的新到请求被处理，而多出的请求被加入挂起队列。如果已有请求正处于挂起状态，拥有较高优先权的新到和挂起请求被处理，剩余的新到请求将被挂起一同等待下一个时隙到来。对于拥有相同优先权的请求，先到达后台的请求将优先被处理，而挂起请求的优先权将随着时间增加，即优先级每秒钟会减去1。
由于预测结果不能保证绝对和实际情况一致，当实际到达请求高于预测时，为了解决由此导致延时敏感请求的延迟过高问题，Razor使用基于阈值的请求调度机制。在每个时隙1秒钟，如果后台的处理能力被使用殆尽，新到的延时敏感请求不能马上被处理，但为了尽可能减少延迟，在下一个时隙中，为延时敏感请求预留部分的处理能力。如图8所示，请求在延时容忍时间内完成的比例大于95％。
本文中所描述的具体实施例仅仅是对本发明精神作举例说明。本发明所属技术领域的技术人员可以对所描述的具体实施例做各种各样的修改或补充或采用类似的方式替代，但并不会偏离本发明的精神或者超越所附权利要求书所定义的范围。

Claims (2)

1.一种移动应用后台请求自适应调度算法，其特征在于，包含以下步骤：
步骤1：基于机器学习算法预测未来需求，实现方式如下，
依据延时容忍度将请求划分为K类；云端服务器存储每一分钟的每类请求数量作为历史数据；在预测下一小时第i分钟的k类请求的数量
Figure FDA0001500915750000011
时，根据时间相近原则和时间周期性原则，将前一个小时和前两天同一个小时的历史数据作为输入，即
Figure FDA0001500915750000012
利用训练集数据做训练，验证集数据做验证得到机器学习的预测模型；；
步骤2：根据采用步骤1所得未来需求的
Figure FDA0001500915750000013
值，得出当前小时最佳固定后台容量，实现方式如下：定义当前小时第i分钟的
Figure FDA0001500915750000014
个请求中会被推迟到第j分钟的比例为
Figure FDA0001500915750000015
其中，
Figure FDA0001500915750000016
表示不被推迟的比例；在第j分钟处理的请求表示为Nj，包括之前推迟到第j分钟内和在第j分钟内产生的请求，即
Figure FDA0001500915750000017
为了满足后台容量大于峰值要求，即N≥maxj∈[1，60]Nj；；根据请求的类型k和延迟分钟数j-1来定义
Figure FDA0001500915750000018
的上限为
Figure FDA0001500915750000019
以此来控制某种类型的请求可以被推迟的数量和时长；最佳后台容量N的值由云端通过解决优化问题
Figure FDA00015009157500000110
得到，其约束条件为N≥maxj∈[1.60]N，
Figure FDA00015009157500000111
Figure FDA00015009157500000112
步骤3：根据采用步骤2所得的最佳后台容量进行云端资源调整和实时请求调度：后台首先根据最佳后台容量得到下一个小时所需要的服务器个数，之后在下一个计费小时之前提前启动或关闭服务器，来最优化后台容量；云端服务器将每分钟分成T个时隙，每个时隙总的用户请求上限为N/T；后台根据移动应用的请求的延迟容忍度，为每个请求分配一个初始的处理优先权；延迟敏感的请求将得到较高的优先权，而容忍度高的请求将得到较低的优先权；在每个时隙τ，后台接收的请求状态包括：
新到状态：在时隙τ内新收到的用户请求；
挂起状态：在时隙τ内没有处理而挤压的用户请求；
处理状态：在时隙τ内正在处理的用户请求；
完成状态：在时隙τ内完成处理的用户请求。
2.根据权利要求1所述的一种移动应用后台请求自适应调度算法，其特征在于，步骤3中，定义在每个时隙τ的开始阶段，R(τ)个请求处于处理状态，F(τ)个请求刚到达后台，P(τ)个请求正处于挂起状态；如果没有请求被挂起，则N/T-R(τ)个拥有较高优先权的新到请求被处理，而F(τ)+R(τ)-N/T个请求被挂起；如果已有P(τ)个请求正处于挂起状态，N/T-R(τ)个拥有较高优先权的新到和挂起请求被处理，剩余的新到请求将被挂起，一同等待下一个时隙到来；对于拥有相同优先权的请求，先到达后台的请求将优先被处理，而挂起请求的优先权将随着时间增加；在每个时隙之后，θR(τ)个请求处理完成，而(1-θ)R(τ)个请求将继续处于处理状态。
CN201711299377.1A 2017-12-08 2017-12-08 一种移动应用后台请求自适应调度算法 Active CN108053026B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201711299377.1A CN108053026B (zh) 2017-12-08 2017-12-08 一种移动应用后台请求自适应调度算法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201711299377.1A CN108053026B (zh) 2017-12-08 2017-12-08 一种移动应用后台请求自适应调度算法

Publications (2)

Publication Number Publication Date
CN108053026A CN108053026A (zh) 2018-05-18
CN108053026B true CN108053026B (zh) 2021-06-15

Family

ID=62123865

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201711299377.1A Active CN108053026B (zh) 2017-12-08 2017-12-08 一种移动应用后台请求自适应调度算法

Country Status (1)

Country Link
CN (1) CN108053026B (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110048886B (zh) * 2019-04-12 2020-05-12 武汉大学 一种大数据分析任务的高效云配置选择算法
CN116450356B (zh) * 2023-04-21 2024-02-02 珠海创投港珠澳大桥珠海口岸运营管理有限公司 一种基于云管控的跨境物流管理方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1956412A (zh) * 2005-10-28 2007-05-02 上海交通大学 对集成服务模型进行接纳控制的方法
CN106453608A (zh) * 2016-11-09 2017-02-22 武汉大学 一种基于云端的移动应用的后台请求自适应调度算法

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2248387A4 (en) * 2008-02-27 2011-09-28 Powerwave Cognition Inc METHODS AND SYSTEMS FOR MOBILE INTERNET, BROADBAND, ROULEABLE
EP3015981B1 (en) * 2014-10-31 2018-07-25 Khalifa University of Science, Technology and Research Networked resource provisioning system

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1956412A (zh) * 2005-10-28 2007-05-02 上海交通大学 对集成服务模型进行接纳控制的方法
CN106453608A (zh) * 2016-11-09 2017-02-22 武汉大学 一种基于云端的移动应用的后台请求自适应调度算法

Also Published As

Publication number Publication date
CN108053026A (zh) 2018-05-18

Similar Documents

Publication Publication Date Title
US20200293838A1 (en) Scheduling computation graphs using neural networks
CN108958916B (zh) 一种移动边缘环境下工作流卸载优化方法
CN111274036B (zh) 一种基于速度预测的深度学习任务的调度方法
CN108021451B (zh) 一种雾计算环境下的自适应容器迁移方法
CN111835827A (zh) 物联网边缘计算任务卸载方法及系统
CN106453608B (zh) 一种基于云端的移动应用的后台请求自适应调度算法
US20240185147A1 (en) Optimizing engagement of transportation providers
CN113989561A (zh) 基于异步联邦学习的参数聚合更新方法、设备及系统
CN108053026B (zh) 一种移动应用后台请求自适应调度算法
CN111124671B (zh) 批推理动态等待方法、服务器和计算机可读存储介质
CN113822456A (zh) 一种云雾混构环境下基于深度强化学习的服务组合优化部署方法
CN109710372B (zh) 一种基于猫头鹰搜索算法的计算密集型云工作流调度方法
Kapur A workload balanced approach for resource scheduling in cloud computing
CN116069512B (zh) 一种基于强化学习的Serverless高效资源分配方法及系统
CN114546608A (zh) 一种基于边缘计算的任务调度方法
Uma et al. Optimized intellectual resource scheduling using deep reinforcement Q‐learning in cloud computing
CN113485833B (zh) 资源预测方法和装置
CN113422795A (zh) 一种基于深度强化学习的车载边缘任务集中调度与资源分配联合优化方法
Tang et al. Multi-user layer-aware online container migration in edge-assisted vehicular networks
Tang et al. Edge computing energy-efficient resource scheduling based on deep reinforcement learning and imitation learning
EP3627349B1 (en) Re-computing pre-computed search results
CN113747504A (zh) 多接入边缘计算联合任务卸载和资源分配的方法及系统
Lu et al. RLPTO: A reinforcement learning-based performance-time optimized task and resource scheduling mechanism for distributed machine learning
CN114003121B (zh) 数据中心服务器能效优化方法与装置、电子设备及存储介质
CN117472167B (zh) 服务器能耗的调节方法、装置、计算机设备及存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant