CN106161543A - Cgi负载监控方法和装置 - Google Patents

Abstract

本发明涉及一种CGI负载监控方法，所述方法包括：接收来自用户终端的请求；将所述请求分配给CGI进行处理；记录预设数量的所述请求中每个请求的开始时间和结束时间，所述开始时间为CGI开始处理所述请求对应的时间，所述结束时间为CGI处理完所述请求时对应的时间；根据每个请求的所述开始时间和结束时间计算得到CGI负载。还公开一种CGI负载监控装置。本发明可以保证Web服务器的服务质量。

Description

CGI负载监控方法和装置

技术领域

本发明涉及网络数据处理领域，特别是涉及一种CGI负载监控方法和装置。

背景技术

CGI(Common Gateway Interface，通用网关接口)程序是指运行在Web服务器上的一个程序，并由来自于用户终端的输入触发。它能让网络用户访问远程系统上的使用类型程序，就好像他们在实际使用那些远程计算机一样。目前，在Web服务器中还需要大量使用CGI程序。一般情况下，后台管理服务器会根据以往经验针对来自用户终端的请求量和处理每个请求的耗时进行预估以事先设置好CGI的数量。

然而，预估的CGI数量往往和实际需要的CGI数量之间有一定的差距，当用户终端的请求量因市场推广等原因突然增加导致预先设置好的CGI数量不够而超负载时，会影响Web服务器的服务质量。

发明内容

基于此，有必要针对目前事先设置好的CGI数量与实际需要的CGI数量之间存在差距而无法保证Web服务器的服务质量的技术问题，提供一种CGI负载监控方法和装置。

一种CGI负载监控方法，所述方法包括：

接收来自用户终端的请求；

将所述请求分配给CGI进行处理；

记录预设数量的所述请求中每个请求的开始时间和结束时间，所述开始时间为CGI开始处理所述请求对应的时间，所述结束时间为CGI处理完所述请求时对应的时间；

根据每个请求的所述开始时间和结束时间计算得到CGI负载。

一种CGI负载监控装置，所述装置包括：

请求接收模块，用于接收来自用户终端的请求；

分配模块，用于将所述请求分配给CGI进行处理；

记录模块，用于记录预设数量的所述请求中每个请求的开始时间和结束时间，所述开始时间为CGI开始处理所述请求对应的时间，所述结束时间为CGI处理完所述请求时对应的时间；

根据每个请求的所述开始时间和结束时间计算得到CGI负载。

上述CGI负载监控方法和装置，在接收到用户终端发出的请求之后，Web服务器会将所述请求分配给CGI进行处理，同时记录预设数量的所述请求中每个请求的开始时间和结束时间，然后根据每个请求的开始时间和结束时间计算得到所述CGI负载，这样通过监控所述CGI负载的大小，就可以方便后台工作人员在CGI负载超出负载阈值时能够及时调整CGI的数量，保证Web服务器的服务质量。

附图说明

图1为一个实施例中CGI负载监控方法的应用环境图；

图2为另一个实施例中CGI负载监控方法的应用环境图；

图3为一个实施例中图1中的服务器的内部结构示意图；

图4为一个实施例中CGI负载监控方法的流程示意图；

图5为一实施例中循环链表的结构示意图；

图6为图5所示实施例中的循环链表达到最大长度后的结构示意图；

图7为另一个实施例中CGI负载监控方法的流程示意图；

图8为一个具体应用场景中给CGI分配请求的示意图；

图9为图8中CGI的运行示意图；

图10为图9中请求量增加后CGI的运行示意图；

图11为一个实施例中CGI负载监控装置模块图；

图12为另一个实施例中CGI负载监控装置模块图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

本发明实施例所提供的CGI负载监控方法应用于如图1所示的数据处理系统100中，数据处理系统100包括用户终端102和服务器104。其中，用户终端102可以是手机、平板电脑或台式计算机等；服务器104可以是一个或多个服务器。

在另一个实施例中，CGI负载监控方法还可应用于如图2所示的数据处理系统中，其包括用户终端102、Web应用服务器104a和后台管理服务器104b。其中，用户终端102上运行有各种应用程序，至少提供请求的发送功能。所述请求可以为搜索请求、留言请求、消息传递请求等。Web应用服务器104a配置有一定数量的CGI，当用户终端102向Web应用服务器104a发送请求时，Web应用服务器104a会将所述请求分配给各个CGI，各个CGI通过运行CGI程序对所述请求进行相应处理。后台管理服务器104b属于网络监控平台的服务器，用于维护网络数据，网络监控平台的工作人员可以通过后台管理服务器104b编写CGI程序及设置CGI的数量。

在一个实施例中，上述图1中的服务器104的内部结构图如图3所示，包括通过系统总线连接的处理器、内存、存储介质和网络接口。其中，该服务器104的存储介质存储有操作系统、数据库和一种CGI负载监控装置，该CGI负载监控装置用于实现一种CGI负载监控方法。该服务器104的处理器被配置为执行一种CGI负载监控方法。

如图4所示，在一个实施例中，提供了一种CGI负载监控方法，本实施例以该方法应用于上述图1中的服务器来举例说明。该方法具体包括如下步骤：

步骤S402：接收来自用户终端的请求。

具体地，用户终端上运行有请求应用，请求应用的页面中设置有请求触发控件，比如一个按钮或一个超链接。用户通过用户终端的触摸屏、按钮或者轨迹球等输入设备输入触发指令，使得用户终端向Web应用服务器发送请求。该请求可以为搜索请求、留言请求、消息传递请求等。在本实施例中，可以接收来自一个用户终端的一个以上的请求，也可以接收来自两个以上用户终端的请求。

步骤S404：将所述请求分配给CGI进行处理。

具体地，通用网关接口(Common Gateway Interface)简称CGI，是一个在Web服务器中使用的技术。在物理层次上它是一段运行在Web服务器上的程序，能够让用户与Web服务器进行交互。比如，一群通信用户在其组建的固定人数的通信社区中进行交流时，每个通信用户可以通过用户终端在所述通信社区中传递一些信息，如链接网址、通知等，待需要传递的信息输入完毕后触发信息发送指令。Web应用服务器接收来自用户终端的请求之后，便会把这些请求分配给各个CGI，于是CGI在Web应用服务器上按照预定的方法对所述请求进行处理。在CGI处理完所述请求之后，Web应用服务器会给用户终端发送一个反馈信息(即其中一个通信用户刚才发送的信息)，这样所述通信社区中的所有通信用户都能看到所述反馈信息以进行交流。这里的请求是消息传递请求，可以理解，如果用户通过用户终端发送的是一个搜索请求，那么CGI程序在处理完毕后给用户终端发送的反馈信息就是搜索的结果。

在一个实施例中，CGI的数量是根据存储的历史请求预先设置的。比如，在步骤S402之前，后台管理服务器根据存储的历史请求配置了10个CGI，那么在步骤S404中，Web应用服务器便会将从用户终端接收的请求分配给这10个CGI进行处理。

步骤S406：记录预设数量的所述请求中每个请求的开始时间和结束时间。

具体地，所述开始时间为CGI开始处理所述请求对应的时间，所述结束时间为CGI处理完所述请求时对应的时间。这里的开始时间和结束时间为绝对时间。比如，Web应用服务器接收了一个请求，并将所述请求分配给CGI进行处理，这样CGI开始处理所述请求和处理完所述请求都会有一个对应的时间。这里需要将CGI开始处理所述请求所对应的时间和处理完所述请求所对应的时间全部记录下来。

在一个实施例，步骤S406包括：创建一个长度与所述预设数量相匹配的循环链表；按照接收请求的顺序依次将每个请求的开始时间和结束时间插入到所述循环链表中。

举例说明，若步骤S406中需要记录1000个请求中每个请求的开始时间和结束时间，那么这里就创建一个长度为1000的循环链表。链表由一系列结点(链表中每一个元素称为结点)组成，结点可以在运行时动态生成。每个结点包括两个部分：一个是存储数据元素的数据域，另一个是存储下一个结点地址的指针域。循环链表则是另一种形式的链式存贮结构，它的特点是表中最后一个结点的指针域指向头结点，整个链表形成一个环。

在本实施例中，每个请求的开始时间和结束时间作为一个整体的数据元素存储在所述循环链表中结点的数据域中。这里的预设数量为500～1500，优选地，预设数量为1000。

进一步地，在一个实施例中，按照接收请求的顺序依次将每个请求的开始时间和结束时间插入所述循环链表之后还包括在检测到所述循环链表达到最大长度时，删除所述循环链表中最先插入的请求的开始时间和结束时间，并插入下一个请求的开始时间和结束时间的步骤。

具体地，如图5所示，为一实施例中循环链表的结构示意图。按照接收请求的顺序依次将每个请求的开始时间和结束时间插入到所述循环链表中，因为该循环链表的长度为1000，所述最多只能将1000个请求的开始时间和结束时间插入到所述循环链表中。其中，p指针指向的数据域中插入的是当前循环链表中第一个请求的开始时间和结束时间，q指针指向的数据域中插入的是当前循环链表中最后一个请求的开始时间和结束时间。在本实施例中，q指针指向的数据域中插入的是第1000个请求的开始时间和结束时间，说明所述循环链表已经达到最大长度。在检测到该循环链表达到最大长度时，第一个请求的开始时间和结束时间会被删除，并插入下一个请求的开始时间和结束时间，即第1001个请求的开始时间和结束时间。

如图6所示，为图5所示实施例中的循环链表达到最大长度后的结构示意图。删除请求后的循环链表变为：P指针指向的数据域中插入的是第二个请求的开始时间和结束时间，q指针指向的数据域中插入的是第1001个请求的开始时间和结束时间。以此类推，这样可以保证用户终端发送的下一个请求的开始时间和结束时间能够插入到所述循环链表中以实现CGI负载监控的实时性。

步骤S408：根据每个请求的开始时间和结束时间计算得到CGI负载。

具体地，每个请求经CGI处理的过程中都对应一个开始时间和一个结束时间。在CGI处理完预设数量的所述请求的这段时间内，每个CGI又包括处理请求的时间和空闲时间。比如：设预设数量为1000，每个请求的结束时间减去其开始时间为5ms，那么说明每个请求经CGI处理所花费的时间为5ms。假设第1000个请求的结束时间减去第一个请求的开始时间为1s，那么说明在CGI处理1000个请求所经历的时间为1s，在这1s内，每个CGI又包括处理请求的时间和空闲时间。

在一个实施例中，步骤S408包括：根据每个请求的开始时间和结束时间分别获取第一总时长和第二总时长，其中，所述第一总时长为预设数量的所述请求中每个请求经CGI处理所花费的时间的总和，所述第二总时长为CGI处理预设数量的所述请求的时间段内每个CGI处理请求所花费的时间和空闲时间的总和；计算所述第一总时长占所述第二总时长的比值作为所述CGI负载。

具体地，上述例中，每个请求经CGI处理所花费的时间为5ms，则1000个请求经CGI处理所花费的时间总和为5s(5ms*1000)，即第一总时长为5s。CGI处理1000个请求所经历的时间为1s，则说明每个CGI处理请求所花费的时间和空闲时间共为1s，假如总共有10个CGI，则CGI处理预设数量的所述请求所经历的时间内每个CGI处理请求所花费的时间和空闲时间的总和为10s(1s*10)，即第二总时长为10s。那么所述第一总时长占所述第二总时长的比值为5s/10s等于50％，即所述CGI负载为50％。

图7所示，在另一个实施例中，提供了一种CGI负载监控方法，本实施例以该方法应用于上述图1中的服务器来举例说明。该方法具体包括如下步骤：

步骤S702：接收来自用户终端的请求。

具体地，用户终端上运行有请求应用，请求应用的页面中设置有请求触发控件，比如一个按钮或一个超链接。用户通过用户终端的触摸屏、按钮或者轨迹球等输入设备输入触发指令，使得用户终端向Web应用服务器发送请求。该请求可以为搜索请求、留言请求、消息传递请求等。在本实施例中，可以接收来自一个用户终端的一个以上的请求，也可以接收来自两个以上用户终端的请求。

步骤S704：将所述请求分配给CGI进行处理。

Web应用服务器在接收到来自用户终端的请求时，便会把这些请求分配给CGI进行处理。在CGI处理完所述信息发送请求之后，Web应用服务器会给用户终端发送一个反馈信息以表示CGI已处理完所述请求。

步骤S706：记录预设数量的所述请求中每个请求的开始时间和结束时间。

具体地，所述开始时间为CGI开始处理所述请求对应的时间，所述结束时间为CGI处理完所述请求时对应的时间。这里的开始时间和结束时间为绝对时间。比如，Web应用服务器接收了一个请求，并将所述请求分配给CGI进行处理，这样CGI开始处理所述请求和处理完所述请求都会有一个对应的时间。这里需要将CGI开始处理所述请求所对应的时间和处理完所述请求所对应的时间全部记录下来。

步骤S708：根据每个请求的开始时间和结束时间计算得到CGI负载。

具体地，每个请求经CGI处理的过程中都对应一个开始时间和一个结束时间。在CGI处理完预设数量的所述请求的这段时间内，每个CGI又包括处理请求的时间和空闲时间。比如：设预设数量为1000，每个请求的结束时间减去其开始时间为5ms，那么说明每个请求经CGI处理所花费的时间为5ms。假设第1000个请求的结束时间减去第一个请求的开始时间为1s，那么说明在CGI处理1000个请求所经历的时间为1s，在这1s内，每个CGI又包括处理请求的时间和空闲时间。

在一个实施例中，步骤S708包括：根据每个请求的开始时间和结束时间分别获取第一总时长和第二总时长，其中，所述第一总时长为预设数量的所述请求中每个请求经CGI处理所花费的时间的总和，所述第二总时长为CGI处理预设数量的所述请求的时间段内每个CGI处理请求所花费的时间和空闲时间的总和；计算所述第一总时长占所述第二总时长的比值作为所述CGI负载。

具体地，上述例中，每个请求经CGI处理所花费的时间为5ms，则1000个请求经CGI处理所花费的时间总和为5s(5ms*1000)，即第一总时长为5s。CGI处理1000个请求所经历的时间为1s，则说明每个CGI处理请求所花费的时间和空闲时间共为1s，假如总共有5个CGI，则CGI处理预设数量的所述请求所经历的时间内每个CGI处理请求所花费的时间和空闲时间的总和为5s(1s*5)，即第二总时长为5s。那么所述第一总时长占所述第二总时长的比值为5s/5s等于100％，即所述CGI程序的负载为100％。

步骤S710：在检测到所述负载大于负载阈值时发送报警信号给后台管理服务器。

具体地，CGI负载越小，说明不需要增加CGI的数量，目前的CGI能够很好地处理用户终端发送过来的请求以保证服务的实时性能。相反，如果CGI负载越大，比如大于90％，则说明当前CGI负载较重，需要增加CGI的数量以分摊处理请求，使服务的实时性能更好。这时，则会向后台管理服务器发送报警信号，以及时通知后台的工作人员对CGI的数量进行调整。在本实施例中，所述负载阈值为90％。可以理解，在其他实施例中，还可以根据实际情况将所述负载阈值设置在80％～100％之间，这里不作严格限制。

步骤S712：根据所述CGI负载调节CGI的数量。

在发送报警信号给后台管理服务器之后，说明需要对CGI的数量进行调节。后台的工作人员会及时通过后台管理服务器向Web服务器发送调节命令，这样Web服务器收到调节命令后就可以根据所述CGI负载调节CGI的数量。

上述CGI负载监控方法，在接收到用户终端发出的请求之后，Web服务器会将所述请求分配给CGI进行处理，同时记录预设数量的所述请求中每个请求的开始时间和结束时间，然后根据每个请求的开始时间和结束时间计算得到所述CGI负载，这样通过监控所述CGI负载的大小，就可以方便后台工作人员在CGI负载超出负载阈值时能够及时调整CGI的数量，保证Web服务器的服务质量。

下面用两个具体应用场景来说明上述CGI负载监控方法的原理，这两个应用场景以CGI处理通信用户在其组建的固定人数的通信社区中发送的消息传递请求为例进行说明。

第一个应用场景请参照图8，Web应用服务器配置有10个CGI。假设目前所述通信社区中只有少数的通信用户在交流。通信用户通过用户终端向Web应用服务器发送消息传递请求，Web应用服务器在接收来自用户终端的消息传递请求后，并将所述消息传递请求分配给这10个CGI进行处理，CGI对所述消息传递请求进行处理后会把处理结果通过Web应用服务器发送给用户终端，即消息传递成功，所述通信社区中的所有通信用户都能看到其中任何一个通信用户传递的消息以进行交流。这时10个CGI的运行图如图9所示。

假设CGI处理每个消息传递请求的时长为5ms，图中填充有网格的CGI表示正在处理请求的CGI，没有填充的CGI表示空闲的CGI。从图中可以看出，一定时间内，每个请求经CGI处理所花费的时间总和等于25ms(5ms+5ms+5ms+5ms+5ms)，而10个CGI处理这些请求所花费的时间和空闲时间的总和为50ms(5ms+5ms+5ms+5ms+5ms+5ms+5ms+5ms+5ms+5ms)，则CGI负载为25ms/50ms＝50％。

因为上述场景中只有少数的通信用户通过用户终端在发送消息传递请求，通过根据该消息传递请求的开始时间和结束时间计算出CGI的负载比较小，Web应用服务器中预先配置的CGI能够很好地处理这些请求，这样就不会发送报警信号给后台管理服务器。

第二个应用场景请继续参照图8，Web应用服务器配置有10个CGI。假设目前所述通信社区中几乎所有的通信用户都在线交流，即在图9的基础上增加了请求量(请求量是指单位时间内请求的数量)。通信用户通过用户终端向Web应用服务器发送消息传递请求，Web应用服务器在接收来自用户终端的消息传递请求后，并将所述消息传递请求分配给这10个CGI进行处理，CGI对所述消息传递请求进行处理后会把处理结果通过Web应用服务器发送给用户终端，即消息传递成功，所述通信社区中的所有通信用户都能看到其中任何一个通信用户传递的消息以进行交流。这时10个CGI的运行图如图10所示。

CGI处理每个消息传递请求的时长为5ms，图中填充有网格的CGI表示正在处理请求的CGI。从图中可以看出，一定时间内，每个请求经CGI处理所花费的时间总和等于50ms(5ms+5ms+5ms+5ms+5ms+5ms+5ms+5ms+5ms+5ms)，而10个CGI处理这些请求所花费的时间和空闲时间的总和也为50ms(5ms+5ms+5ms+5ms+5ms+5ms+5ms+5ms+5ms+5ms)，则CGI负载为50ms/50ms＝100％。

上述场景中有很多个通信用户同时或短时间内(10s以内)通过用户终端在发送消息传递请求，请求量增加了。根据该请求的开始时间和结束时间计算出CGI的负载为100％(大于90％)，说明Web应用服务器中预先配置的CGI数量不能够支持它很好地或者说接下来实时地处理这些请求，这时便会向后台管理服务器发送报警信号，以便后台工作人员能够及时调整CGI的数量，保证Web服务器的服务质量。

如图11所示，在一个实施例中，提供了一种CGI负载监控装置1100，具有实现上述各个实施例的CGI负载监控方法的功能。该CGI负载监控装置1100包括请求接收模块1102、分配模块1104、记录模块1106及计算模块1108。

请求接收模块1102，用于接收来自用户终端的请求。

具体地，用户终端上运行有请求应用，请求应用的页面中设置有请求触发控件，比如一个按钮或一个超链接。用户通过用户终端的触摸屏、按钮或者轨迹球等输入设备输入触发指令，使得用户终端向Web应用服务器发送请求。该请求可以为搜索请求、留言请求、消息传递请求等。在本实施例中，可以接收来自一个用户终端的一个以上的请求，也可以接收来自两个以上用户终端的请求。

分配模块1104，用于将所述请求分配给CGI进行处理。

具体地，通用网关接口(Common Gateway Interface)简称CGI，是一个在Web服务器中使用的技术。在物理层次上它是一段运行在Web服务器上的程序，能够让用户与Web服务器进行交互。比如，一群通信用户在其组建的固定人数的通信社区中进行交流时，每个通信用户可以通过用户终端在所述通信社区中传递一些信息，如链接网址、通知等，待需要传递的信息输入完毕后触发信息发送指令。Web应用服务器接收来自用户终端的请求之后，便会把这些请求分配给各个CGI，于是CGI在Web应用服务器上按照预定的方法对所述请求进行处理。在CGI处理完所述请求之后，Web应用服务器会给用户终端发送一个反馈信息(即其中一个通信用户刚才发送的信息)，这样所述通信社区中的所有通信用户都能看到所述反馈信息以进行交流。这里的请求是消息传递请求，可以理解，如果用户通过用户终端发送的是一个搜索请求，那么CGI程序在处理完毕后给用户终端发送的反馈信息就是搜索的结果。

记录模块1106，用于记录预设数量的所述请求中每个请求的开始时间和结束时间。

具体地，所述开始时间为CGI开始处理所述请求对应的时间，所述结束时间为CGI处理完所述请求时对应的时间。这里的开始时间和结束时间为绝对时间。比如，Web应用服务器接收了一个请求，并将所述请求分配给CGI进行处理，这样CGI开始处理所述请求和处理完所述请求都会有一个对应的时间。这里需要将CGI开始处理所述请求所对应的时间和处理完所述请求所对应的时间全部记录下来。

在一个实施例，记录模块1106包括循环链表创建单元和插入单元，所述循环链表创建单元用于创建一个长度与所述预设数量相匹配的循环链表，所述插入单元用于将每次请求的开始时间和结束时间插入到所述循环链表中。

举例说明，若记录模块1106需要记录1000个请求中每个请求的开始时间和结束时间，那么这里就创建一个长度为1000的循环链表。链表由一系列结点(链表中每一个元素称为结点)组成，结点可以在运行时动态生成。每个结点包括两个部分：一个是存储数据元素的数据域，另一个是存储下一个结点地址的指针域。循环链表则是另一种形式的链式存贮结构，它的特点是表中最后一个结点的指针域指向头结点，整个链表形成一个环。

在本实施例中，每个请求的开始时间和结束时间作为一个整体的数据元素存储在所述循环链表中结点的数据域中。这里的预设数量为500～1500，优选地，预设数量为1000。

进一步地，在一个实施例中，还包括删除单元，用于在检测到所述循环链表达到最大长度时，删除所述循环链表中最先插入的请求的开始时间和结束时间，并通过所述插入单元插入下一个请求的开始时间和结束时间。

计算模块1108，用于根据每个请求的开始时间和结束时间计算得到CGI负载。

具体地，每个请求经CGI处理的过程中都对应一个开始时间和一个结束时间。在CGI处理完预设数量的所述请求的这段时间内，每个CGI又包括处理请求的时间和空闲时间。比如：设预设数量为1000，每个请求的结束时间减去其开始时间为5ms，那么说明每个请求经CGI处理所花费的时间为5ms。假设第1000个请求的结束时间减去第一个请求的开始时间为1s，那么说明在CGI处理1000个请求所经历的时间为1s，在这1s内，每个CGI又包括处理请求的时间和空闲时间。

在一个实施例中，计算模块1108包括时长获取单元和计算单元，所述时长获取单元用于根据每个请求的开始时间和结束时间分别获取第一总时长和第二总时长，其中，所述第一总时长为预设数量的所述请求中每个请求经CGI处理所花费的时间的总和，所述第二总时长为CGI处理预设数量的所述请求的时间段内每个CGI处理请求所花费的时间和空闲时间的总和。所述计算单元用于计算所述第一总时长占所述第二总时长的比值作为所述CGI负载。

具体地，上述例中，每个请求经CGI处理所花费的时间为5ms，则1000个请求经CGI处理所花费的时间总和为5s(5ms*1000)，即第一总时长为5s。CGI处理1000个请求所经历的时间为1s，则说明每个CGI处理请求所花费的时间和空闲时间共为1s，假如总共有10个CGI，则CGI处理预设数量的所述请求所经历的时间内每个CGI处理请求所花费的时间和空闲时间的总和为10s(1s*10)，即第二总时长为10s。那么所述第一总时长占所述第二总时长的比值为5s/10s等于50％，即所述CGI负载为50％。

如图12所示，在另一个实施例中，提供了一种CGI负载监控装置1200，具有实现上述各个实施例的CGI负载监控方法的功能。该CGI负载监控装置1200包括请求接收模块1202、分配模块1204、记录模块1206及计算模块1208。

请求接收模块1202用于接收来自用户终端的请求，分配模块1204用于将所述请求分配给CGI进行处理，记录模块1206用于记录预设数量的所述请求中每个请求的开始时间和结束时间，计算模块1208用于根据每个请求的开始时间和结束时间计算得到CGI负载。以上模块的功能描述具体可参照对图11所示的CGI负载监控装置1100的描述，这里不再赘述。

本实施例中的CGI负载监控装置1200与图11所示的CGI负载监控装置1100的不同之处在于，CGI负载监控装置1200还包括报警模块1210和调节模块1212。报警模块1210用于在检测到所述CGI负载大于负载阈值时发送报警信号给后台管理服务器，调节模块1212用于根据所述CGI负载调节CGI的数量。

具体地，CGI负载越小，说明不需要增加CGI的数量，目前的CGI能够很好地处理用户终端发送过来的请求以保证服务的实时性能。相反，如果CGI负载越大，比如大于90％，则说明当前CGI负载较重，需要增加CGI的数量以分摊处理请求，使服务的实时性能更好。这时，则会向后台管理服务器发送报警信号，以及时通知后台的工作人员对CGI的数量进行调整。在本实施例中，所述负载阈值为90％。可以理解，在其他实施例中，还可以根据实际情况将所述负载阈值设置在80％～100％之间，这里不作严格限制。

在发送报警信号给后台管理服务器之后，说明需要对CGI的数量进行调节。后台的工作人员会及时通过后台管理服务器向Web服务器发送调节命令，这样Web服务器收到调节命令后就可以根据所述CGI负载调节CGI的数量。

上述CGI负载监控装置，请求接收模块在接收到用户终端发出的请求之后，Web服务器中的分配模块会将所述请求分配给CGI进行处理，同时记录模块会记录预设数量的所述请求中每个请求的开始时间和结束时间，然后计算模块根据每个请求的开始时间和结束时间计算得到所述CGI负载，这样通过监控所述负载的大小，就可以方便后台工作人员在CGI负载超出负载阈值时能够及时调整CGI的数量，保证Web服务器的服务质量。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)等非易失性存储介质，或随机存储记忆体(Random Access Memory，RAM)等。

以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种CGI负载监控方法，所述方法包括：

接收来自用户终端的请求；

将所述请求分配给CGI进行处理；

记录预设数量的所述请求中每个请求的开始时间和结束时间，所述开始时间为CGI开始处理所述请求对应的时间，所述结束时间为CGI处理完所述请求时对应的时间；

根据每个请求的所述开始时间和结束时间计算得到CGI负载。

2.根据权利要求1所述的方法，其特征在于，所述记录预设数量的所述请求中每个请求的开始时间和结束时间的步骤，包括：

创建一个长度与所述预设数量相匹配的循环链表；

按照接收请求的顺序依次将每个请求的开始时间和结束时间插入到所述循环链表中。

3.根据权利要求2所述的方法，其特征在于，所述按照接收请求的顺序依次将每个请求的开始时间和结束时间插入所述循环链表的步骤之后，还包括：

在检测到所述循环链表达到最大长度时，删除所述循环链表中最先插入的请求的开始时间和结束时间，并插入下一个请求的开始时间和结束时间。

4.根据权利要求1所述的方法，其特征在于，所述根据每个请求的开始时间和结束时间计算出所述通用网关接口程序的负载，包括：

根据每个请求的开始时间和结束时间分别获取第一总时长和第二总时长，其中，所述第一总时长为预设数量的所述请求中每个请求经CGI处理所花费的时间的总和，所述第二总时长为CGI处理预设数量的所述请求所经历的时间内每个CGI处理请求所花费的时间和空闲时间的总和；

计算所述第一总时长占所述第二总时长的比值作为所述CGI负载。

5.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在检测到所述CGI负载大于负载阈值时发送报警信号给后台管理服务器；

根据所述CGI负载调节CGI的数量。

6.一种CGI负载监控装置，所述装置包括：

请求接收模块，用于接收来自用户终端的请求；

分配模块，用于将所述请求分配给CGI进行处理；

记录模块，用于记录预设数量的所述请求中每个请求的开始时间和结束时间，所述开始时间为CGI开始处理所述请求对应的时间，所述结束时间为CGI处理完所述请求时对应的时间；

根据每个请求的所述开始时间和结束时间计算得到CGI负载。

7.根据权利要求6所述的装置，其特征在于，所述记录模块包括：

循环链表创建单元，用于创建一个长度与所述预设数量相匹配的循环链表；

插入单元，用于按照接收请求的顺序依次将每次请求的开始时间和结束时间插入到所述循环链表中。

8.根据权利要求7所述的装置，其特征在于，所述记录模块还包括：

删除单元，用于在检测到所述循环链表达到最大长度时，删除所述循环链表中最先插入的请求的开始时间和结束时间，并通过所述插入单元插入下一个请求的开始时间和结束时间。

9.根据权利要求6所述的装置，其特征在于，所述计算模块包括：

时长获取单元，用于根据每个请求的开始时间和结束时间分别获取第一总时长和第二总时长，其中，所述第一总时长为预设数量的所述请求中每个请求经CGI处理所花费的时间的总和，所述第二总时长为CGI处理预设数量的所述请求所经历的时间内每个CGI处理请求所花费的时间和空闲时间的总和；

计算单元，用于计算所述第一总时长占所述第二总时长的比值作为所述CGI负载。

10.根据权利要求6所述的装置，其特征在于，所述装置还包括：

报警模块，用于在检测到所述CGI负载大于负载阈值时发送报警信号给后台管理服务器；

调节模块，用于根据所述CGI负载调节CGI的数量。