CN103873293B - 一种健康探测装置及方法 - Google Patents
一种健康探测装置及方法 Download PDFInfo
- Publication number
- CN103873293B CN103873293B CN201410079007.7A CN201410079007A CN103873293B CN 103873293 B CN103873293 B CN 103873293B CN 201410079007 A CN201410079007 A CN 201410079007A CN 103873293 B CN103873293 B CN 103873293B
- Authority
- CN
- China
- Prior art keywords
- server
- state
- service processes
- threshold
- parameter
- 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
Links
Landscapes
- Computer And Data Communications (AREA)
- Hardware Redundancy (AREA)
- Debugging And Monitoring (AREA)
Abstract
本发明提供一种健康探测装置及方法,应用在负载分担设备上,所述设备与若干个服务器相连,所述装置包括:查询单元,用于周期性发送状态查询指令至各服务器,以便获取某一服务进程在各服务器上的状态参数;判断单元,用于在获取各服务器的状态参数后,根据状态参数,判断各服务器针对所述服务进程的状态为正常、异常或挂起。本发明可以避免服务器负载过重。
Description
技术领域
本发明涉及网络技术领域,尤其涉及一种健康探测装置及方法。
背景技术
随着互联网的飞速发展,大量报文需要服务器进行处理,为了有效的处理这些报文,通常会使用负载分担的方法,也就是用负载分担设备将大量报文分发给多个服务器进行处理。但在对多个服务器进行负载分担之前,要对各服务器进行健康探测,用以判断该服务器是否正常以及是否可以提供相应的服务,以确保通过负载分担设备发送来的业务报文可以得到有效处理。
目前对服务器进行健康探测的算法主要有ICMP(网络控制报文)、FTP(文件传输协议)、HTTP(超文本传送协议)等,这些算法实现主要是基于服务器是否能提供某种服务为参考依据。此外,现有技术在进行负载分担处理时,只知道服务器是否能够处理报文,无法知道服务器进行服务处理的性能。例如,现在有服务器1、服务器2和服务器3,其中,服务器1工作状态异常,已无法正常处理报文,服务器2和3可以正常处理报文,但服务器2的CPU占用率为80%,而服务器3的CPU占用率为30%。现有技术可以获知服务器1工作状态异常,服务器2和服务器3工作状态正常,从而停止向服务器1分发报文,但会继续向服务器2和服务器3分发报文。由于服务器2的CPU占用率已经很高,如果继续向其分发报文,极易负载过重,最终导致服务器瘫痪。因此,如何真实的获取到服务器的处理报文的能力,是一个急需解决的问题。
发明内容
有鉴于此,本发明提供一种健康探测装置,应用在负载分担设备上,所述设备与若干个服务器相连,所述装置包括:
查询单元,用于周期性发送状态查询指令至各服务器,以便获取某一服务进程在各服务器上的状态参数,所述状态参数包括所述服务进程在服务器上的CPU占用率;
判断单元,用于在获取各服务器的状态参数后,根据状态参数,判断各服务器针对所述服务进程的状态为正常、异常或挂起。
本发明还一种健康探测方法,应用在负载分担设备上,所述设备与若干个服务器相连,所述方法包括:
周期性发送状态查询指令至各服务器,以便获取某一服务进程在各服务器上的状态参数,所述状态参数包括所述服务进程在服务器上的CPU占用率;
在获取各服务器的状态参数后,根据状态参数,判断各服务器针对所述服务进程的状态为正常、异常或挂起。
本发明提供的技术方案,可获得各服务器针对各某一个服务进程的处理能力,避免服务器服务负载过重。
附图说明
图1是本发明实施例提供的一种装置的结构示意图。
图2是本发明实施例提供的一种装置的结构示意图。
图3是本发明实施例提供的一种方法的流程示意图。
图4是本发明实施例提供的一种负载分担的方法流程示意图。
具体实施方式
为了使本发明的目的、技术方案及优点更加清楚明白,以下参照附图并举实施例,对本发明所述方案进一步的详细说明。
实施例一
本发明实施例提供一种健康探测装置,应用在负载分担设备上,所述设备与若干个服务器相连,各服务器上可运行若干个服务进程。请参考图1,该装置运行的基本硬件包括CPU、内存、非易失性存储器件以及其他硬件,CPU可通过执行存储器中存储的相关指令来执行相关操作,进而实现健康探测,其他硬件可以包括通信接口等。
具体的,CPU可通过执行相关指令,周期性发送状态查询指令至各服务器,以便获取某一服务进程在各服务器上的状态参数,所述状态参数具体可包括该服务进程在服务器上的CPU占有率,所述的某一服务进程可以是系统中针对某一服务的进程;在获取各服务器的状态参数后,根据状态参数,判断各服务器针对所述服务进程的状态为正常、异常或挂起,也就是获得各服务器针对该某一服务是正常、异常或挂起。这样,该健康探测装置就可以判断出哪一台服务器可以为该服务提供正常的处理能力,来正常处理报文,从而可在利用服务器进行负载分担时,获取各服务器针对某一服务的处理能力为正常、异常或挂起,以便对该服务进行负载分担的处理,这样,对正常的服务器可正常进行报文的负载分担,对异常的服务器则不再进行负载分担,对挂起的服务器可继续负担旧有连接的服务,这样,负载分担设备在进行负载分担时,可根据不同服务器针对不同服务的状态,进行负载分担处理,避免服务器处理能力有限或不能提供该服务的处理而导致服务无法及时处理的问题;同时,也可避免了服务器由于过载而导致瘫痪的问题。
实施例二
本发明实施例提供一种健康探测装置,应用在负载分担设备上,所述设备与若干服务器相连,各服务器上可运行若干个服务进程。该装置包括查询单元01和判断单元02,如图2所示。
其中,查询单元01用于周期性发送状态查询指令至各服务器,以便获取某一服务进程在各服务器上的状态参数,所述状态参数包括所述服务进程在服务器上的CPU占用率。由于所述装置应用在负载分担设备上,而负载分担设备通常会与若干个服务器相连,所以查询单元01在发送状态查询指令的时候,会给每一个服务器发送状态查询指令,且该查询指令是针对一个服务进程的查询,具体实现时可携带表示该服务进程的标识等信息。
另外,由于在每个服务器上,同一时间内通常是会运行多个服务进程的,例如ftpd(文件传送协议驻留程序)、tftpd(文件传送协议驻留服务程序)、httpd(超文本传输送协议守护程序)等,为了能够准确分析出各服务器真实的状态,查询单元01一般会针对某一个服务进程发送状态查询指令,也就是针对某一服务来进行健康探测,这样获取到的服务器状态参数通常是针对该服务进程的,后续判断单元02对于该服务器状态参数的分析通常也是针对该服务进程。
查询单元01除了可以发送状态查询指令至各服务器,还可以向各服务器发送性能查询指令。需要说明的是,为了能够及时获取到各服务器的状态,所以查询单元01会周期性的发送状态查询指令,各服务器在接收到状态查询指令后,会反馈状态参数,这样就能够及时获知该服务器当前状态;而性能查询指令,由于服务器的性能参数基本上不会改变,因此可以是有服务器新加入时发送,以便能够获取该服务器的性能,新加入的服务器接收到性能查询指令后,就会反馈性能参数,以便后续分析,当然,本实施例也不限制按一定的周期发送,或者按需发送,例如需要进行负载分担时发送,以便负载分担时可基于服务器反馈的性能参数进行负载分担。
由上可知,在通过查询单元01的状态查询后,判断单元02会获取到各服务器反馈来的状态参数,判断单元02可以根据所述状态参数,判断该服务器针对所述服务进程的状态为正常,或为异常,或为挂起。其中,所述判断单元02根据状态参数判断该服务器针对所述服务进程的状态的具体过程是:设定第一阈值和第二阈值,其中,第一阈值小于第二阈值;若状态参数小于第一阈值,则判断所述状态为正常;若状态参数大于第一阈值,小于第二阈值,则判断所述状态为挂起;若状态参数大于第二阈值,则判断所述状态为异常。实际应用中,该状态参数也可包括多个不同的值,例如服务器CPU占用率等,这时,可针对不同的参数值设定有不同的阈值范围,以将获得的参数值与相应设定的阈值比较,确定服务器的状态。
这里需进行说明,所述第一阈值和第二阈值,是针对每个服务器上所运行的某一个服务程序的一个状态参数而设定的。也就是说,每一个状态参数都会对应设置第一阈值和第二阈值。而且,每个状态参数之间是“或”的关系,也就是说,在若干个状态参数中,只要有一个状态参数大于第一阈值,小于第二阈值,则判断所述状态为挂起;或者是,在若干个状态参数中,只要有一个状态参数大于第二阈值,则判断所述状态为异常。
具体地,所述服务器的状态参数,除了可以包括服务进程在服务器上的CPU占用率,还可以包括服务器CPU占用率和服务器内存占用率等状态参数,判断单元02可以根据以上状态参数对服务器的状态进行判断。当然,所述状态参数除了可以包括服务器CPU占用率、服务器内存占用率以及进程CPU占用率这三种上述状态参数,还可以根据其他的状态参数,但判断的准确性不如上述三个状态参数高。这里需要说明的是,通常情况下,所述三个状态参数之间是或的判断关系,其具体判断过程,后续部分会进行详细的说明。
举例说明一下,现在有服务器1、服务器2和服务器3,这三台服务器上均运行着服务进程A和服务进程B。查询单元01可向服务器1、服务器2和服务器3分别发送针对服务进程A和服务进程B的状态查询指令,服务器1、服务器2和服务器3则会分别反馈各服务进程相对应的状态参数:服务器CPU占用率、服务器内存占用率及进程CPU占用率,各参数可见表1所示。
表1
表1中,各数值是值的百分数,这里去掉了表分号,实际应用中,也可用小数、百分数表示。可以看出,针对不同的服务进程,各服务器可反馈三个状态参数,也就是状态参数包括三个值。
同时,设备可预先设置有针对不同服务进程的阈值,且针对不同的状态参数设置不同的阈值,以基于该阈值确定服务器的状态。如表2所示。
表2
表2中,针对不同的状态参数分别设置两个阈值,且针对不同的服务进程设置的阈值可不同。实际应用中,也可设置一个阈值。
请参考表1和表2,对两个表中的数据进行分析,判断各服务器针对各服务进程的状态。请看表1,服务器1针对其上运行的服务进程A的服务器CPU占用率、服务器内存占用率、进程CPU占用率分别为90、85、65,再对照表2中服务进程A的服务器CPU占用率、服务器内存占用率、进程CPU占用率对应的第一阈值分别为70、60、70。比较后可以看出,服务器1针对其上运行的服务进程A的服务器CPU占用率大于设定的针对服务进程A的服务器CPU占用率第一阈值,但小于第二阈值,根据该比较可判断服务器状态为挂起;服务器1针对其上运行的服务进程A的服务器内存占用率大于设定的针对服务进程A的服务器内存占用率的第二阈值,根据该比较可判断服务器状态为异常;服务器1针对其上运行的服务进程A的进程CPU占用率小于设定的针对服务进程A的进程CPU占用率的第一阈值,根据该比较可判断服务器状态为正常。由于每个状态参数之间的判断结果是“或”的关系,所以最后可以判定出,服务器1针对服务进程A是异常状态。
根据上述方式,可以从表1和表2判断出,服务器2针对服务进程A是挂起状态,服务器3针对服务进程A是正常状态;服务器1针对服务进程B是异常状态,服务器2针对服务进程B是挂起状态,服务器3针对服务进程B是正常状态。
上述举例是对状态参数包括三个参数值来进行说明,实际应用中,应至少包括服务进程的CPU占用率,以准确获得针对该服务进程的服务器的状态是正常、异常或挂起。也就是说,在实际应用中,可根据需要可获得仅包括服务进程CPU占用率的状态参数,也还可包括服务器CPU占用率和/或服务器内存占用率,以及其他等参数。
此外,如图2所示,本实施例装置还可包括分发单元03,这样,服务器根据性能查询指令反馈的性能参数可由分发单元03来进行分析,以进行负载分担处理。
具体地,所述分发单元03可用于针对服务进程的服务器的状态为挂起的各服务器,停止发送新的连接的该服务进程的报文,以及用于针对服务进程的服务器的状态为异常的各服务器,停止发送该服务进程的所有报文,以及用于针对服务进程的服务器的状态为正常的各服务器,利用负载分担将该服务进程的报文分发至各服务器。
当查询单元01发送性能查询指令,获得各服务器的性能参数后,分发单元03可根据各服务器针对该服务进程的状态和性能参数,利用负载分担分发报文。具体地,分发单元03利用负载分担分发报文,具体可为:用于针对该服务进程的服务器的状态为正常的服务器,根据各服务器的性能参数,确定各服务器的权重,并基于各服务器的权重进行负载分担,将该服务进程的报文发送至各服务器。
其中,所述的性能参数可以包括CPU频率、CPU核数、内存大小,根据这些性能参数,就可以计算出该服务器的权重。例如,各个服务器的权值=CPU频率(单位:MHz)×CPU核数(单位:个)×内存大小(单位:MBytes);各个服务器的权重=各个服务器的权值/所有服务器权值之和,取值为去掉小数后的整数。
在确定了各服务器的权重之后,就可以基于各服务器的权重进行负载分担计算,可以将待发新会话的报文的源IP地址通过哈希(HASH)算法,计算出HASH值;然后将HASH值与所有服务器权重之和进行取余;接着将取余的结果与各服务器的权重进行比较;最后根据比较结果,将所述新会话的报文发送给对应权重的服务器进行处理。
举例说明一下,现在有服务器1、服务器2以及服务器3,这三台服务器的权重分别是20、30及40,现在有一个待发新会话的报文,根据其源IP地址计算出的HASH值为994050049,该HASH值与所有服务器权重之和(20+30+40=90)进行取余的结果为49。该结果大于服务器1的权重,小于服务器1与服务器2权重之和,则该结果所对应的新会话报文应该分发给服务器2;假如另有一个待发的新会话报文,其根据源IP地址计算出的HASH值取余的结果大于服务器1与服务器2的权重之和,则该报文应分发给服务器3;如果有新会话报文取余结果小于或等于服务器1的权重,则该报文应分发给服务器1。
再例如,如果各服务器处理能力相同,也即权重相等,比如都设置权重为10,则三台服务器总权重为30。根据待分发的新会话报文的源IP地址,用HASH算法计算出HASH值为994050049,该HASH值与总权重进行取余的结果为19,该值大于服务器1的权重但小于服务器1与服务器2权重之和,因此该报文分发给服务器2。
这里需要说明的是,由于之前判断单元02是针对某一服务进程判断各服务器的状态,所以分发单元03所分发的新会话报文通常也是指该服务进程的新会话报文,而且所述分发单元03只会给在进行健康探测后,判断针对该服务进程的状态为正常的服务器分发该服务进程的新会话报文。但是对于针对该服务进程状态为挂起或者异常的服务器,分发单元03则不再向该服务器分发该服务进程的新会话报文。具体的说,若服务器的状态为挂起,则不再发送新会话的报文,但已经建立的老会话的报文,由于之前该会话报文已经经过了负载分担计算,并根据计算结果发送给该服务器进行处理,在该服务器的状态为挂起时,所述老会话的报文会继续发送,由其进行处理;若服务器的状态为异常,则不再发送新的报文,同时停止发送已经建立的老会话的报文,而会将该报文重新进行负载分担计算,然后根据计算结果将该老会话的报文转发给其他状态为正常的服务器进行处理。
这里需要说明的是,相对现有服务器,本实施例中可在服务器上集成一个负载分担代理系统LB agent,该代理系统可针对服务器进行自身处理性能参数以及状态参数的收集,以便对负载分担设备发送的状态查询指令和性能查询指令进行反馈相应的状态参数和性能参数。其中,该代理系统可以收集服务器当前运行的各状态参数,例如上述的服务器CPU占用率、各服务进程的CPU占用率、服务器内存占用率等等。实际应用中,该代理系统可以绑定一个TCP端口,该端口可配置,默认可为60000,这样,这个代理系统工作时,就可以实时监听TCP端口,以及时相应负载分担设备发送的查询指令;同样的,负载分担设备在发送查询指令时,也会配置相关参数,例如服务器的IP、端口号等。
需要说明的是,上述的负载分担设备,具体是指可以实现现有服务器负载分担中实现负载分担处理的设备,其具体实现和结构可与现有的相同或类似,在此不再赘述,只是本实施例中可在现有或类似的负载分担设备上集成上述的健康探测装置,以实现健康探测,并可与负载分担设备上已有的负载分担功能结合实现负载分担,且在负载分担计算时可利用上述的负载分担处理方式。
实施例三
本发明提供一种健康探测方法,应用在负载分担设备上,所述设备与若干个服务器相连,各服务器上可以运行若干个服务进程。请参考图3,所述方法可以包括以下步骤:
步骤101,周期性发送状态查询指令至各服务器;
步骤102,在获取所述状态参数后,根据所述状态参数,判断各服务器针对所述服务进程的状态为正常、异常或挂起。
本实施例方法的执行主体具体可以为上述的健康探测装置,或者集成上述健康探测装置或其功能的负载分担设备,以实现对各服务器对报文处理的能力进行健康探测,以便之后进行负载分担。
通过以上步骤,负载分担设备可以获取各服务器针对某一服务进程的状态参数,然后根据获取到的状态参数判断各服务器的状态是正常,还是挂起,还是异常。其具体实现过程可参见上述装置实施例中的相关说明,在此不再赘述。
实施例四
本发明实施例提供一种健康探测方法,应用在负载分担设备上,所述设备与若干个服务器相连,各服务器上可以运行若干个服务进程。请参考图3,所述方法可以包括以下步骤:
步骤101,周期性发送状态查询指令至各服务器。
步骤102,在获取所述状态参数后,根据所述状态参数,判断该服务器针对所述服务进程的状态为正常,或为异常,或为挂起。
其中,根据状态参数判断各服务器针对所述服务进程的状态的具体过程是:设定第一阈值和第二阈值,其中,第一阈值小于第二阈值;若状态参数小于第一阈值,则判断所述状态为正常;若状态参数大于第一阈值,小于第二阈值,则判断所述状态为挂起;若状态参数大于第二阈值,则判断所述状态为异常。
进一步地,该方法在获得各服务器很对该服务进程的状态后,还可执行以下步骤:针对该服务进程的服务器的状态为挂起的各服务器,停止发送新的连接的该服务进程的报文;以及针对该服务进程的服务器的状态为异常的各服务器,停止发送该服务进程的所有报文;以及针对该服务进程的服务器的状态为正常的各服务器,利用负载分担将该服务进程的报文发送至各服务器。
实际应用中,本实施例方法中,还可包括以下步骤:向状态正常的各服务器发送性能查询指令,以便获取各服务器的性能参数。且获取各服务器的性能参数后,还可包括步骤:根据各服务器针对该服务进程的状态和性能参数,利用负载分担分发报文。具体地,利用负载分担报文的具体过程可包括如下步骤,如图4所示:
步骤301,针对所述服务进程的服务器的状态为正常的服务器,根据各服务器的性能参数,确定各服务器的权重。
步骤302,基于各服务器的权重进行负载分担,将该服务进程的报文发送至各服务器。
本实施例方法的具体实现可参见上述装置实施例中的相关说明,其具体实现过程在此不再赘述。
所属领域的技术人员可以清楚的了解到,为了描述的方便和简洁,上述方法的具体工作过程,可以参考前述装置项实施例中的对应过程。
以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本发明保护的范围之内。
Claims (6)
1.一种健康探测装置,应用在负载分担设备上,所述设备与若干个服务器相连,其特征在于,所述装置包括:
查询单元,用于周期性发送状态查询指令至各服务器,以便获取某一服务进程在各服务器上的多个状态参数,所述多个状态参数包括所述服务进程在服务器上的CPU占用率;
判断单元,用于在获取服务器的多个状态参数后,判断每一个状态参数下服务器针对所述服务进程的状态,并结合每一个状态参数下的判断结果最终确定服务器针对所述服务进程的状态为正常、异常或挂起;
所述查询单元,还用于向状态正常的各服务器发送性能查询指令,以便获取各服务器的性能参数;
分发单元,用于针对所述服务进程的服务器的状态为正常的服务器,根据各服务器的性能参数,确定各服务器的权重,并基于各服务器的权重以及所述服务进程待分发的新建会话的报文的报文特征进行负载分担,将该服务进程的报文分发至各服务器。
2.根据权利要求1所述的装置,其特征在于,所述判断单元判断每一个状态参数下服务器针对所述服务进程的状态的具体过程是:设定第一阈值和第二阈值,其中,第一阈值小于第二阈值;若状态参数小于第一阈值,则判断所述状态为正常;若状态参数大于第一阈值,小于第二阈值,则判断所述状态为挂起;若状态参数大于第二阈值,则判断所述状态为异常。
3.根据权利要求1所述的装置,其特征在于,所述分发单元,还用于针对所述服务进程的服务器的状态为挂起的各服务器,停止发送新的连接的该服务进程的报文,以及用于针对所述服务进程的服务器的状态为异常的各服务器,停止发送该服务进程的所有报文。
4.一种健康探测方法,应用在负载分担设备上,所述设备与若干个服务器相连,其特征在于,所述方法包括:
周期性发送状态查询指令至各服务器,以便获取某一服务进程在各服务器上的多个状态参数,所述多个状态参数包括所述服务进程在服务器上的CPU占用率;
在获取服务器的多个状态参数后,判断每一个状态参数下服务器针对所述服务进程的状态,并结合每一个状态参数下的判断结果最终确定服务器针对所述服务进程的状态为正常、异常或挂起;
向状态正常的各服务器发送性能查询指令,以便获取各服务器的性能参数;
针对所述服务进程的服务器的状态为正常的服务器,根据各服务器的性能参数,确定各服务器的权重,并基于各服务器的权重以及所述服务进程待分发的新建会话的报文的报文特征进行负载分担,将该服务进程的报文分发至各服务器。
5.根据权利要求4所述的方法,其特征在于,所述判断每一个状态参数下服务器针对所述服务进程的状态的具体过程是:
设定第一阈值和第二阈值,其中,第一阈值小于第二阈值;
若状态参数小于第一阈值,则判断所述状态为正常;若状态参数大于第一阈值,小于第二阈值,则判断所述状态为挂起;若状态参数大于第二阈值,则判断所述状态为异常。
6.根据权利要求4所述的方法,其特征在于,还包括:
针对所述服务进程的服务器的状态为挂起的各服务器,停止发送新的连接的该服务进程的报文;
针对所述服务进程的服务器的状态为异常的各服务器,停止发送该服务进程的所有报文。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410079007.7A CN103873293B (zh) | 2014-03-05 | 2014-03-05 | 一种健康探测装置及方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410079007.7A CN103873293B (zh) | 2014-03-05 | 2014-03-05 | 一种健康探测装置及方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN103873293A CN103873293A (zh) | 2014-06-18 |
CN103873293B true CN103873293B (zh) | 2018-06-12 |
Family
ID=50911440
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201410079007.7A Active CN103873293B (zh) | 2014-03-05 | 2014-03-05 | 一种健康探测装置及方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN103873293B (zh) |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106302595B (zh) | 2015-06-02 | 2020-03-17 | 阿里巴巴集团控股有限公司 | 一种对服务器进行健康检查的方法及设备 |
CN104993953B (zh) * | 2015-06-19 | 2019-02-26 | 北京奇虎科技有限公司 | 检测网络服务状态的方法和装置 |
CN107911498A (zh) * | 2017-11-24 | 2018-04-13 | 杭州迪普科技股份有限公司 | 一种基于dns代理实现dns解析的方法及装置 |
CN109768896B (zh) * | 2018-12-14 | 2022-03-18 | 平安普惠企业管理有限公司 | 监控服务器环境状态的方法、装置和计算机设备 |
CN110177028B (zh) * | 2019-05-30 | 2021-06-22 | 北京字节跳动网络技术有限公司 | 分布式健康检查方法及装置 |
CN110943887B (zh) * | 2019-11-29 | 2023-04-18 | 广州市百果园信息技术有限公司 | 探针调度方法、装置、设备和存储介质 |
CN111432012A (zh) * | 2020-03-30 | 2020-07-17 | 浙江每日互动网络科技股份有限公司 | 异步通信方法及装置、系统、终端和计算机可读存储介质 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1738244A (zh) * | 2004-08-17 | 2006-02-22 | 北京亿阳巨龙智能网技术有限公司 | 在软交换系统中设置应用服务器的代理服务器的方法 |
CN102360310A (zh) * | 2011-09-28 | 2012-02-22 | 中国电子科技集团公司第二十八研究所 | 一种分布式系统环境下的多任务进程监视方法和监视系统 |
CN102831012A (zh) * | 2011-06-16 | 2012-12-19 | 日立(中国)研究开发有限公司 | 多节点分布式系统中的任务调度装置和任务调度方法 |
CN103118124A (zh) * | 2013-02-22 | 2013-05-22 | 桂林电子科技大学 | 一种基于分层多代理的云计算负载均衡方法 |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7730269B2 (en) * | 2006-08-29 | 2010-06-01 | International Business Machines Corporation | Load management to reduce communication signaling latency in a virtual machine environment |
CN101521604B (zh) * | 2009-04-03 | 2011-04-20 | 南京邮电大学 | 基于策略的分布式性能监测方法 |
CN102404381A (zh) * | 2011-09-02 | 2012-04-04 | 西安交通大学 | 一种云计算环境下基于工作流的软件部署系统及部署方法 |
CN103067297B (zh) * | 2013-01-25 | 2015-10-07 | 中国科学院声学研究所 | 一种基于资源消耗预测的动态负载均衡方法及装置 |
-
2014
- 2014-03-05 CN CN201410079007.7A patent/CN103873293B/zh active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1738244A (zh) * | 2004-08-17 | 2006-02-22 | 北京亿阳巨龙智能网技术有限公司 | 在软交换系统中设置应用服务器的代理服务器的方法 |
CN102831012A (zh) * | 2011-06-16 | 2012-12-19 | 日立(中国)研究开发有限公司 | 多节点分布式系统中的任务调度装置和任务调度方法 |
CN102360310A (zh) * | 2011-09-28 | 2012-02-22 | 中国电子科技集团公司第二十八研究所 | 一种分布式系统环境下的多任务进程监视方法和监视系统 |
CN103118124A (zh) * | 2013-02-22 | 2013-05-22 | 桂林电子科技大学 | 一种基于分层多代理的云计算负载均衡方法 |
Also Published As
Publication number | Publication date |
---|---|
CN103873293A (zh) | 2014-06-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN103873293B (zh) | 一种健康探测装置及方法 | |
US10057296B2 (en) | Detecting and managing abnormal data behavior | |
CN108989136B (zh) | 业务端到端性能监控方法及装置 | |
CN105530138B (zh) | 一种数据监控方法及装置 | |
Kumar | A Review on Client-Server based applications and research opportunity | |
CN105450716B (zh) | 动态业务分发方法及系统 | |
JP2008507010A (ja) | ステートレス通信プロトコルにおけるサーバ状態推測 | |
CN110506259A (zh) | 用于计算节点管理协议的系统和方法 | |
CN103929341B (zh) | 网络性能的测量方法、服务器、网络探针和系统 | |
CN104065538B (zh) | 网络性能的测量控制方法、控制服务器和系统 | |
CN107623685A (zh) | 快速检测SYN Flood攻击的方法及装置 | |
CN108234247A (zh) | 一种检测网络质量的方法和系统 | |
CN104883298A (zh) | 一种业务质量探测方法及路由器 | |
CN106100926A (zh) | 一种网络负载均衡链路健康检查方法 | |
US20190296960A1 (en) | System and method for event processing order guarantee | |
CN107666399A (zh) | 一种监控数据的方法和装置 | |
Huang et al. | Application identification system for SDN QoS based on machine learning and DNS responses | |
CN104219219B (zh) | 一种数据处理的方法、服务器及系统 | |
CN111385328A (zh) | 业务请求的处理方法、系统及电子设备 | |
CN107995199A (zh) | 网络设备的端口限速方法及装置 | |
CN105939404B (zh) | Nat资源的获取方法及装置 | |
CN107911498A (zh) | 一种基于dns代理实现dns解析的方法及装置 | |
CN108011781A (zh) | 基于Linux内核提高网络设备测试性能的方法 | |
CN107547643A (zh) | 一种负载分担方法和装置 | |
US9992073B2 (en) | Network status measuring system and a method for measuring status of a network |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
CB02 | Change of applicant information |
Address after: 310052 Binjiang District Changhe Road, Zhejiang, China, No. 466, No. Applicant after: Xinhua three Technology Co., Ltd. Address before: 310053 Hangzhou hi tech Industrial Development Zone, Zhejiang province science and Technology Industrial Park, No. 310 and No. six road, HUAWEI, Hangzhou production base Applicant before: Huasan Communication Technology Co., Ltd. |
|
CB02 | Change of applicant information | ||
GR01 | Patent grant | ||
GR01 | Patent grant |