Web调度系统（精选六篇）
Web调度系统 篇1
随着医药企业竞争的加剧和现代信息技术的广泛应用, 物流在医药企业竞争中发挥着越来越重要的作用, 被广泛地认为是医药企业除了在降低物资消耗, 提高劳动生产率以外的又一个可以增加利润的方式[1]。药品物流作为医药企业第三利润源的重要组成部分, 正在受到日益广泛的重视, 并面临着前所未有的发展机遇。但由于我国物流产业发展较晚, 整体水平有待提高, 特别是一些中小医药企业还停留在人工劳动阶段, 效率低, 由于信息化、智能化水平低造成的利润流失比较严重[2]。
1 药品物流系统的总体设计
本文构建了一个基于Web的药品物流系统, 药品物流系统主要有两大模块组成:药品管理模块和车辆调度模块。药品管理模块又分为药品基本信息模块和客户管理模块。药品基本信息模块的主要功能是药品的基本信息的管理, 比如药品的编码、规格、重量和容量等信息管理;客户管理模块的主要功能是对客户名称、客户编号、联系方式等信息的管理。车辆调度模块又分为数据录入模块、优化计算模块和结果显示模块。录入模块包括基本信息录入模块和拓扑关系录入模块;优化计算模块包优化车辆、优化路径和优化时间等模块;结果显示模块包括窗体显示、模拟显示和制作派车单模块。系统组成如图1所示:
2 药品物流系统车辆调度优化模块的原理、结构与功能
2.1 调度优化原理
调度优化模块处理过程如下:首先对实际调度问题的约束条件和目标进行抽象, 建立问题的数学模型, 数学模型处理三方面的优化问题, 车辆优化、时间优化和路径优化[3]。进行路径优化时, 利用算法具有选择功能, 即根据问题规模不同, 选择的算法不同, 算法机制中设定规模参数, 规模小于参数N时, 默认选择精确算法;规模大于N且小于M时、默认选用启发式算法;规模大于M时, 默认选用智能算法。如果对默认值不满意, 可以手动方式选择优化算法或者修改系统设定的参数重新选择方案。然后结合时间限制条件, 求解出优化路径, 同时也确定了配送车辆数据和时间数据, 把车辆、路径和时间这三部分数据带入多目标转化的单目标费用函数, 计算出费用。这个方案不能保证最佳, 但应是一个“可行方案”。如果方案不满意, 则重新选择算法, 直至找到满意的方案。如果有多个适合求解的算法均制定出“满意方案”, 则从它们中择优输出。目前对于优化路径算法大致分为三类:精确解法可求得最优解, 利用动态规划法, 分支定界法解决小规模的问题;传统的启发式算法在求解过程中可减少搜寻的次数, 所以是一种容易且快速求解规模大约束条件多的NP问题的算法, 这里的插入法整合了最邻近法和节省法技术, 能够求解适当规模的问题;智能算法具有自我调节功能[4], 适合快速收敛于全局最优解的大规模问题, 利用免疫算法来求解特大规模问题。
2.2 调度优化的结构描述
调度优化模块由数据录入部分、优化计算部分和结果显示三个部分构成。
数据录入部分:稳定的数据如道路的拓扑关系、车辆属性、与道路相关信息和货物属性存入到数据库中。还有一些默认参数初始化时设定完成, 如所有需求客户设置为问题规模, 以参数形式参与算法的选择。经常变动的订单信息存入临时表, 订单信息是每天都要录入的, 而稳定数据一次录入多次使用, 以免重复录入, 提高了效率。
中间的数据处理部分:从数据录入模块录入变动的数据存入临时表或者设置为参数, 如约束因素和问题规模等传输到选择方案, 以此来选择出算法, 从数据录入模块输入的稳定数据放入数据库, 优化计算时, 取一些相关的数据才能计算出优化结果。
数据显示部分:通过后台处理逻辑得到优化方案, 传输到前台显示部分, 显示方式包括窗体报表显示和电子地图模拟显示, 把显示的满意方案送到派车单模块, 不满意的部分送到选择方案模块。调度优化结构如图2所示。
2.3 调度优化功能描述
数据录入部分:能够提供数据处理部分优化计算时所用到的数据。选择方案时提供需求客户数量作为问题规模, 客户需求的时间窗数据作为问题的约束条件;优化车辆时提供客户需求载荷量信息作为满载问题转化为非满载问题, 非满载部分设置为需求量参与路径优化算法;优化路径时提供道路的基本费率和基本费率递减调节系数计算路卡卡费, 提供百公里平均耗油量数据和行驶里程计算耗油费用;优化时间时提供客户需求的时间窗数据计算惩罚费用。
中间数据处理部分:从数据录入模块中取到客户的需求量和时间限制作为车辆路径问题的约束限制, 取到的客户点作为问题的规模, 选择方案根据规模和约束因素选取默认的路径算法, 优化算法从数据库和输入的参数取到相关的信息, 计算出车辆路径问题的三个优化目标作为参数输入到费用函数加权计算最小费用。
数据显示部分:最小费用所对应的方案为优化的方案, 默认选择模拟显示方式, 将优化路径通过每辆车所访问的客户点模拟出来, 以路网的形式展现给使用者。也可以用手动方式转到窗体报表方式显示, 如果优化的结果不满意重新选取算法再次计算方案, 满意后制作派车单。
3 结语
基于Web的药品物流系统在调度优化的过程中采用了算法选择功能, 同时结合实际情况对车辆路径问题进行了分析设计, 能够实现药品在最短的路径进行流通, 有助于以较低的成本提高药品物流配送的效率, 最大程度的提高医药流通企业的利润。
摘要：本文通过对车辆路径问题的研究, 按照软件工程的思想, 对药品物流系统调度优化模块进行了详细的设计和功能描述, 实现了药品物流费用的降低, 提高了医药企业的利润和信息化水平。
关键词：调度优化,车辆路径问题,路径优化
参考文献
[1]张敏, 黄中鼎.物流运输管理.经济管理, 2004, 7:1-12
[2]西泽修.现代物流业对于转变经济发展方式推动产业结构调整具有重要作用.大力发展现代物流业.经济日报, 2009, 13 (1) :1-8
[3]刘云忠, 宣慧玉.车辆路径问题的模型及算法研究综述.管理工程学报, 2005, 1 (19) :124-125
Web调度系统 篇2
1 Web的含义
Web的意思实际是蜘蛛网和网, 现在被普遍译为网络、互联网等技术领域。其表现为超文本、超媒体、超文本传输协议三种形式。
2 电网调度自动化系统
2.1 构成电网调度自动化系统的子系统
构成电网调度自动化系统的子系统共分为四项:第一, 信息采集和命令执行子系统, 这项系统是把远动终端设置在变电站及发电站之中, 以便其与主站之间相互结合完成四遥功能的实现。第二, 信息传输子系统, 其又按制式通道的区别分为两种传输系统, 一种是模拟式的, 另一种是数字式的。第三, 信息收集、处理和控制子系统, 收集每个发电站和变电站的实时信息, 通过对信息进行全面的分析, 使调度员及时有效的了解分析与处理的结果, 从而达到对于整个电网的监控。第四, 人机联系子系统, 通过电动自动化的辅助作用, 调度员能够及时、有效的掌握到整体电力系统运行状态的实时信息, 根据信息反映出的状况制定方案与措施, 控制整个电力系统的安全运行, 从而提高电力系统运行过程中的安全性及效益性。
2.2 电网调度自动化系统的基本功能
电力系统中各个监控与调度自动化的硬件与软件共同组成了电网调动自动化系统。其主要基本功能分为:变电站自动化, 在电力系统中变电站是其组成的重要一部分, 电网调度自动化得以完善, 主要建立在变电站实现综合自动化的基础上;配电网管理系统, 通过监管从变电到配电再到用电的整个全过程, 实现全方位综合自动化系统;能量管理系统, 是电力系统监控和控制的硬件与软件的总称。
3 电网调度自动化系统的发展现状及存在的问题
随着电网调度自动化系统的不断发展, 其取得的效果十分显著。通过对电网调度自动化系统的现状及发展方向的研究, 总结了其存在的问题。
3.1 电网通信
微波、载波、无线扩频和光纤等通道类型是实现电网调度自动化系统的“四遥”功能, 其光纤和微波通道既有实现“四遥”功能的优势, 还能实现遥视的功能。但是, 有其优势的同时又存在着造价高和维护量大的缺点。主要通道光纤和其辅助作用的通道载波、无线扩频是现代电网调度自端动化系统的多种综合通道配置。然而, 这种通道配置对电网调度自动化系统整体的性能很大程度制约了不良影响, 建立光纤环网将是电网调度自动化系统发展的必然趋向。所以, 为通信系统在电网调度自动化系统中更安稳的运行提供有力的保障, 需要在人员上配备拥有专业技术的人员, 在设备上应选择具有高性能的设备, 在实施方案上做到严格按照综合全部的因素制定科学方案等。
3.2 主站系统
电网调度自动化的主站系统开放性不足, 其按常理应该能同时满足上级局SCADA系统、负荷管理和预测系统等部分的信息完成实时的共享, 但由于功能单一和开放性不足的现代电网调度自主化的主站系统, 与其他系统无法进行实时的数据共享。应以全面达到“四遥”为电网调度自动化系统的目标。“遥视”功能的实现随着电网调度自动化系统水平的升高和变电站无人职守的需求显得尤为重要。但是, 根据目前实际情况来看, 还无法做到这点, 所以应着重考虑实现这一要求。另外, 通过运用双网络结构在主站系统设备的建设, 可以使系统的可靠性得到有效的提高, 并能减轻网络负荷。为提高整个电网调度自动化系统处理数据的能力与速度, 应把高性能的服务器设置到主站系统里。
3.3 远程终端机RTU
对远程信息更好的得到接受和发送, 应在变电站改造过程中装配远动屏;运用交流采样方式的测量系统, 为快速提高采样的精确度提供便利条件, 并有效减小采样环节的差错。为预防受后台监控机的控制, 要选用具有接受和发送独立远动信息功能的微机综合自动化系统的产品。在变电站自动化子系统中, 应选用有载调压主变功能的;不具有调容功能的电容器, 也就没办法充分利用系统调节容量, 应选用可调容式电容器, 实现对电网的无功补偿;只有选用功能完备的变电所综合自动化系统才能完成对主变有载调压和调容的远东操作。
4 Web技术在电网调度自动化系统中的设计方案
4.1 电网调度自动化系统功能上的需求
电网调度自动化系统的主要职责表现为:完成安全监视与数据采集的职责、电力电容器的投切、实现负荷控制的职责、实时信息共享的职责。SCADA功能、PAS功能、DTS功能这三大功能就是电网调度自动化系统的主要功能。通过数据采集、数据库管理、数据处理、人机会话、遥控遥调操作、报表处理与模拟屏和大屏幕投影接口等功能的作用下实现SCADA的功能;PAS功能要切合供电局的实际状况运用其中的部分功能即可, 状态评估、调度员潮流计算、拓扑分析、负荷预测、静态安全分析、短路电流计算等都是其主要功能;调度员的培训、运行方式的研究和反事故的演习这三项是DTS主要功能表现。依据供电局实际情况, 全面实现SCADA功能, 并选择部分PAS功能的实现, 充裕的经济能力下可以实现DTS功能。运用发展性思维看待系统功能拓展的可能性, 系统总体应按照实现全部功能的需求来设计, 要留有充足的功能模块接口方便以后功能的扩展和系统升级, 并存好相关的说明文档, 以保障系统的开放性。
4.2 系统整体结构的方案
微机保护、原始数据采集、事故记录及故障录波、数据处理与记录等功能主要由信息采集和命令执行子系统完成的。在调度中心和变电站之间信息传输子系统建立质量可靠的通信通道, 并在其相互间传输信息。信息的采集与分析和控制子系统通过各变电站传来的信息实施处理, 完成实时信息处理、历史信息统计、事故处理、人机界面和上级调度间的数据通信相互间的数据连接。数据库服务器、Web服务器、调度平台和维护平台共同组成主站系统。数据和信息的共享, 是通过上位机子系统、前置机子系统和企业MIS系统以交换式快速100M运用以太网构成Internet而完成的。
5 结语
电网调度自动化系统从电话通讯调度到现在以计算机为主的综合自动化设备监控的转型, 是适应现代信息化科技的发展方向的, 也使其得到更科学的数据, 不断的使电力网络化得到完善。
参考文献
[1]唐凯.电网调动自动化系统可靠性的研究[J].中国科技纵横, 2012 (19) .
Web调度系统 篇3
随着Internet迅速发展, 信息化已经深入到各行各业。随着信息化的深入普及, 越来越多的Web服务器需要面对更高的访问量和数据量, 同时对系统提出了更高的要求, 大多数都要求系统24小时工作。然而随着访问人数的增加, 服务器反应能力下降, 会造成客户端事务处理超时。在单个服务器的情况下解决这类问题通常是升级主机, 但是单个主机的能力总是有限的, 当有大量请求的情况下可能使用更好的主机也无法解决问题, 而且购买高性能主机的成本是非常昂贵的。服务器集群由于其成本低和可扩展性好作为解决这类问题的有效方案, 选择好的负载均衡算法成为保证服务质量的关键。本文在研究现有的负载均衡调度算法的基础上, 针对Web服务器集群负载均衡的特性, 在一致性哈希算法[1]和基于临界加速递减动态负载均衡算法[2]的基础上, 提出了基于临界加速递减的一致性哈希负载均衡算法 (CHDMC) , 并根据Web服务器负载均衡的特性对算法进行优化和改进, 最后通过实验验证了该算法的有效性。
1 国内外研究现状
Web服务器集群是通过高速网络将相互独立的一组服务器互相链接起来, 对于访问者来说这一组服务器是一个单一的整体, 保证Web服务器集群效率的关键是Web服务器负载均衡调度算法。
目前经典的负载均衡算法有轮循算法、加权轮循算法、随机分配算法方面和动态反馈调度等[3,4,5]。在负载均衡调度算法改进的研究方面, 文献[6]结合系统资源类型和服务器权重系数, 依据服务器加权负载标准差, 进行真实服务器负载状况分析, 动态调整服务器权重系数, 对改进的最小链接算法进行调度, 实现负载均衡;文献[7]结合静态权重轮循算法和动态负载均衡, 提出一种自适应的综合动态负载均衡算法, 解决分布式文件系统的负载均衡;文献[8]提出了一个双层分配器负载平衡模型, 解决Web服务器负载均衡问题;文献[9]通过分析已有的负载均衡算法, 提出一种改进的动态反馈负载均衡算法, 调度器定时接收集群中每台服务器上报的性能参数, 计算每台服务器当前负载比例值, 根据该值计算每台服务器的分发权重, 以合理分配用户请求。
当服务器请求增加到一定量时, 响应时间的变化会出现抖动现象, 表明服务器即将进入饱和状态, 我们定义出现抖动现象到负载饱和状态这一负载区为临界区。临界加速递减MDC (Multiplicative Decrease in Critical area) 负载分配算法是通过增加进入临界区负载率, 防止服务器进入负载饱和的策略。为了保证负载均衡器具有较高的转发效率, 分配器不对每个请求任务本身的负荷进行分析, 而是动态监测请求任务被分配后对各个服务器工作负荷造成的影响;通过反馈服务器实际的工作负载状态, 再结合设定的服务器固有处理能力, 负载均衡器计算出每台服务器当前的负载率以及平均负载率。根据服务器应分配与之能力相匹配的负载的原则, 在后续的分配中, 对高于平均负载率的服务器减少分配给它的请求任务数量, 对低于平均负载率的服务器增加分配给它的请求任务数量, 以达到负载均衡的目标。
然而, Web请求任务对系统资源的消耗不仅与链接数量有关, 还与链接类型、所需资源类型、请求内容等多方面因素有关, 动态网页链接请求要涉及到数据库的并发访问和对数据库响应结果的综合处理, 其链接响应时间就远比读取一个静态文件或者HTML页面长, 这就要求负载均衡器需要实时地了解后端服务器节点的负载情况, 目前动态负载分配算法都是在负载均衡器分配之前分析服务器的负载状况进行负载调度, 这样会影响负载均衡器的转发效率, 从而会导致服务器集群总体效率下降。为此, 本文提出一种结合一致性哈希算法和临界加速递减算法的动态负载均衡算法, 该算法结合静态负载分配算法和动态负载分配算法的优点, 在Web服务器集群负载均衡方面有很好的效果。
2 本文算法分析
2.1 本文算法的设计思想
为了尽可能地提高Web服务器集群的服务质量和请求反应速度, 要求负载分配算法能够确保用户请求均衡分配的同时不影响请求分配速度。本文算法结合了一致性哈希负载分配算法和临界因子加速递减动态请求负载分配算法的优点, 做到“能者多劳, 均衡分配”的同时也不影响负载均衡器的分配效率, 算法流程如图1所示。
本文算法的设计思想是:一个任务请求到来时, 先通过加权一致性哈希算法计算出该任务所分配的服务器节点, 然后判断分配的服务器节点的负载率是否超过集群的平均负载率, 如果没有超过则把该请求分配给服务器节点, 如果超过则执行负载转移模块, 将该请求分配到集群中负载率最小的服务器节点, 当请求返回时负载衡器通过临界因子加速递减动态请求负载分配算法计算该服务器节点的负载率和集群的平均负载率。
2.2 加权一致性哈希算法中哈希函数的选取与实现
一致性哈希算法的基本算法本思想是, 采用哈希函数计算出服务器节点的哈希值, 然后将其放在一个0～232的环上, 再根据每个请求的关键字的值 (这个值可以是请求的IP地址、URL等) , 通过哈希函数将该请求的关键字的值映射到环上某个点, 如果该点没有映射到服务器上, 那么顺时针查找, 直到第一次找到有映射服务器的节点, 该节点就是确定的目标节点, 如果超过了232仍然找不到节点, 则命中第一个机器节点。如图2所示, 比如H (K) 的值介于A～B之间, 那么命中的机器节点应该是B节点。
采用基本一致性哈希算法进行后端服务器节点映射在实际应用中具有一定的局限性。因为服务器节点在环上的分配完全是随机产生的, 所以存在一定的概率造成服务器节点的分配不均衡, 使得整个集群负载不均衡。
针对以上问题本文采用了虚拟节点分配法优化系统性能。本文优化算法中, 虚拟节点的总数为N, 真实服务器映射的基本单位Ω, 则服务器虚拟节点的总数是Q=N·Ω (log (N) ) [10], 分a配给单个服务器的虚拟节点的个数为Q (i) =i·Q (其中aAi是第i个服务器节点的资源数, A=∑ai) , 然后采用一致性哈希的原则, 以虚拟服务器节点作为分配的基本单位, 沿着环为每个真实服务器节点分配虚拟节点。
本文采用的是MD5函数作为地址映射函数, 服务器虚拟节点的哈希值由MD5函数通过计算得到, 并且完成寻址, 服务器虚拟节点加入到环上的伪代码如下:
上面的流程大概可以这样归纳:node.Getn Copies得到每个真实服务器节点的虚拟节点个数, 四个虚拟节点为一组, 以getKey For Node方法得到这组虚拟节点的关键字, Md5对关键字编码后, 每个虚拟节点哈希值对应Md5码16个字节中的4个, 组成一个long型数值, 该值作为这个虚拟节点在环中的惟一Key。本算法中哈希函数的索引值为4字节, 这样虚拟节点的总数为232。
有了服务器虚拟节点在环上的分布后, 查找服务器节点的方法和基本一致性哈希算法类似, 当一个HTTP请求到来时, 通过Md5算法将HTTP请求的关键字映射到环上某个点, 如果该点没有映射到服务器上, 那么顺时针查找, 直到第一次找到有映射服务器的虚拟节点, 该节点就是确定的目标节点, 如果超过了232仍然找不到节点, 则命中第一个虚拟节点, 最后通过虚拟节点映射真实的服务器节点。
2.3 动态均衡服务器负载能力的表示及测定
(1) 固有负载能力的测定
确定动态负载均衡算法, 服务器负载能力的测试是关键, 本文是利用Apache JMeter对服务器负载进行检测, 测试配置:线程数1 500个, 时间间隔10 s, 循环次数5次, 结果如图3所示。
图3中横坐标表示发送请求个数, 纵坐标“实线”表示请求成功个数, “虚线”表示服务器响应时间 (以毫秒为单位) , 从图3中可以看出当请求达到5 500个左右时, 服务器请求成功率会突然降低, 并且持续一段时间, 这是系统软件为防止死机而采取的一种措施, 也称“拒绝服务”或“假死”现象, “假死”会对服务器的性能产生严重影响, 因此必须避免这种现象发生。我们认为出现假死时服务器已经处于饱和状态, 从上图可以看出这台服务器“假死”时服务器的响应时间为3 250 ms, 记个时间为Tmax, 当服务器的响应时间超过Tmax, 则服务器的可用资源为零;从上图可以看出服务器的最小响应时间为58 ms, 记这个时间为Tbas, Tbas就是系统维持运转的基本负载;从图3还可以明显看出当请求达到一定量时服务器的响应时间会出现“抖动”现象, 出现抖动的临界时间为1 649 ms, 记这个时间为Tcir, 我们定义从临界时间到服务器“假死”的区域为“假死”前的临界区, 这一区间为Tcir～Tmax。
(2) 动态负荷的表示及计算
由于用户请求任务对系统资源的消耗不仅与链接数量有关还与其他因素有关, 实时了解Web服务器集群中后端服务器节点的负载情况是将请求合理分配的前提, 下文给出了动态负荷表示的相关定义和计算。
定义1固有负载能力LoadCapacity (i) , 表示第i个服务器节点的固有资源数。
定义2服务器的当前负载Load (i) , 表示第i个服务器节点当前所使用的资源数。
定义3服务器负载率Resource (i) , 表示第i个服务器节点资源的利用率:
其中n为集群中服务器的个数, 当服务器负载均衡时有:
定义4在系统维持基本负载前也就是响应时间小于Tcri, 该服务器的当前负载可以定义为响应时间的函数, 该函数可以通过建模得出:
定义5递减因子α, 当服务器的响应时间进入临界区间时, 为了避免服务器进入“假死”状态, 我们必须减轻服务器的负载, 为此我们定义服务器负载率增加部分为递减因子α, 加入后服务器负载率的计算公式为:
算式中, 为服务器的临界深度, 由于每台服务器的临界深度不一样, 我们设置参数β来调整其递减的速度 (通常β的值为2) , 有了递减因子就可以主动控制服务器不出现“假死”状态[11]。
负载均衡器的主要作用是通过负载均衡算法转发HTTP请求到后端服务器节点, 服务器节点的负载率的计算是本文算法的关键, 由式 (2) 至式 (4) 可以得出服务器节点负载率计算公式:
由式 (5) 可以看出, 当一个HTTP请求成功返回到负载均衡器时, 我们可以通过请求响应时间t计算该节点的负载率, 为了确保Tbas、T cri和Tmax不受环境的影响, 我们统一由负载均衡器对后端服务器节点测试, 测得每个后端服务器节点的Tbas、T cri和Tmax作为参数事先写入负载均衡器。
计算完服务器节点的负载率后, 我们要计算服务器集群的平均负载率, 根据负载率的计算公式我们可以推导出平均负载率AveraRes的计算公式:
2.4 算法实现
当一个HTTP请求到达负载均衡器时, 负载均衡器首先将该请求加入到负载均衡队列末尾, 当请求队列中该请求前面的请求都已经分配完时, 负载均衡器通过加权一致性哈希算法, 计算出请求的哈希值 (其中请求关键字的值为请求的源IP地址, 可以确保同一个用户的请求能够分配给同一个后端服务器节点) , 找到对应的后端服务器节点, 然后判断在分配的后端服务器节点的负载率是否超过集群的平均负载率, 如果没有超过则将请求分配给该服务器节点, 如果超过了平均负载率, 将该请求分配给服务器集群中负载率最小的后端服务器节点, 负载均衡器记录该请求的转发时间, 以便当该请求返回到负载均衡器时, 通过请求返回时间和请求转发时间的差计算服务器节点的负载率, 负载均衡算法具体实现伪代码如下:
本算法通过改进的加权一致哈希算法分配后端服务器节点, 请求源IP地址最为关键字计算哈希值, 确保同一用户的请求分配到同一个后端服务器节点, 减少了用户会话转移的次数, 通过临界因子加速递减动态请求负载分配算法, 在请求到来时先将请求分配给后端服务器节点, 当请求返回时再通过请求响应时间计算服务器节点的负载率, 保证了后端服务器节点负载均衡的同时提高了请求转发的效率。
3 算法性能测试与结论
为了测试算法的性能, 根据现有的条件, 对所实现的负载均衡算法进行了性能测试。测试环境一台负载均衡器、后端三台真实服务器和一台数据库服务器。集群系统配置如表1所示。
测试环境的网络为高速局域网, 测试工具采用的是Apache Jmeter, 用加权轮询算法 (WRR) 、临界加速递减 (MDC) 与本文所实现的算法性能进行比较。测试请求是用户登录系统操作, 该请求不仅有静态页面, 还有数据库操作, 属于动态请求, 通过Apache Jmeter反馈的数据, 分析了请求的平均响应时间和请求成功数做了测试, 测试结果如图4、图5所示。
从图4可以看出当并发请求大于25 000个时, 本文算法平均响应时间要小于WRR算法和MDC算法, 并且随着并发请求个数的增加本文算法相对其他两种算法优势比较明显。从图5可以看出当并发请求个数不断增加时本文算法的请求成功率明显要比前两种算法高, 其中WRR算法成功率最低。测试结果表明本文算法不管是在请求成功率还是平均响应时间上相对于原有的算法有明显的提升。
4 结语
本文综合一致性哈希调度算法和基于临界加速递减动态负载均衡算法的优点, 结合Web服务器集群的特点, 提出了一种基于加权最小连接数调度的一致性哈希负载均衡算法, 在计算服务器负载率时加入了临界递减因子, 主动防止服务器进入“假死”状态。通过测试表明本文算法在负载均衡性能上有明显的提高, 本算法在Web服务器集群系统中具有非常广泛的应用前景。
参考文献
[1]Karger D, Lehman E, Leighton T, et al.Consistent Hashing and Random Trees:Distributed caching protocols for relieving hot spots on the world wide web[C]//Proceedings of the 29th Annual ACM Symposium on Theory of Computing, EI Paso, Texas:ACM, 1997:654-663.
[2]郭成城, 晏蒲柳.一种异构Web服务器集群动态负载均衡算法[J].计算机学报, 2005, 28 (2) :179-184.
[3]Dias D, Kish W.A scalable and highly available web server[C]//Compcon 96.Technologies for the Information Superhighway Digest of Papers, 1996:85-92.
[4]Cardellini V, Colajanni M, Yu P S.Dynamic load balancing on Webserver systems[J].Internet Computing, IEEE, 1999, 3 (3) :28-39.
[5]Casalicchio E, Tucci S.Static and dynamic scheduling algorithms for scalable Web server farm[C]//Parallel and Distributed Processing, 2001.Proceedings.Ninth Euromicro Workshop on, 2001:369-376.
[6]刘斌, 徐精明, 代素环, 等.基于Linux虚拟服务器的负载均衡算法[J].计算机工程, 2011, 37 (23) :279-287.
[7]张聪萍, 尹建伟.分布式文件系统的动态负载均衡算法[J].小型微型计算机系统, 2011, 32 (7) :1424-1426.
[8]王志晓, 牛强.基于双层分配器的Web服务集群负载平衡解决方案[J].计算机应用, 2006, 26 (2) :307-309.
[9]王春娟, 董丽丽, 贾丽.Web集群系统的负载均衡算法[J].计算机工程, 2010, 36 (2) :102-104.
Web调度系统 篇4
构建Web集群是提高Web服务器系统性能和扩展性的有效办法。在目前已提出的基于客户端、基于DNS、基于前端和基于服务端等多种Web集群结构中,基于前端的集群结构作为最佳方案[1]应用最为广泛,它由一个前端服务器(又称请求分发器或负载均衡器等)和若干台后端服务器组成。前端服务器负责接收客户端的请求,并按一定策略将请求分发到合适的后端服务器,由后端服务器直接为客户端提供服务。前端中使用的调度策略直接影响到集群系统的性能,合理的请求调度策略将决定Web集群的整体性能和扩展性[2]。
HTTP请求通常可以分为静态请求和动态请求,静态请求是对服务器文件系统中文件的请求,而处理动态请求时,服务器运行应用程序实时为每个请求生成回复数据。Yang等[3]建议对于静态请求应该采用基于局部性(Locality)的请求调度策略(如LARD[4]),通过将相同的请求调度到同一个服务节点,来获得很高的缓存命中率;而对于动态请求,由于不能利用内存缓存,所以应当尽量均衡负载。
静态请求产生的负载与所请求文件的大小成正比,所以很容易实现负载均衡。而处理多样化的动态请求所需要的服务器资源差异太大,而且无法预测,现有的各种调度策略都很容易造成负载失衡,影响系统的性能。
本文给出了一种实现简单的基于分类的动态请求调度策略(CBDRSP),不需要估计请求产生的负载,也能很好地在集群后端节点间均衡负载。本文余下部分结构如下:第2节介绍了动态请求调度策略的研究现状;第3节对CBDRSP进行了详细介绍;第4节对性能进行了测试;最后给出了结论。
2动态请求调度策略研究现状
关于动态请求调度策略的文献很少,这是因为相比于静态请求,动态请求的不确定因素太多。处理每一个动态请求所需要的系统资源截然不同,有的需要大量CPU资源、有的需要大量I/O资源,有的同时需要大量CPU资源和I/O资源,所以动态请求不像静态请求(仅需要I/O资源)那样可以被透彻分析,并有针对性地提出优化策略。
已有的研究中,动态请求调度策略大多采用了基于会话关联的方案。BEA提出的轮转(Round-Robin,RR)和会话关联(Session Affinity)相结合的调度策略就是一种基于会话关联的调度策略[5]。用户会话的第一个请求(如票务网站上的用户登录请求)根据RR来调度,而该会话上的所有后续请求根据基于会话关联的方案(Session-Affinity-based Schemes,SAbS)来分发,即同一会话中的所有请求被调度到同一台Web服务器上。基于会话的轮询策略不管请求的内容,不管用户会话的长短,也不考虑会话中每个请求的负载特性,可能会导致严重的负载失衡,如图1所示。
Casalicchio等人将HTTP请求分为四类:静态或轻度动态的Web发布业务、I/O密集型业务、计算密集型业务以及I/O和计算密集型业务。前端对每类业务维护一个调度关系的环形表,以此来均衡所有后端服务器上的多种资源承担的负载,而不至于使服务器上的单一资源(如CPU资源)过载。该方法考虑到了不同请求具有不同的负载特性,但是对负载类型划分的粒度太粗,而且对于如何区分请求属于哪类业务也没有给出很好的方法。
针对上述现有方法的缺点,本文提出了一种实现简单的调度策略,能很好地对动态请求实现负载均衡。
3基于分类的动态请求调度策略
CBDRSP的主要动机是按照产生的负载对请求进行分类,每类请求产生的负载大致相同,这样,只要对每类请求按照RR等比较简单的策略进行调度,就能实现所有请求在后端节点上的负载均衡。所以CBDRSP的关键就是如何在不估算请求产生的负载的情况下,对动态请求进行分类。
一个典型的动态网站有几千甚至几十万个页面,其中很多页面都是由相同的服务器应用程序以不同的输入参数运行出来的结果。对于编写良好的应用程序,这类请求会调用相同的服务器应用程序,而且按照几乎相同的流程执行几乎相同的代码(可能会因为参数不同而执行一些不同的小程序分支),因而具有几乎相同的计算复杂度,执行几乎相同的数据库查询,结果就是产生几乎相同的负载大小。根据以上分析,可以将动态请求按照执行的服务器应用程序进行分类。
最初,动态程序的参数都是直接加在带“?”的URL后,不同的参数之间以“&”进行分隔。如“http://www.eu169.com/photo/index.asp?user=1&page=2”,其中“/place/index.asp”是要执行的服务器应用程序,而“user=1&page=2”则是带的参数。对这种情况,很容易就能根据请求的URL对请求进行分类,只需要截取URL中域名以后至“?”之前的部分进行比较(大部分HTTP请求的GET、POST等操作后面带的URL中并不包含域名,域名在Host属性中指明),相同的就属于同一类请求。
现在的Web服务器软件为了方便记忆和搜索引擎收录,大都提供了URL重写(URL Rewrite)[6]功能,通过某种映射关系,将动态请求的URL变换为看起来更像静态请求URL的形式,如“http://www.eu169.com/photo/index-1-2.html”,也有一些第三方插件提供了这样的功能[7]。经过重写后的URL不能像之前的URL那么直观地进行分类。考虑到除了极少数网站会手动对动态页面进行URL重写设置外,大部分网站都用正则表达式对URL进行批量重写。显然,可以像Web服务器内部处理方式一样,通过正则表达式匹配的方式来还原出动态请求的原始应用程序名。在Web集群的前端中设置与Web服务器配置文件内相同的正则表达式,就能对请求按照改写过的URL进行分类。这可以通过在前端中直接读取并解析Web服务器的配置文件来实现。
将请求分好类后,就能按类来对请求进行调度。如果将每类请求能够均匀地分布到后端节点上,那么就实现了所有请求在集群后端节点上的负载均衡。根据前面的分析,属于同一个类的动态请求的负载大致相同,所以在各后端节点上分配相同数量的请求,就能实现均衡该类请求的负载。我们的实现中采用简单的RR算法来分配同类请求。
这里我们只考虑了同构集群的情况,即所有集群后端节点具有相同的处理能力。对于异构集群,可以很容易地通过为不同服务器赋予不同的权值,然后用加权轮转调度来实现负载的均衡。
4试验测试
我们用LoadRunner[8]对上述CBDRSP进行了量化分析。为了比较,我们实现了会话关联的请求调度策略SARD(Session Affinity Requests Distribution)。Web服务器使用Apache 2.2.3和PHP 5.2.4。Web服务器上有两个PHP页面:1.php和2.php,页面代码都是简单地进行循环计算,通过控制循环的次数,使得1.php在空闲服务器上的执行时间约为0.1s,而2.php的执行时间约为3s。
测试中有两个应用场景,第一个访问10次1.php,第二个访问10次2.php,用户的思考时间都为1s。试验中,我们用三台计算机运行LoadRunner,逐渐增加LoadRunner模拟的用户数,并统计集群系统的吞吐量。测试系统如图2所示,我们采用了三台相同的Web服务器(2.8Ghz CPU,1G内存)来组成同构的Web集群,前端也运行在和Web服务器相同配置的硬件平台上。
测试结果如图3所示,在用户数较少时,系统吞吐量几乎随着用户数的增加而线性增长;用户数增加到一定程度后,吞吐量增长变缓;当用户数达到Lmax(调度策略不同,系统的性能不一样,所以Lmax也不尽相同)后,吞吐量开始随着并发用户数的增加而减小。
由上图中的测试结果可以看出(图中的并发用户数是三个LoadRunner模拟出的用户总数),使用SARD时,由于是按照用户会话来调度的,调度粒度比较粗,在并发用户数远没有达到系统应有的Lmax(根据CBDRSP,系统应有的Lmax至少应该为350)时,由于出现了严重的负载失衡,导致吞吐量的增长开始变缓,并在用户数达到250时达到最大的吞吐量。相比SARD,CBDRSP的最大吞吐量增加了51.9%。随着并发用户数的不断增加,不管使用何种调度策略,所有后端节点最终都过载,使得各种调度策略的吞吐量趋于一致。
5结束语
我们提出了一种专门用于分发动态请求的调度策略CBDRS,它按照URL的模式将动态请求分类,使得属于同一类的请求对服务器产生几乎相同的负载,然后将每类请求按轮转方式分配到后端节点,从而实现了在不估算动态请求负载的前提下实现了负载均衡。测试结果表明在同构集群中,CBDRS的性能相比会话关联的请求调度策略SARD提高了51.9%。
参考文献
[1]Valeria C,Michele C,Philip S Y.Dynamic Load Balancing on Web-Server Systems.IEEE Internet Computing,1999,3(3):28～39
[2] Armando F, Steven D G, Yatin C. Cluster-based scalable network services. ACM SIGOPS Operating Systems Review, 1997, 31(5): 78～91
[3]Wu Y,ShuangQing L,DaiJie C.ALoad Balancing Strategy in Web Cluster System//Proceedings of the Third International Confer-ence on Natural Computation(ICNC2007).2007.809～813
[4]Vivek S P,Mohit A,Gaurov B.Locality-Aware Request Distribution in Cluster-based Network Servers.ACM SIGPLAN No-tices,1998,33(11):205～216
[5]BEA Systems Inc.BEA WebLogic Server10[EB/OL].http://www.bea.com/framework.jsp-CNT=index.htm&FP=/con-tent/products/weblogic/server/,2008.
[6] The Apache Software Foundation. URL Rewriting Guide [EB/OL]. http://httpd.apache.org/docs/2.2/misc/rewriteguide. html, 2008.
[7]Cristian D,Jaimie S.URL Rewriting Using ISAPI-Rewrite[EB/OL].http://www.isapirewrite.com/,2007.
Web调度系统 篇5
安全性评价是一种现代化的管理手段, 是对安全基础工作进行诊断的重要方法。它用现状与标准对比的方法, 评价一个系统或一个企业的安全水平或风险程度, 预知和掌握客观存在的危险因素及其严重程度, 明确预防事故的重点和需要采取的反事故措施。电网调度系统的安全性评价内容包括电网公司的调度运行、运行方式、继电保护、调度自动化、电力通信、综合安全管理 (水库调度) 等专业。
当前我国绝大部分调度部门的安全性评价工作仍然用手工填写Word文档和Excel表格, 并通过Email或传真的方式完成, 这已经不能适应电网调度快速准确的要求。因此本文提出设计一套基于Web技术的电网调度安全性评价管理系统。
2 安全性评价
安全性评价是对系统存在潜在危险进行分析和度量, 即对系统危险程度用安全标准来衡量, 得出系统安全水平的估计。调度系统安全性评价是对电网安全稳定运行水平总体的科学评价, 包括对调度运行管理、继电保护设备及运行管理、通信与调度自动化设备及管理水平的评价, 是实现管理科学化的一种有效方法。电网调度系统通过开展安全性评价工作, 摸清各专业设备和管理水平的安全底数, 为安全管理的正确决策提供重要依据。
3 网络结构及其特点
系统采用B/S 结构, 即用户端浏览器/ Web 服务器/ 数据库服务器组成的三层结构, 网络结构如图1 所示。采用三层结构解决了传统的C/S模式下的一些弊病, 并具有以下优点: (1) 简化客户端工作, 无需像C/S模式那样在上安装应用程序。 (2) 简化系统维护。B/S的所有功能都实现在Web 服务器上, 使升级维护工作量减轻。 (3) 体现三层结构即把功能分层。使应用程序具有伸缩性、复用性和安全性。
4 系统功能模块
电网调度安全性评价系统是以实现调度系统的安全性评价的各项功能为核心的信息管理系统, 它是调度中心信息系统的一个组成部分, 同时它又是一个相对独立的业务系统, 它是集数据交换、查评标准管理、查评报告生成、查评文件管理、整改管理、安评完成情况管理、信息发布为一体的综合信息管理系统。系统总体功能结构图如图2所示。
4.1 数据库管理系统
由于本系统需要传递大量的数据, 同时还会与其他管理系统交换数据. 因此数据库系统具有功能可扩展、标准开放、通用性强的特点. 它能有效管理系统内部所有数据, 同时还可以与外部数据进行交换。
4.2 系统管理子系统
本子系统主要是为用户提供有关系统运行过程中日常维护的管理工具, 包括组织结构管理、用户管理、查评周期管理等功能. 通过这些功能, 系统可以对网、省调所属地区调度中心进行管理; 对系统用户的信息和权限进行管理; 并且可以启动新的安评周期并为其设定名称和编号。
4.3 业务系统及模块
(1) 信息发布子系统。
该子系统包括电子公告牌和公共论坛两个功能. 电子公告牌用于对本系统用户的公告进行管理。公共论坛使用户可以在整个网络覆盖的范围内展开讨论, 极大地改善不同部门、不同地域的沟通问题, 也方便安全学习活动。
(2) 安评指标和任务管理子系统。
该子系统完成安评指标的维护和安评任务分解、下达功能. 安评指标的维护完成安全性评价基础查评标准信息的维护及电力系统企业自定的公司 (或企业) 查评标准信息的维护, 并提供对上述查评标准信息的数据采集与信息检索功能. 安评任务下达是根据查评指标维护环节所维护的各单位的查评标准信息, 向各地调部门发布或生成本次安全查评工作的各项任务.安评任务分解根据单位的组织机构层次关系逐级进行, 直至任务已经分解到最基层的相关责任人员上。
(3) 自查评管理子系统。
各地调中心在定期安全性评价功能中完成自查评工作, 系统根据查评打分给出各地调自查评的汇总分数和合格率, 并形成自查报告以及相应的详细数据。各责任人可以对比查评标准和实际安全工作的各项进行打分, 并填写得、扣分的原因, 对非满分项设定问题级别.对于自查评的结果, 该系统具有专业、周期、以及各单位之间的对比功能。
(4) 专家查评管理子系统。
专家查评小组根据各单位自查评的查评项目进行审核, 并根据审核情况进行专家查评小组打分工作。本子系统不仅能对专家情况进行管理, 为各查评项指定专家. 还能提供对专家项目进行打分并进行扣分原因及整改建议的功能, 并对专家查评结果进行各种比较。
(5) 整改管理子系统。
该子系统实现专家整改建议的提出, 各单位制定整改措施, 编写整改报告的功能。整改管理子系统主要针对安评环节所发现的查评问题记录信息, 进行查评整改任务的提取, 制定整改措施并检查整改工作的信息反馈, 完成整改报告。
(6) 安评任务完成情况子系统。
本子系统用于管理和查询各地区当前周期查评任务完成的情况。按计划内完成、计划内未完成、超期完成、超期未完成等类型, 查询各单位、或各责任人各周期内所有按照安评计划中的计划日期完成安评指标项的情况。
5 结语
电网调度安全性评价管理系统在预测、防范电网调度可能存在的事故或隐患, 消除不利于电网调度正常运行的因素等方面能发挥积极的作用.它符合现代企业管理理念, 能够充分地提高工作效率和省公司的经营经营决策水平, 大大提升企业的现代化进程。
参考文献
[1]张丽英, 余卫国等.电网调度系统安全性评价 (网、省调部分) [J].国家电网公司, 2003.
[2]刘俭.安全性评价与危险点分析[J].电力安全技术, 2001, 1 (3) .
Web调度系统 篇6
随着互联网技术的发展,Web服务数量的增长速度不断加快,对于越来越多的Web服务请求,如何保障用户所需要响应速度以及查询准确度来说是个巨大的挑战[1,2]。网络系统在保障用户的Web服务请求时,通常采用数据挖掘的方法处理大规模的Web服务请求数据[3]。
聚类算法是数据挖掘领域的一个重要研究内容,通过多个作为聚类中心的数据样本与其他数据样本之间的相似性程度,使数据样本向聚类中心靠拢,从而形成多个簇结构[4]。现有的经典聚类算法有K⁃means,QIDB⁃SCAN,PAM,AP等聚类算法[5,6,7,8]。以上一些方法没有利用本体等技术从语义层次进行匹配计算来实现服务聚类,影响了服务聚类的准确性;另外一些方法在利用传统的聚类方法实施服务聚类时,计算服务间的相似度所耗时间比较长,影响了服务聚类的效率。综上,这些算法应用为搜索引擎时,存在着精确度不高、召回率低、信息过载和淹没的问题。文献[9]提出一种基于RDB中自身连接的Web服务聚类方法,该方法利用本体概念间的语义推理关系,并设计一种基于关系数据库,快速准确实施Web服务聚类,但也存在着服务种类设定单一固定,没有考虑服务特性信息,实际应用性不高的问题。
针对上述聚类算法在应用中的问题,本文提出一种新的Web数据聚类算法,首先对于Web数据在Web服务的时间序列上的聚类过程进行了定义和分析,接着提出了增量式时间序列聚类方法,该部分包括了数据压缩和数据聚类,确保在数据挖掘前期处理掉重复的数据,利用时间相似度矩阵,对聚类任务进行分组,进一步确保所设计算法的准确度。然后依据最佳任务调度策略实现Web集群服务中的最佳负载运算状态,进一步保证本文所设计方法的快速高效。整个系统算法系统框图见图1。
1 基于时间序列的Web数据聚类定义
对于Web数据在Web服务的时间序列上的聚类过程,定义如下:
定义1 时间序列。文中时间序列K={k1,k2,⋯,kt}表示在Web服务的总的寿命轨迹中,任何时间t内表示样本数据时间特性的数字有序集合。
定义2 时间序列聚类。给定N个对象的数据集,则N={K1,K2,⋯,KN},表示一个时间集。以作为一个聚类中心,基于相似信息均匀的时间序列数据被集中在一起,这就是时间序列聚类。
定义3 相似信息。两个时间序列之间的相似性是基于它们的子序列之间的相似性。
定义4 子集群。一个子集群GCi是一组单独的在时间上具有相似性的时间序列数据,并表示为一个单一的原型。时间序列数据根据与它们的子集群紧密度被附加到新的子集群。
定义5 聚类能力。时间序列ki与一个子集群GCi的紧密度被定义为:
式中:Xij表示ki与kj之间的相似度;|GCi|表示时间序列数据的数目;A(ki)是用来区别具有低紧密度的时间序列数据,并把它们放到一个新的子集群中。
2 增量式时间序列聚类算法
时间序列分析(Time Series Analysis)是一种动态数据处理的统计方法,而本文采用的增量式时间序列聚类是采用聚类的方法先对总的数据进行时间序列的分析,从而根据时间相似性将数据分成多个子集群,再对各个子集群数据进行相似性分析。而且本文的增量式时间序列聚类方法还加入了数据压缩技术,有效减少算法运算的复杂性,减少聚类时间。该算法的流程包括数据压缩和时间序列数据聚类2个步骤。
2.1 数据压缩
对于非常相似的时间序列数据,基于增量式时间序列聚类方法首先计算出时间序列数据之间的相似度矩阵,以一个紧密度阈值为标准,通过比较阈值的大小来确定时间序列数据是否达到一定的相似程度,当数据达到一定的相似度时,通过移除这部分相似数据,从而尽可能地减少重复的无用数据,实现Web数据的压缩。
先采用数据压缩的方法可以有效地减少Web数据的复杂性[10,11]。时间序列数据首先通过归一化法而被标准化,防止时间序列数据在压缩时发生比例变化和偏移。假如K={k1,k2,⋯,kt}是一个时间序列,则时间序列数据通过归一化定义为:
式中:ai表示数据点的算术平均值;λ是在给定的时间序列内所有数据点的标准偏差。
时间序列数据之间的相似性被计算出来并存储在一个N×N的相似度矩阵XN×N中,假设DN×N为一个距离矩阵,由于Xij表示ki与kj之间的相似度,则Dij用来表示ki与kj之间的欧几里得距离,Dij的计算公式为:
当给定一个相似度矩阵XN×N,其阈值范围为(0,1)的紧密度,算法通过从一个子集群移除时间序列数据来实现数据压缩。
2.2 时间序列数据聚类
在步骤1中,时间序列数据是基于时间的相似性进行分组。当两个时间序列数据在结构信息上是相似时,在时间上并不一定相似,而只有考虑到时间序列上的相似性,才更加符合实际的Web数据聚类情况。因此,子集群之间的相似性被计算出来,并且存储在一个M×M的相似性矩阵中,用YM×M表示。Yij代表着子集群GCi与GCj之间的相似度。子集群之间的欧几里得距离是被计算出来构建相似性矩阵YM×M的。为了计算子集群GCi与GCj之间的距离,需要计算子集群GCi中所有数据点与子集群GCj中所有数据的欧几里得距离的平均值。得到距离方程:
式中:n(GCi),n(GCj)分别表示子集群GCi和GCj的数据点数量。
3 最佳任务调度
在进行Web的集群服务时,服务器的装载量平衡可以被描述为:N个任务需要分配到M个节点服务器,并且用不同的装载量和处理量进行处理,为了找到一个优化调度,以最小化总完工时间。该系统的数学模型表示如下[12,13]:
假设有M个服务器(或节点)和N个任务,并且每个任务必须被分配给一个服务器。在此采用F={f1,f2,⋯,fM}代表服务器,并用L={l1,l2,⋯,lM}表示当前的负载,N个任务表示为Y={y1,y2,⋯,yN},建立一个M×N的矩阵来表示任务和服务器,用gij表示任务yi在服务器fj的两种状态:
假设任务yi在服务器fj执行所需要的时间为tij,定义进行任务调度时最佳的系统状态具有以下条件:
(1)整个系统具有相对短的处理时间;
(2)整个系统的吞吐量在任务执行时是较大的。
采用一个函数W(yi,li,fi),它可以反映整个系统处理任务的能力:
式中:μ1和μ2分别表示一个常数;li反映当前服务器fj的负载能力;表示系统当前所有服务器的负载能力;中的ft表示对应服务器f处理每个任务的时间间隔;则表示系统在处理任务过程中的总间隔时间;的值越大,说明该系统在完成任务上花费的时间越多,则说明该系统的运算能力越差。越大,则说明系统的负载能力越强。因此这里的W(yi,li,fi)反映的是在处理每一个任务时系统在运算及负载上的综合能力,并用它来反映整个系统处理任务的能力,W(yi,li,fi)越小,则系统处理任务的能力越好。当处于任务执行状态且服务器的负载能力达到最大时,该系统处在最佳的运行状态。假设每个服务器作为一个聚类中心,任务以服务器的执行能力作为衡量紧密度的一个标准,紧密度越高的服务器,任务就会向其聚拢,但服务器每增加一个任务时,根据式(8)可知其执行能力会逐渐下降。在本文的Web数据聚类算法中,实现任务的最佳调度的步骤如下:
步骤1:在进行Web的集群服务时,对于M个服务器F={f1,f2,⋯,fM},根据式(8)计算其当前的执行能力。
步骤2:对于N个任务Y={y1,y2,⋯,yN},任务yi根据紧密度的大小σij而选择是否需要向服务器fj聚拢,σij的计算公式为:
式中:ζ(fj)表示服务器fj的最大吞吐量;loadj表示服务器fj当前的负载量;n(fj)表示当前服务器fj所接收的任务数量。
4 实验仿真及分析
4.1 仿真环境及场景设置
为了验证本文提出的基于增量式时间序列和最佳任务调度的Web数据聚类算法,在CPU为Intel Core i5,主频3.3 GHz,内存为4 GB的PC机上对算法进行了Matlab编程仿真,采用了OWLS⁃TC数据库的数据资源,本文所进行的仿真实验的Web服务总数最大为300,服务器数量为60,仿真数据取20次运行的平均结果。文献[14]提出了GACH:基于网格的高维数据的层次聚类算法;文献[15]提出了基于多目标模糊聚类的增量学习数据分类算法,本文的算法与这两篇文献中的算法进行了性能比较。
4.2 聚类时间
聚类算法完成每一次数据聚类的时间是衡量该聚类算法聚类性能的一个重要指标,为了测试本文算法的聚类性能,在仿真实验中对系统提供的数据进行了聚类,并得出算法所需的聚类时间,得到图2的结果。从图2的曲线可以看出,在服务总数增大的情况下,本文算法的聚类时间保持着较小的增长趋势,最大的聚类时间不超过200 s,而文献[14]算法和文献[15]算法的聚类时间随服务总数的增加有明显的增长趋势,且最大的聚类时间均超过500 s。可以看出,本文算法所需的聚类时间相对较少,在这方面的性能相比文献[14,15]算法具有一定的优势。因为文献[14]是一种基于网格的方法来对高维数据进行划分,网格方法虽然在数据分类上复杂度较低,但计算量较大。文献[15]采用的是模糊聚类的方法,并结合学习的方法实现数据分类,因此数据分类的迭代次数较多,运算量大。而本文的方法先对数据进行了压缩,减少了运算量,缩短了聚类时间。
4.3 聚类精确度
聚类精确度是衡量聚类算法有效性的关键,聚类精度越高说明该聚类算法能够更加有效地对样本进行分类。为了验证算法的聚类精确度,在服务总数逐渐增多的情况下,统计了三种算法的聚类精度,并得到了图3的结果。从图3中可以看出,服务总数的增加使得算法的聚类精度有下降的趋势,其中本文算法的下降幅度相对较小,从60的服务总数增多至240的服务总数时,本文算法的聚类精度下降了9%,最终处在86.7%。文献[14]的算法和文献[15]的算法则分别下降了20.3%和21.4%,最终分别处在66.4%和68.5%。从对比数据可以看出,本文算法的聚类精确度较高。文献[14]的方法只采用基于网格的方法,单一地考虑了数据的结构性特征,因此聚类精度最低。文献[15]结合聚类和机器学习的方法,在一定程度上提高了聚类精度,但相比本文的方法,缺少了对数据在时间相似度上的考虑,因此聚类精度相比本文的方法不占优势。
4.4 服务执行成功率
服务执行成功率表示对服务任务进行调度时,给服务器所分配的服务任务能够执行成功的数量与总分配的服务任务的比值,从服务执行成功率可以说明该任务调度方法是否有效。为了对这一问题进行验证,在服务总数增多的情况下,对三种算法就服务执行成功率问题进行了仿真实验。从得到的图4的结果可以看出,在服务总数增多的情况下,算法的服务成功率会出现波动的趋势,并且会有一定的下降幅度,图4中本文的算法在服务总数为30时服务执行成功率高于85%,之后下降到78%,而文献[14]和文献[15]的方法在服务总数为30时服务执行成功率均低于75%,之后分别下降到59%和53%。因此本文算法的服务执行成功率相对来说较高。
4.5 聚类失真度
聚类失真度是反映聚类算法性能的一个重要指标,失真度越小说明相似点聚在一个类中程度越高,聚类的效果就越好。在实验中失真度定义为每个点和它所属聚类的代表点之间距离的平方和,在改变数据聚类的个数的情况下,记录聚类算法的失真度,并得到了图5的结果。
从图5中可以看出,随着聚类数量的增多,聚类算法的失真程度会逐渐降低,这是因为在整体数据量不变的情况下,根据数据的特性划分的聚类数更多,则每个聚类所包含的范围越小,在某一个聚类中的数据就越接近所属聚类的代表点。图5中本文算法的聚类失真度最低达到了5.4%,而文献[14]算法达到了8.3%,文献[15]达到了7.1%,相比较这两个对比算法,本文算法的失真度更小,聚类的效果就越好。
5 结论