一种WEB服务监控参数的调整装置和方法转让专利
申请号 : CN200910094000.1
文献号 : CN101695034B
文献日 : 2011-09-14
发明人 : 戴桂兰 , 戴凤军
申请人 : 清华大学
摘要 :
本发明提出了一种WEB服务监控参数的调整装置和方法，针对现有技术中监控与系统性能无法兼顾的问题而发明。本发明的装置包括：参数收集模块，收集服务的平均响应时间、系统占用的处理器资源、系统占用的内存资源、当前用户的访问量参数；控制模块，对WEB服务监控的数据拦截频率、数据处理频率、数据发送频率和数据持久化频率进行调整。本发明的方法包括：当WEB服务的平均响应时间变化时，根据WEB服务的系统占用的处理器和内存资源及当前用户的访问量，对监控的数据拦截频率、数据处理频率、数据发送频率和数据持久化频率进行调整。本发明能够实现监控及时性、准确性，并兼顾对被监控服务的性能影响。
权利要求 :
1.一种WEB服务监控参数的调整装置，其特征在于，包括：
参数收集模块，所述参数收集模块连接WEB服务以收集WEB服务的参数，所述参数至少包括：WEB服务的平均响应时间、系统占用的处理器资源、系统占用的内存资源、当前用户的访问量；
控制模块，所述控制模块连接所述参数收集模块，以根据所述参数收集模块收集到的WEB服务的参数对WEB服务监控的数据拦截频率、数据处理频率、数据发送频率和数据持久化频率进行调整，调整规则为：当平均响应时间上升时，如果当前访问量不变或下降，且系统占用内存资源不变、空闲内存资源不变或下降、系统占用处理器资源不变、空闲处理器资源不变或下降时，则降低所述监控的数据持久化频率；
当平均响应时间上升时，如果当前访问量不变或下降，且系统占用内存资源上升、空闲内存资源下降、系统占用处理器资源上升、空闲处理器资源不变或下降时，则降低数据拦截和数据处理的频率；
当平均响应时间上升时，如果当前访问量不变或下降，且系统占用内存资源上升、空闲内存资源下降、系统占用处理器资源不变、空闲处理器资源不变或下降时，则降低数据发送的频率；
当平均响应时间上升时，如果当前访问量不变或下降，且系统占用内存资源不变或下降、空闲内存资源不变或下降、系统占用处理器资源上升、空闲处理器资源不变或下降时，则降低数据处理的频率；
当平均响应时间上升时，如果当前访问量不变或上升，且系统占用内存资源不变或上升、空闲内存资源达到阀值、系统占用处理器资源和空闲处理器资源均未达到阀值，则提高数据发送和数据持久化的频率；
当平均响应时间上升时，如果当前访问量不变或上升，且系统占用内存资源和空闲内存资源均未达到阀值、系统占用处理器资源不变或上升、空闲处理器资源达到阀值，则降低数据拦截和数据处理的频率；
当平均响应时间降低时，如果当前访问量上升，且系统占用内存资源不变、空闲内存资源不变或降低、系统占用处理器资源不变、空闲处理器资源不变或降低，则不调整或提高数据持久化的频率；
当平均响应时间降低时，如果当前访问量不变或上升，且系统占用内存资源降低、空闲内存资源升高、系统占用处理器资源不变、空闲处理器资源不变或降低，则不调整或提高数据发送的频率；
当平均响应时间降低时，如果当前访问量不变或上升，且系统占用内存资源不变或降低、空闲内存资源不变或升高、系统占用处理器资源降低、空闲处理器资源不变或升高，则提高数据处理的频率。
2.根据权利要求1所述的WEB服务监控参数的调整装置，其特征在于，所述控制模块包括：参数读取模块，所述参数读取模块连接所述参数收集模块，以读取所述WEB服务的参数改变；
监控参数调整模块，所述监控参数调整模块连接所述参数读取模块，并根据所述调整规则对监控参数进行调整。
3.一种WEB服务监控参数的调整方法，包括：
当WEB服务的平均响应时间变化时，根据WEB服务的系统占用的处理器和内存资源及当前用户的访问量，调整WEB服务监控的数据拦截频率、数据处理频率、数据发送频率和数据持久化频率，以实现对监控所占用的资源进行调整，对所述WEB服务监控的参数的具体调整方法为：当平均响应时间上升时，如果当前访问量不变或下降，且系统占用内存资源不变、空闲内存资源不变或下降、系统占用处理器资源不变、空闲处理器资源不变或下降时，则降低所述监控的数据持久化频率；
当平均响应时间上升时，如果当前访问量不变或下降，且系统占用内存资源上升、空闲内存资源下降、系统占用处理器资源上升、空闲处理器资源不变或下降时，则降低数据拦截和数据处理的频率；
当平均响应时间上升时，如果当前访问量不变或下降，且系统占用内存资源上升、空闲内存资源下降、系统占用处理器资源不变、空闲处理器资源不变或下降时，则降低数据发送的频率；
当平均响应时间上升时，如果当前访问量不变或下降，且系统占用内存资源不变或下降、空闲内存资源不变或下降、系统占用处理器资源上升、空闲处理器资源不变或下降时，则降低数据处理的频率；
当平均响应时间上升时，如果当前访问量不变或上升，且系统占用内存资源不变或上升、空闲内存资源达到阀值、系统占用处理器资源和空闲处理器资源均未达到阀值，则提高数据发送和数据持久化的频率；
当平均响应时间上升时，如果当前访问量不变或上升，且系统占用内存资源和空闲内存资源均未达到阀值、系统占用处理器资源不变或上升、空闲处理器资源达到阀值，则降低数据拦截和数据处理的频率；
当平均响应时间降低时，如果当前访问量上升，且系统占用内存资源不变、空闲内存资源不变或降低、系统占用处理器资源不变、空闲处理器资源不变或降低，则不调整或提高数据持久化的频率；
当平均响应时间降低时，如果当前访问量不变或上升，且系统占用内存资源降低、空闲内存资源升高、系统占用处理器资源不变、空闲处理器资源不变或降低，则不调整或提高数据发送的频率；
当平均响应时间降低时，如果当前访问量不变或上升，且系统占用内存资源不变或降低、空闲内存资源不变或升高、系统占用处理器资源降低、空闲处理器资源不变或升高，则提高数据处理的频率。
说明书 :
一种WEB服务监控参数的调整装置和方法
技术领域
[0001] 本发明涉及一种WEB服务的质量保证技术，特别是指一种WEB服务监控参数的调整装置和方法。
背景技术
[0002] 在Web服务的整个生命周期内，服务监控都扮演着非常重要的角色。对于Web测试、管理以及Web服务QoS(Quality of Service，服务质量)保证具有重要意义。
[0003] 在服务测试期间，服务监控是测试用户获取各类测试数据的基本手段。在服务运行期间，服务监控是管理人员了解服务运行状况、调整服务策略、排除服务故障的基本工
具。此外，从用户角度来看，在服务绑定期间，服务监控是服务客户随时掌握服务连接状态、
调整服务绑定策略的重要依据。因此，Web服务监控具有非常重要意义。
具。此外，从用户角度来看，在服务绑定期间，服务监控是服务客户随时掌握服务连接状态、
调整服务绑定策略的重要依据。因此，Web服务监控具有非常重要意义。
[0004] 当前在WEB服务的监控方面已取得了一些研究成果，但主要存在经下几个方面的问题：一是接口简单，通常仅提供基本原始记录监控，无法得到完整而详细的监控报告；二
是系统调整也基本由管理人员手动进行，不能根据系统运行情况及服务绑定需求对服务进
行动态调整，无法满足服务质量动态跟踪和调整的需求；三是没有很好地解决监控的及时
性、准确性与对被监控服务性能之间存在的矛盾。
是系统调整也基本由管理人员手动进行，不能根据系统运行情况及服务绑定需求对服务进
行动态调整，无法满足服务质量动态跟踪和调整的需求；三是没有很好地解决监控的及时
性、准确性与对被监控服务性能之间存在的矛盾。
发明内容
[0005] 针对现有技术中存在的缺陷和不足，本发明的目的是提供一种WEB服务监控参数的调整装置和方法，针对现有技术中无法很好解决监控及时性、准确性与对被检测服务性
能影响之间的关系，在降低对于服务性能影响的前提下提高监测的及时性和准确性。
能影响之间的关系，在降低对于服务性能影响的前提下提高监测的及时性和准确性。
[0006] 为了达到上述目的，本发明提出了一种WEB服务监控参数的调整装置，包括：
[0007] 参数收集模块，所述参数收集模块电连接WEB服务以收集WEB服务的参数，所述参数至少包括：WEB服务的平均响应时间、系统占用的处理器资源、系统占用的内存资源、当
前用户的访问量；
前用户的访问量；
[0008] 控制模块，所述调整模块电连接所述参数收集模块，以根据所述参数收集模块收集到的WEB服务的参数对WEB服务监控的数据拦截频率、数据处理频率、数据发送频率和数
据持久化频率进行调整。
据持久化频率进行调整。
[0009] 其中，所述控制模块包括：
[0010] 参数读取模块，所述参数读取模块电连接所述参数收集模块，以读取所述WEB服务的参数改变；
[0011] 监控参数调整模块，所述监控参数调整模块电连接所述参数读取模块，并根据以下规则对监控参数进行调整：
[0012] 当平均响应时间上升时，如果当前访问量不变或下降，且系统占用内存资源不变、空闲内存资源不变或下降、系统占用处理器资源不变、空闲处理器资源不变或下降时，则降
低监控持久化的频率；
低监控持久化的频率；
[0013] 当平均响应时间上升时，如果当前访问量不变或下降，且系统占用内存资源上升、空闲内存资源下降、系统占用处理器资源上升、空闲处理器资源不变或下降时，则降低数据
拦截和数据处理的频率；
拦截和数据处理的频率；
[0014] 当平均响应时间上升时，如果当前访问量不变或下降，且系统占用内存资源上升、空闲内存资源下降、系统占用处理器资源不变、空闲处理器资源不变或下降时，则降低数据
发送的频率；
发送的频率；
[0015] 当平均响应时间上升时，如果当前访问量不变或下降，且系统占用内存资源不变或下降、空闲内存资源不变或下降、系统占用处理器资源上升、空闲处理器资源不变或下降
时，则降低数据处理的频率；
时，则降低数据处理的频率；
[0016] 当平均响应时间上升时，如果当前访问量不变或上升，且系统占用内存资源不变或上升、空闲内存资源达到阀值、系统占用处理器资源和空闲处理器资源均未达到阀值，则
提高数据发送和数据持久化的频率；
提高数据发送和数据持久化的频率；
[0017] 当平均响应时间上升时，如果当前访问量不变或上升，且系统占用内存资源和空闲内存资源均未达到阀值、系统占用处理器资源不变或上升、空闲处理器资源达到阀值，则
降低数据拦截和数据处理的频率；
降低数据拦截和数据处理的频率；
[0018] 当平均响应时间降低时，如果当前访问量上升，且系统占用内存资源不变、空闲内存资源不变或降低、系统占用处理器资源不变、空闲处理器资源不变或降低，则不调整或提
高数据持久化的频率；
高数据持久化的频率；
[0019] 当平均响应时间降低时，如果当前访问量不变或上升，且系统占用内存资源降低、空闲内存资源升高、系统占用处理器资源降低、空闲处理器资源升高，则不调整、或提高数
据拦截和/或数据处理和/或数据处理的频率；
据拦截和/或数据处理和/或数据处理的频率；
[0020] 当平均响应时间降低时，如果当前访问量不变或上升，且系统占用内存资源降低、空闲内存资源升高、系统占用处理器资源不变、空闲处理器资源不变或降低，则不调整或提
高数据发送的频率；
高数据发送的频率；
[0021] 当平均响应时间降低时，如果当前访问量不变或上升，且系统占用内存资源不变或降低、空闲内存资源不变或升高、系统占用处理器资源降低、空闲处理器资源不变或升
高，则提高数据处理的频率。
高，则提高数据处理的频率。
[0022] 同时，本发明还提出了一种WEB服务监控参数的调整方法，包括：
[0023] 当WEB服务的平均响应时间变化时，根据WEB服务的系统占用的处理器和内存资源及当前用户的访问量，调整数据拦截频率、数据处理频率、数据发送频率和数据持久化频
率，以实现对监控所占用的资源进行调整。
率，以实现对监控所占用的资源进行调整。
[0024] 其中，所述WEB服务监控参数的具体调整方法为：
[0025] 当平均响应时间上升时，如果当前访问量不变或下降，且系统占用内存资源不变、空闲内存资源不变或下降、系统占用处理器资源不变、空闲处理器资源不变或下降时，则降
低监控持久化的频率；
低监控持久化的频率；
[0026] 当平均响应时间上升时，如果当前访问量不变或下降，且系统占用内存资源上升、空闲内存资源下降、系统占用处理器资源上升、空闲处理器资源不变或下降时，则降低数据
拦截和数据处理的频率；
拦截和数据处理的频率；
[0027] 当平均响应时间上升时，如果当前访问量不变或下降，且系统占用内存资源上升、空闲内存资源下降、系统占用处理器资源不变、空闲处理器资源不变或下降时，则降低数据
发送的频率；
发送的频率；
[0028] 当平均响应时间上升时，如果当前访问量不变或下降，且系统占用内存资源不变或下降、空闲内存资源不变或下降、系统占用处理器资源上升、空闲处理器资源不变或下降
时，则降低数据处理的频率；
时，则降低数据处理的频率；
[0029] 当平均响应时间上升时，如果当前访问量不变或上升，且系统占用内存资源不变或上升、空闲内存资源达到阀值、系统占用处理器资源和空闲处理器资源均未达到阀值，则
提高数据发送和数据持久化的频率；
提高数据发送和数据持久化的频率；
[0030] 当平均响应时间上升时，如果当前访问量不变或上升，且系统占用内存资源和空闲内存资源均未达到阀值、系统占用处理器资源不变或上升、空闲处理器资源达到阀值，则
降低数据拦截和数据处理的频率；
降低数据拦截和数据处理的频率；
[0031] 当平均响应时间降低时，如果当前访问量上升，且系统占用内存资源不变、空闲内存资源不变或降低、系统占用处理器资源不变、空闲处理器资源不变或降低，则不调整或提
高数据持久化的频率；
高数据持久化的频率；
[0032] 当平均响应时间降低时，如果当前访问量不变或上升，且系统占用内存资源降低、空闲内存资源升高、系统占用处理器资源降低、空闲处理器资源升高，则不调整、或提高数
据拦截和/或数据处理和/或数据处理的频率；
据拦截和/或数据处理和/或数据处理的频率；
[0033] 当平均响应时间降低时，如果当前访问量不变或上升，且系统占用内存资源降低、空闲内存资源升高、系统占用处理器资源不变、空闲处理器资源不变或降低，则不调整或提
高数据发送的频率；
高数据发送的频率；
[0034] 当平均响应时间降低时，如果当前访问量不变或上升，且系统占用内存资源不变或降低、空闲内存资源不变或升高、系统占用处理器资源降低、空闲处理器资源不变或升
高，则提高数据处理的频率。
高，则提高数据处理的频率。
[0035] 上述技术方案具有如下优点：本发明研究监控对于服务平均响应时间的影响，并根据系统占用处理器和内存资源及用户访问量的改变，对监控的数据拦截频率、数据处理
频率、数据发送频率和数据持久化频率进行调整，从而实现针对服务性能自动调整监控的
频率，以实现监控的及时性、准确性，并兼顾对被监控服务性能影响。
频率、数据发送频率和数据持久化频率进行调整，从而实现针对服务性能自动调整监控的
频率，以实现监控的及时性、准确性，并兼顾对被监控服务性能影响。
附图说明
[0036] 图1是WEB服务监控的流程图；
[0037] 图2是本发明优选实施例中的服务信息获取流程图；
[0038] 图3是应用本发明提出的装置组成的自调整监控系统的总体架构示意图；
[0039] 图4是系统CPU和内存资源达到阀值后的试验结果示意图；
[0040] 图5是系统IO资源紧张时调整实验结果示意图；
[0041] 图6是网络资源竞争时调整实验结果示意图。
具体实施方式
[0042] 下面结合附图和实施例，对本发明的具体实施方式作进一步详细描述。以下实施例用于说明本发明，但不用来限制本发明的范围。
[0043] 为了便于理解本发明，现将本发明所涉及到的技术进行简单的介绍：
[0044] Web服务监控的整体过程如图1所示，包括以下四个部分：
[0045] 一、数据拦截：是指通过在数据处理通道内拦截Web服务的交互数据内容和相关的上下文信息(包括：数据ID、数据发送方、接收方、当前时间、数据调用服务、数据类型、数
据交换模式等信息)，获取基础服务信息。当前主要的SOAP引擎(如Axis2、XFire、CXF、
ASP.NET等)在对经由SOAP数据处理时都是采用数据处理链的方式。用户可以根据需要其
中嵌入自己的实现，配置到相应处理通道中，即可获得对经过的数据进行处理的机会。
据交换模式等信息)，获取基础服务信息。当前主要的SOAP引擎(如Axis2、XFire、CXF、
ASP.NET等)在对经由SOAP数据处理时都是采用数据处理链的方式。用户可以根据需要其
中嵌入自己的实现，配置到相应处理通道中，即可获得对经过的数据进行处理的机会。
[0046] 二、数据处理：是指对拦截的数据上下文内容进行处理并完成格式转换。数据处理通常包括根据数据ID和请求进入时间得到数据的响应时间、对不同的服务请求、响应、异
常时行计数以得到当前服务的统计信息、更新服务的最大、最小响应时间等，而后对上述拦
截数据和处理得到的数据进行转换，供后续处理。
常时行计数以得到当前服务的统计信息、更新服务的最大、最小响应时间等，而后对上述拦
截数据和处理得到的数据进行转换，供后续处理。
[0047] 三、监控数据缓存：是指对一段时间内的监控数据内容进行缓存。由于数据拦截的频率和需要拦截的服务数量都非常高，出于系统服务效率影响的考虑，通常需要对监控相
关数据进行缓存，以尽量减少过高的数据传送频率或过高的数据持久化频率对服务造成的
影响。
关数据进行缓存，以尽量减少过高的数据传送频率或过高的数据持久化频率对服务造成的
影响。
[0048] 四、数据发送、数据持久化：是指将监控的数据内容发送给用户(如管理员、性能测试工具)，或者持久到后端的数据库、文件系统中，供后期的查询和进一步处理(如对服
务性能进行评估等)所用。
务性能进行评估等)所用。
[0049] 由于基于服务端的监控受各种外部因素的影响较小，能够更加真实地反映服务本身的状态，并且对服务的管理和测试也大多在服务端进行。因此，本发明是针对服务端的监
控所做出的改进。
控所做出的改进。
[0050] 对于服务性能的度量，如果以各种服务的平均响应时间P来取值，则不能反应每个服务的真正性能。如果将每个服务的每个方法都与服务端资源联系起来并考察它们之间
的相互关系也是不可行的，由于系统对资源的分配无法确定到服务级别，更谈不上在方法
级别上。因而，本专利采用基于统计的方式来确定P的变化。以Pt表示在时间T内的平均
性能变化。
的相互关系也是不可行的，由于系统对资源的分配无法确定到服务级别，更谈不上在方法
级别上。因而，本专利采用基于统计的方式来确定P的变化。以Pt表示在时间T内的平均
性能变化。
[0051] 对具体的服务Si而言，其响应时间变化对性能的影响可以分为两部分，一部分是由于其访问量分布的比例所做的贡献，另一部分是其本身响应时间变化幅度的变化所做的
贡献。本文将这两部分分别称作分布贡献度DCtrsi和幅度贡献度ACtrsi。
贡献。本文将这两部分分别称作分布贡献度DCtrsi和幅度贡献度ACtrsi。
[0052] 总的平均响应时间指数P，综合考虑所有服务的分布值和平均响应时间，得出一个合理的响应时间变化度量值，可以表示如下：
[0053]
[0054] 其中VCTrsi为综合贡献度，它是幅度贡献度DCtrsi和幅度贡献度ACtrsi二者基础上得出的一个综合指数，在二者基础上的得到的一个函数值。简单的说，VCTrsi可以为分
布贡献度DCtrsi和幅度贡献度ACtrsi的乘积。
布贡献度DCtrsi和幅度贡献度ACtrsi的乘积。
[0055] 在确定了具体的服务Si的平均响应时间P后，以下对影响平均响应时间P的参数进行分析：
[0056] 与Web引擎和服务实现相同的，影响服务性能的因素由服务端的处理器(CPU)、内存、网络、磁盘IO这四项系统资源因子，以及当前的用户请求数量这五个因素来共同决定。
本文中分别用Scpu、Smem、Snet、Sdisk和Reqcnt表示上述五个因素。因此，P可以表示成基于以上
五个参数的函数，如下式(1-2)所示：
本文中分别用Scpu、Smem、Snet、Sdisk和Reqcnt表示上述五个因素。因此，P可以表示成基于以上
五个参数的函数，如下式(1-2)所示：
[0057] P＝f1(Ss_cpu，Ss_mem，Ss_net，Ss_disk，Reqcnt) (1-2)
[0058] 其中Ss_cpu，Ss_mem，Ss_net，Ss_disk分别代表web服务所占用的CPU、内存、网络和磁盘IO资源。
[0059] 由于服务端的处理器(CPU)、内存、网络、磁盘IO都分别由Web服务本身、监控Web服务、系统和其它应用共享。因此上述四项系统资源中，每一个资源可以分为服务本身占
用、监控占用、其它应用资源、系统空闲资源。以上四种资源的总量定义为Icpu、Imen、Inet、
Idisk。在特定系统中为常量，则它们之间相互影响关系用函数φ表示如下：
用、监控占用、其它应用资源、系统空闲资源。以上四种资源的总量定义为Icpu、Imen、Inet、
Idisk。在特定系统中为常量，则它们之间相互影响关系用函数φ表示如下：
[0060] Ss_cpu＝φcpu(Sm_cpu，So_cpu，Sf_cpu) (1-2-1)
[0061] Ss_men＝φmem(Sm_men，So_mem，Sf_men) (1-2-2)
[0062] Ss_net＝φnet(Sm_net，So_net，Sf_net) (1-2-3)
[0063] Ss_disk＝φdisk(Sm_disk，So_disk，Sf_disk) (1-2-4)
[0064] 其中，Ss_cpu，Sm_cpu，So_cpu，Sf_cpu分别代表系统占用的CPU资源、监控所占用的CPU资源、其他应用资源所占用的CPU资源、空闲的CPU资源。
[0065] 其中，Ss_cpu，Sm_men，So_mem，Sf_men分别代表系统占用的内存资源、监控所占用的内存资源、其他应用资源所占用的内存资源、空闲的内存资源。
[0066] 其中，Ss_net，Sm_net，So_net，Sf_net分别代表系统占用的网络资源、监控所占用的网络资源、其他应用资源所占用的网络资源、空闲的网络资源。
[0067] 其中，Ss_disk，Sm_disk，So_disk，Sf_disk分别代表系统占用的磁盘IO资源、监控所占用的磁盘IO资源、其他应用资源所占用的磁盘IO资源、空闲的磁盘IO资源。
[0068] 因此，式(1-2)又可以表示如下：
[0069] P＝f2(φcpu，φmem，φnet，φdisk，Reqcnt) (1-3)
[0070] 由上式(1-3)可以明显的看出，在系统可分配资源一定的情况下，服务本身所占的资源随着外部应用资源和监控所占资源的增加而减少。
[0071] 因此调整监控的主要任务就是尽量调整监控本身所占用的以下四种资源：
[0072] (1)CPU资源：监控本身对CPU资源的占用比较复杂，从上述服务监控流程可见，数据拦截、数据处理、数据发送、数据持久化都需要CPU的参与。数据拦截所占用CPU可以通
过连续的单位时间的接截次数Fitcp来表示，而数据处理数据所占用的CPU则由数据处理的
频率Fpro来衡量。同样，数据发送和数据持久化则由数据发送频率Fsend和数据持久化频率
Fpers来衡量。因而，Sm_cpu可简单地用ψ函数表示如下：
过连续的单位时间的接截次数Fitcp来表示，而数据处理数据所占用的CPU则由数据处理的
频率Fpro来衡量。同样，数据发送和数据持久化则由数据发送频率Fsend和数据持久化频率
Fpers来衡量。因而，Sm_cpu可简单地用ψ函数表示如下：
[0073] Sm_cpu＝ψcpu(Fitcp，Fpro，Fsend，Fpers) (1-4)
[0074] (2)内存资源：监控本身所占内存资源主要包括两部分：监控信息的缓存和监控程序本身运行所占用的。通常，监控程序占用内存基本保持固定，其变化部分主要为缓存部
分。缓存部分主要包括两类监控数据的缓存，即数据发送缓存和数据持久化缓存。设其大
小分别表示为Bsend，Bpers。因此，Sm_mem可用以下函数表示：
分。缓存部分主要包括两类监控数据的缓存，即数据发送缓存和数据持久化缓存。设其大
小分别表示为Bsend，Bpers。因此，Sm_mem可用以下函数表示：
[0075] Sm_mem＝ψmem(Bsend，Bpers) (1-5)
[0076] 由于缓存Bsend，Bpers的大小与发送频率是成反比的关系。因此，上式还可以表示为下式：
[0077] Sm_mem＝ψmem(Fsend，Fpers) (1-6)
[0078] (3)网络资源：监控对网络资源占用主要是监控数据的发送频率和发送量有关，而发送量又可以转化为发送频率的函数。因此，Sm_net可以用下函数表示：
[0079] Sm_net＝ψnet(Fsend) (1-7)
[0080] (4)磁盘IO资源：磁盘IO资源的变化部分通常只与持久化有关，其它部分磁盘IO交互通常不变或变化很小忽略不计。因此，Sm_disk只与持久化频率和持久化量有关。同样，
持久化量也可以转化为持久化频率的函数。因此，Sm_disk可以用下函数表示：
持久化量也可以转化为持久化频率的函数。因此，Sm_disk可以用下函数表示：
[0081] Sm_disk＝ψdisk(Fpers) (1-8)
[0082] 将以上各ψ式分别代入可得到φ函数如下：
[0083] Ss_cpu＝φcpu(Fitcp，Fpro，Fsend，Fpers，So_cpu，Sf_cpu)
[0084] Ss_men＝φmem(Fsend，Fpers，So_mem，Sf_men)
[0085] Ss_net＝φnet(Fsend，So_net，Sf_net)
[0086] Ss_disk＝φdisk(Fpers，So_disk，Sf_disk)。
[0087] 而函数f可以重新表示如下：
[0088] P＝f3(Fitcp，Fpro，Fsend，Fpers，Reqcnt，So_cpu，So_mem，So_net，So_disk，Sf_cpu，Sf_men，Sf_net，Sf_disk) (1-9)
[0089] 由式(1-9)可见，平均响应时间P是与监控频率(Fitcp，Fpro，Fsend，Fpers)、当前用户的访问量(Reqcnt)、其他应用资源所占用的处理器、内存、网络和磁盘IO资源(So_cpu，So_mem，
So_net，So_disk)、空闲的处理器、内存、网络和磁盘IO资源(Sf_cpu，Sf_men，Sf_net，Sf_disk)。其中其他应用资源所占用的处理器、内存、网络和磁盘IO资源(So_cpu，So_mem，So_net，So_disk)为外部不可控部分，而空闲的处理器、内存、网络和磁盘IO资源(Sf_cpu，Sf_men，Sf_net，Sf_disk)则同样受系统分配策略的影响。因此，监控及对服务状态的影响因素主要体现在用户请求量和监控
频率两个方面。
So_net，So_disk)、空闲的处理器、内存、网络和磁盘IO资源(Sf_cpu，Sf_men，Sf_net，Sf_disk)。其中其他应用资源所占用的处理器、内存、网络和磁盘IO资源(So_cpu，So_mem，So_net，So_disk)为外部不可控部分，而空闲的处理器、内存、网络和磁盘IO资源(Sf_cpu，Sf_men，Sf_net，Sf_disk)则同样受系统分配策略的影响。因此，监控及对服务状态的影响因素主要体现在用户请求量和监控
频率两个方面。
[0090] 本发明对于WEB服务的监控调整，其核心就是应用上述分析得到的关系，以判断监控对服务本身的影响是否在合理的范围之内，并依此做出合理调整。
[0091] 实施例1
[0092] 应用上述的分析结果，本发明第一优选实施例提出的WEB服务监控参数的调整装置，包括：
[0093] 参数收集模块，所述参数收集模块电连接WEB服务以收集WEB服务的参数，所述参数至少包括：WEB服务的平均响应时间、系统占用的处理器资源、系统占用的内存资源、当
前用户的访问量；
前用户的访问量；
[0094] 控制模块，所述调整模块电连接所述参数收集模块，以根据所述参数收集模块收集到的WEB服务的参数对WEB服务监控的数据拦截频率、数据处理频率、数据发送频率和数
据持久化频率进行调整。
据持久化频率进行调整。
[0095] 本发明第一优选实施例提出的WEB服务监控参数的调整装置，能够针对服务的平均响应时间、系统占用的处理器资源、系统占用的内存资源、当前用户的访问量这些参数，
自动对WEB服务监控的数据拦截频率、数据处理频率、数据发送频率和数据持久化频率进
行调整。这样可以在服务性能下降，平均响应时间上升时，降低监控频率。在平均响应时间
下降时，提高监控频率。
自动对WEB服务监控的数据拦截频率、数据处理频率、数据发送频率和数据持久化频率进
行调整。这样可以在服务性能下降，平均响应时间上升时，降低监控频率。在平均响应时间
下降时，提高监控频率。
[0096] 实施例2
[0097] 本发明第二优选实施例是在上述第一优选实施例的基础上改进而来，即所述控制模块包括：
[0098] 参数读取模块，所述参数读取模块电连接所述参数收集模块，以读取所述WEB服务的参数改变；
[0099] 监控参数调整模块，所述监控参数调整模块电连接所述参数读取模块，并根据以下规则对监控参数进行调整：
[0100] 当平均响应时间上升时，如果当前访问量不变或下降，且系统占用内存资源不变、空闲内存资源不变或下降、系统占用处理器资源不变、空闲处理器资源不变或下降时，则降
低监控持久化的频率；
低监控持久化的频率；
[0101] 当平均响应时间上升时，如果当前访问量不变或下降，且系统占用内存资源上升、空闲内存资源下降、系统占用处理器资源上升、空闲处理器资源不变或下降时，则降低数据
拦截和数据处理的频率；
拦截和数据处理的频率；
[0102] 当平均响应时间上升时，如果当前访问量不变或下降，且系统占用内存资源上升、空闲内存资源下降、系统占用处理器资源不变、空闲处理器资源不变或下降时，则降低数据
发送的频率；
发送的频率；
[0103] 当平均响应时间上升时，如果当前访问量不变或下降，且系统占用内存资源不变或下降、空闲内存资源不变或下降、系统占用处理器资源上升、空闲处理器资源不变或下降
时，则降低数据处理的频率；
时，则降低数据处理的频率；
[0104] 当平均响应时间上升时，如果当前访问量不变或上升，且系统占用内存资源不变或上升、空闲内存资源达到阀值、系统占用处理器资源和空闲处理器资源均未达到阀值，则
提高数据发送和数据持久化的频率；
提高数据发送和数据持久化的频率；
[0105] 当平均响应时间上升时，如果当前访问量不变或上升，且系统占用内存资源和空闲内存资源均未达到阀值、系统占用处理器资源不变或上升、空闲处理器资源达到阀值，则
降低数据拦截和数据处理的频率；
降低数据拦截和数据处理的频率；
[0106] 当平均响应时间降低时，如果当前访问量上升，且系统占用内存资源不变、空闲内存资源不变或降低、系统占用处理器资源不变、空闲处理器资源不变或降低，则不调整或提
高数据持久化的频率；
高数据持久化的频率；
[0107] 当平均响应时间降低时，如果当前访问量不变或上升，且系统占用内存资源降低、空闲内存资源升高、系统占用处理器资源降低、空闲处理器资源升高，则不调整、或提高数
据拦截和/或数据处理和/或数据处理的频率；
据拦截和/或数据处理和/或数据处理的频率；
[0108] 当平均响应时间降低时，如果当前访问量不变或上升，且系统占用内存资源降低、空闲内存资源升高、系统占用处理器资源不变、空闲处理器资源不变或降低，则不调整或提
高数据发送的频率；
高数据发送的频率；
[0109] 当平均响应时间降低时，如果当前访问量不变或上升，且系统占用内存资源不变或降低、空闲内存资源不变或升高、系统占用处理器资源降低、空闲处理器资源不变或升
高，则提高数据处理的频率。
高，则提高数据处理的频率。
[0110] 实施例3
[0111] 本发明第三优选实施例提出了一种WEB服务的监控方法，包括：
[0112] 当WEB服务的平均响应时间变化时，根据WEB服务的系统占用的处理器和内存资源及当前用户的访问量，对监控的数据拦截频率、数据处理频率、数据发送频率和数据持久
化频率进行调整。
化频率进行调整。
[0113] 实施例4
[0114] 本发明第四优选实施例是在第三优选实施例的基础上改进而来，即所述第三实施例可以具体为：
[0115] 当平均响应时间上升时，如果当前访问量不变或下降，且系统占用内存资源不变、空闲内存资源不变或下降、系统占用处理器资源不变、空闲处理器资源不变或下降时，则降
低监控持久化的频率；
低监控持久化的频率；
[0116] 当平均响应时间上升时，如果当前访问量不变或下降，且系统占用内存资源上升、空闲内存资源下降、系统占用处理器资源上升、空闲处理器资源不变或下降时，则降低数据
拦截和数据处理的频率；
拦截和数据处理的频率；
[0117] 当平均响应时间上升时，如果当前访问量不变或下降，且系统占用内存资源上升、空闲内存资源下降、系统占用处理器资源不变、空闲处理器资源不变或下降时，则降低数据
发送的频率；
发送的频率；
[0118] 当平均响应时间上升时，如果当前访问量不变或下降，且系统占用内存资源不变或下降、空闲内存资源不变或下降、系统占用处理器资源上升、空闲处理器资源不变或下降
时，则降低数据处理的频率；
时，则降低数据处理的频率；
[0119] 当平均响应时间上升时，如果当前访问量不变或上升，且系统占用内存资源不变或上升、空闲内存资源达到阀值、系统占用处理器资源和空闲处理器资源均未达到阀值，则
提高数据发送和数据持久化的频率；
提高数据发送和数据持久化的频率；
[0120] 当平均响应时间上升时，如果当前访问量不变或上升，且系统占用内存资源和空闲内存资源均未达到阀值、系统占用处理器资源不变或上升、空闲处理器资源达到阀值，则
降低数据拦截和数据处理的频率；
降低数据拦截和数据处理的频率；
[0121] 当平均响应时间降低时，如果当前访问量上升，且系统占用内存资源不变、空闲内存资源不变或降低、系统占用处理器资源不变、空闲处理器资源不变或降低，则不调整或提
高数据持久化的频率；
高数据持久化的频率；
[0122] 当平均响应时间降低时，如果当前访问量不变或上升，且系统占用内存资源降低、空闲内存资源升高、系统占用处理器资源降低、空闲处理器资源升高，则不调整、或提高数
据拦截和/或数据处理和/或数据处理的频率；
据拦截和/或数据处理和/或数据处理的频率；
[0123] 当平均响应时间降低时，如果当前访问量不变或上升，且系统占用内存资源降低、空闲内存资源升高、系统占用处理器资源不变、空闲处理器资源不变或降低，则不调整或提
高数据发送的频率；
高数据发送的频率；
[0124] 当平均响应时间降低时，如果当前访问量不变或上升，且系统占用内存资源不变或降低、空闲内存资源不变或升高、系统占用处理器资源降低、空闲处理器资源不变或升
高，则提高数据处理的频率。
高，则提高数据处理的频率。
[0125] 在上述第二和第四实施例中的调整策略可以总结为如下表所示：
[0126]
[0127] 其中，箭头“↑”和“↓”表示上升和下降，“T”表示到达上限阀值，“*”表示除阀值之外的所有可能值，而横线“-”表示不变，符号“，”表示“或”关系。
[0128] 由于系统资源分配复杂多变，因此在出现非本表所列出的情况时，不作调整。这是由于此时无法确定是否是由于监控对服务响应特性造成的影响的情况。
[0129] 优选的，由于调控时各种复杂因素的存在，上述调整中还应参照上一调整周期t-1内的调整策略。如果上在前一周期内相同的变化趋势下，调整后效果不明显，则应该采用更
加谨慎的方式调整或改变调整策略。此外，延迟也是鉴别调整是否有效的一个有效手段。
加谨慎的方式调整或改变调整策略。此外，延迟也是鉴别调整是否有效的一个有效手段。
[0130] 显然，以上四个频率之间存在以下的相互约束关系：
[0131] Fitcp≥Fpro≥Fsend
[0132] Fitcp≥Fpro≥Fpers
[0133] 下面提供一个具体的实现方式，以对本发明做出进一步的具体说明。
[0134] 本发明具体实施例基于Axis2+tomcat+mysql+AcitveMQ在WindowsXP平台上提供了一个基本实现，总体架构图如图3所示。其中应用层包括：服务检测、服务监控、服务质量
评估。其中，监控实体相关层是与具体Axis2相关部分，包括系统监控适配器(CPU内存)、
服务监控适配器、服务事件监控适配器。而系统资源获取部分则基于JNI实现。而监控控
制/处理层则位于服务端，作为一个模块运行在Axis2进行内部，用于截获相关信息并对相
应内容进行预处理，以及监控配置信息的处理。相应的信息持久化到mysql数据库系统或
文件系统。如果需要远程监控则通过JMS(Java Messaging Service，Java消息服务)、端
口和Web服务传输到远程测试或监控客户端。系统提供了一个基于RCP的监控客户端用于
及时接收当前JMS监控消息。此外该监控客户端还可以直接从mysql数据库得到相应的监
控消息，进行分析显示(这种方式对于非即时测试或评估很有意义)。而Web服务接口则作
为服务监控消息的订阅接口，Web服务用户可以通过监控接口得到当前服务的性能信息。
评估。其中，监控实体相关层是与具体Axis2相关部分，包括系统监控适配器(CPU内存)、
服务监控适配器、服务事件监控适配器。而系统资源获取部分则基于JNI实现。而监控控
制/处理层则位于服务端，作为一个模块运行在Axis2进行内部，用于截获相关信息并对相
应内容进行预处理，以及监控配置信息的处理。相应的信息持久化到mysql数据库系统或
文件系统。如果需要远程监控则通过JMS(Java Messaging Service，Java消息服务)、端
口和Web服务传输到远程测试或监控客户端。系统提供了一个基于RCP的监控客户端用于
及时接收当前JMS监控消息。此外该监控客户端还可以直接从mysql数据库得到相应的监
控消息，进行分析显示(这种方式对于非即时测试或评估很有意义)。而Web服务接口则作
为服务监控消息的订阅接口，Web服务用户可以通过监控接口得到当前服务的性能信息。
[0135] 如图3所示，包括：
[0136] (1)服务信息获取模块
[0137] 在Axis2中其消息处理通道由多个处理器(Handler)组成，用户通过在用户可以根据需要创建自己的Handler，实现相应的虚拟处理器(Abstract Handler)接口，并配置
到消息处理通道中即可获得对经由消息处理的机会。如图2所示，在处理SOAP消息时，引
擎会自动调用链条上的每节handler链，从而获得相应的上下文消息，包括消息ID、消息的
发送方、消息接收方、消息采用的传输协议，消息交换模式(Message Exchange Pattern)等
内容。
到消息处理通道中即可获得对经由消息处理的机会。如图2所示，在处理SOAP消息时，引
擎会自动调用链条上的每节handler链，从而获得相应的上下文消息，包括消息ID、消息的
发送方、消息接收方、消息采用的传输协议，消息交换模式(Message Exchange Pattern)等
内容。
[0138] (2)信息生成模块
[0139] 信息生成模块包括基本信息生成模块和统计信息生成模块。
[0140] 统计信息指在一定的时间段t内对服务访问情况的基本统计，象征着该段时间内该统计对象的变化情况。统计信息的生成可以分为三个层次，一是全局统计信息，对应整个
SOAP引擎；二是服务层统计信息，对应具体的service，二是操作层统计信息，对应服务中
某一个操作接口。三层之间是自顶向下的依赖关系：全局统计信息依赖于服务层生成，服务
层统计信息依赖于操作层统计信息生成，而操作层统计信息依赖于基本访问信息生成。
SOAP引擎；二是服务层统计信息，对应具体的service，二是操作层统计信息，对应服务中
某一个操作接口。三层之间是自顶向下的依赖关系：全局统计信息依赖于服务层生成，服务
层统计信息依赖于操作层统计信息生成，而操作层统计信息依赖于基本访问信息生成。
[0141] 基本统计信息由统计信息生成模块生成，负责维护并记录该SOAP引挚启动后的各类统计信息。它分为全局、服务和方法三级，主要依赖于SOAP的消息上下文得到：主要
包括请求计数Reqcnt、响应计数Respcnt、异常记数Faultcnt，以及最大响应时间、最小响
应时间、平均响应时间和最后一次响应时间，分别表示为：ResPmin、Respmax、Resp tavg、
Resplst。
包括请求计数Reqcnt、响应计数Respcnt、异常记数Faultcnt，以及最大响应时间、最小响
应时间、平均响应时间和最后一次响应时间，分别表示为：ResPmin、Respmax、Resp tavg、
Resplst。
[0142] 统计信息的获取可以由一个定时的后台线程执行，它负责定其获得该阶段内的统计信息，并计算出其变化量。其定时器触发频率为Fpro
[0143] 假设用户在一段时间内对服务S中操作O进行了M次访问，如对时间用CO(S，O)K(1＜K＜M)表示第K个基本访问信息，则统计信息包含了在T时间段内的上述增长量、响
应时间和增长分布值。
应时间和增长分布值。
[0144] 响应时间的定义如下：
[0145]
[0146] Req(S，O)t，max＝MAX(Resplst(m)|1≤m≤M)
[0147] Req(S，O)t，min＝MIN(Resplst(m)|1≤m≤M)
[0148] 增长量参数则定义如下：
[0149] Req(S，O)t，cnt＝Reqcnt(M)-Reqcnt(1)
[0150] 其它Req(S，O)t，cnt、Fault(S，O)t，cnt与此类似；
[0151] 统计信息生成过程可以用伪码描述如下：
[0152] Procedure OnRecieveMessage：
[0153] BEGIN
[0154] GET SERVICE NAME//得到服务名和操作名
[0155] GET OPERATION NAME
[0156] IF INFLOW//消息进入通道，处理请求消息
[0157] SET MESSAGE ID//设置请求消息ID
[0158] SET TIMESTAMP//记录请求进入时间
[0159] INCREASE Global Reqcnt、Service Reqcnt、Operation Reqcnt//全局、服务、方法请求计数递增。
[0160] ELSE IF OUTFLOW//消息输出通道，处理响应消息
[0161] GET MESSAGE ID//设置请求消息ID
[0162] INCREASE Global Respcnt、Service Respcnt、OperationRespcnt//全局、服务、方法请求计数递增。
[0163] SET TIMESTAMP//获得请求进入时间
[0164] ResP Time＝CURRENT TIME-TIMESTAMP//获得响应时间
[0165] INCREASE Global RespT、Service RespTt、Operation RespT//全局、服务、方法请求时间递增。
[0166] ALTER Global Resmax、Respmin、Resplst//更新全局最大、最小、最后响应时间。
[0167] ALTER Service Resmax、Respmin、Resplst//更新当前服务最大、最小、最后响应时间。
[0168] ALTER Operation Resmax、Respmin、Resplst//更新当前方法最大、最小、最后响应时间。
[0169] ELSE IF FAULTFLOW//异常消息处理通道，处理异常消息
[0170] INCREASE Global Faultcnt、Service Faultcnt、Operation Faultcnt//全局、服务、方法请求计数递增。
[0171] RETURN CONTINUE//交给下一消息处理模块
[0172] END
[0173] (3)容器事件获取模块
[0174] 在Axis2中，通过实现AixsObserver接口并相配置到引擎中来监听引擎相关事件。在监控期间，被监控SOAP引擎的服务提供方可能会发布新的Web服务、停止某个Web
服务、更新Web服务甚至动态添加或更新SOAP处理模块等操作。在这些情况下，Web服务
监控模块需要及时得到通知，从而调整重置相关计数，调整监控计划任务。同样对于Web服
务用户也可以基于事件改变绑定策略。
服务、更新Web服务甚至动态添加或更新SOAP处理模块等操作。在这些情况下，Web服务
监控模块需要及时得到通知，从而调整重置相关计数，调整监控计划任务。同样对于Web服
务用户也可以基于事件改变绑定策略。
[0175] (4)系统信息获取模块
[0176] 系统信息基于Windows系统API和JNI实现，由一个后台线程定时获取系统的各项参数，包括Axis2当前进程所占的资源，包括进程所占CPU时间、内存占用量，系统空余内
存量及系统CPU空闲比例，其定时器触发频率为Fsys。
存量及系统CPU空闲比例，其定时器触发频率为Fsys。
[0177] (5)持久化模块
[0178] 由一个后台线程负责定期将数据持久化mysql数据库或文本发明件中(通过配置文件选择，默认持久化数据库中)。其定时器触发频率为Fpers。
[0179] (6)发送模块
[0180] 负责定期将数据转换后的数据发送远程客户端，可以接受两种方式，一种是基于端口(socket)的远程连接请求；另一种是发送到基于AcitiveMQ的队列(默认方式)，监
控用户作为Consumer从JMS队列订阅相应的消息。其定时器触发频率为Fsend。
控用户作为Consumer从JMS队列订阅相应的消息。其定时器触发频率为Fsend。
[0181] (7)过滤模块
[0182] 监控数据采集过滤主要针对以下内容进行：一是只监控待测Web服务，对其它Web服务信息自动滤除。二是针对用户订阅内容的过滤。
[0183] 监控过滤提供三种过滤方式，一类是静态过滤，基于配置文件实现。这种方式是提供需要过滤服务名的列表或正则表达式。系统在启动后将维护一个过滤的服务名称列表，
在拦截时依据匹配情况进行过滤操作，第二种方式是基于接口的过滤，用户根据不同策略
实现相应的接口，并将实现类配置到配置文件中，系统在启动时动态加载相应的过滤实现
类，在拦截相应的SOAP消息时将自动过滤相应的服务。另一类是动态过滤，即Tuner会根据
一定的调整策略对服务过滤列表进行操作。本发明在实现时，采用同种策略，一是减小响应
时间变化量较小的消息拦截频率，另一种策略是减少请求量最大的服务的拦截频率Fitcp。
用户可能通过配置改变过滤策略Fitcp。
在拦截时依据匹配情况进行过滤操作，第二种方式是基于接口的过滤，用户根据不同策略
实现相应的接口，并将实现类配置到配置文件中，系统在启动时动态加载相应的过滤实现
类，在拦截相应的SOAP消息时将自动过滤相应的服务。另一类是动态过滤，即Tuner会根据
一定的调整策略对服务过滤列表进行操作。本发明在实现时，采用同种策略，一是减小响应
时间变化量较小的消息拦截频率，另一种策略是减少请求量最大的服务的拦截频率Fitcp。
用户可能通过配置改变过滤策略Fitcp。
[0184] (8)缓冲模块
[0185] 缓冲模块包括两部分一是发送缓冲，另一部分为持久化缓冲，它们分别由两个不同的CopyOnWriteArrayList链表结构实现。发送模块和拷入化模块定时从链表中取出相
应的内容。这种缓冲结构减少了由于发送或持久化频率太高带来的资源紧张问题。
应的内容。这种缓冲结构减少了由于发送或持久化频率太高带来的资源紧张问题。
[0186] (9)调度模块
[0187] 调度模块负责接受自调整模块的要求，更改相应的调度参数，对发送模块、持久化模块、服务监控模块、系统监控模块、容器事件获取模块及数据处理模块以及过滤模块的调
度周期和调策略进行调整，并进行重新调度运行。
度周期和调策略进行调整，并进行重新调度运行。
[0188] (10)自调整模块
[0189] 自调整模块是系统调整的核心，它负责收集系统资源状态，并根据系统信息生成模块得到的服务响应统计信息依照相应的调整算法计算出调整策略，并给调度模块下达重
新调度指令。在实现时自调整模块也以一个后台线程的形式出现。
新调度指令。在实现时自调整模块也以一个后台线程的形式出现。
[0190] 为了检验Web服务监控模块对服务本身的影响，搭建了独立实验平台如表2所示。
[0191] 表2机器配置列表
[0192]
[0193] 网络环境配置：
[0194] 交换机：TP-LINK TL-SF1008+10M/100M自适应交换机。
[0195] 软件配置：
[0196] Web服务器：Tomcat6+Axis22.11。
[0197] Broker：Tomcat6+Axis22.11。
[0198] 实验结果及其分析如下：
[0199] (1)系统CPU和内存资源达到阀值后的试验结果：
[0200] 图4在是服务端共运行六个服务的监控结果。由三个客户端，通过缓慢增加访问量而使服务端压力增大到系统CPU和内存资源不足而引发调整。
[0201] 其中第一栏为各个服务的响应时间，第二栏为在采样周期内的平均响应时间，而较缓的曲线为整个时间的平均响应时间，第三样为系统内存和CPU的使用情况。第四栏为
在当前周期内请求数的增长情况。
在当前周期内请求数的增长情况。
[0202] 图4是基于以上环境的一个实验结果：由图可以看到在时间点8:24左右系统服务响应时间增大，系统CPU资源与内存资源都剧烈增大，些时自调整功能模块启动，主动降低
了Fpro的结果，则在以后的时间段内平均响应时间均下降。注意在上图中起始段过高是由
于系统预热(warm up)造成的。在系统设计时，初始阶段并不进行调整。
了Fpro的结果，则在以后的时间段内平均响应时间均下降。注意在上图中起始段过高是由
于系统预热(warm up)造成的。在系统设计时，初始阶段并不进行调整。
[0203] 由此可见，当系统资源成为瓶颈时，且平均响应时间增大时，自调整能够较好地适应系统的变化，用户响应时间得到了较好的保障。
[0204] (2)IO资源紧张时调整实验结果：
[0205] 如图5所示，在服务例子中，Bankservice和AddressBookService是操作数据库比较频繁的用例，图5是在客户端访问以上两个服务下的实验结果。
[0206] 由图5可以看到，在时间点10:14:30左右时，由于持久化带来的压力较大，此时响应时间变长，当系统调整了持久化频率Fpers后，系统的响应时间降低而系统内存的资源使
用量立即增加。
用量立即增加。
[0207] (3)网络资源竞争时调整实验结果：
[0208] 图6中除Bankservice和AddressBookService外，LongTextService是一个传输长字符串的服务用例。当其访问量增大时，会给网络传输资源带来压力。如图6可见，在时
间点10:35:45左右，服务延迟增大。此时启动传输频率调整模块，用户的响应时间降低。但
同时内存用量增大，原因是大量的发送内容缓存在内存中所致。
间点10:35:45左右，服务延迟增大。此时启动传输频率调整模块，用户的响应时间降低。但
同时内存用量增大，原因是大量的发送内容缓存在内存中所致。
[0209] 通过以上三个试验结果发现，自调整模块能够较好地在系统资源紧张时参与调整，较好地保证了用户响应时间不受太大影响。但以上结果仅在较为简单的环境下得到的，
对复杂环境下调整模块的工作情况以及选择合适的调整阀值仍需要开展更多的研究和实
验。
对复杂环境下调整模块的工作情况以及选择合适的调整阀值仍需要开展更多的研究和实
验。
[0210] 以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明技术原理的前提下，还可以做出若干改进和变型，这些改进和变型
也应视为本发明的保护范围。
也应视为本发明的保护范围。