CN105991741A - 显示负载请求的方法、装置及网络服务器 - Google Patents

Abstract

本申请提供一种显示负载请求的方法、装置及网络服务器，该方法包括：从所述网络服务器实时采集需要处理的负载请求个数；从所述网络服务器实时采集已处理的负载请求个数；将所述需要处理的负载请求个数和所述已处理的负载请求个数的差值作为第一负载曲线观测值进行动态显示。本发明的技术方案能够直观地展示出网络服务器的负载请求的情况，清晰地观察网络服务器的负载状态。

Description

显示负载请求的方法、装置及网络服务器

技术领域

本申请涉及互联网技术领域，尤其涉及一种显示负载请求的方法、装置及网络服务器。

背景技术

在现有技术中，通过在一段时间内对web服务器的中央处理器(CenterProcess Unit，简称为CPU)正在处理的进程数以及等待CPU处理的进程数进行统计，即对CPU使用队列的长度进行统计，根据统计结果来衡量CPU的负载情况；通过单秒处理请求数和响应时间等参数来衡量服务器的负载情况以及服务器的性能。由于上述各个指标并不能直观的展示出web服务器运行时的超文本传送协议(HTTP-Hypertext transfer protocol，简称为http)请求负载情况，致使无法直观地得到web请求数负载的变化趋势，进而不能清晰的了解web服务器的请求数负载情况。

发明内容

有鉴于此，本申请提供一种新的技术方案，可以解决无法直观地得到网络服务器的负载请求数的变化趋势，进而不能清晰的了解网络服务器的负载请求数情况的技术问题。

为实现上述目的，本申请提供技术方案如下：

根据本发明的第一方面，提出了一种显示负载请求的方法，包括：

从网络服务器实时采集需要处理的负载请求个数；

从所述网络服务器实时采集已处理的服务器请求个数；

将所述需要处理的负载请求个数和所述已处理的负载请求个数的差值作为第一负载曲线观测值进行动态显示。

根据本发明的第二方面，提出了一种显示负载请求的装置，包括：

第一采集模块，用于从网络服务器实时采集需要处理的负载请求个数；

第二采集模块，用于从所述网络服务器实时采集已处理的服务器请求个数；

第一显示模块，用于将所述第一采集模块采集到的所述需要处理的服务器请求个数和所述第二采集模块采集到的所述已处理的服务器请求个数的差值作为第一负载曲线观测值进行动态显示。

根据本发明的第三方面，提出了一种网络服务器，所述网络服务器包括：

处理器；用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为：

实时采集需要处理的负载请求个数；

实时采集所述网络服务器已处理的负载请求个数；

将所述需要处理的负载请求个数和所述已处理的负载请求个数的差值作为第一负载曲线观测值进行动态显示。

由以上技术方案可见，通过从网络服务器实时采集需要处理的负载请求个数和已处理的负载请求个数，将需要处理的负载请求个数和已处理的负载请求个数的差值作为第一负载曲线观测值进行动态显示，当第一负载曲线观测值为正数时表示网络服务器处理能力足够，处理完成的负载请求数大于需要处理的负载请求数，当第一负载曲线观测值为负数时表示网络服务器超负载，当第一负载曲线观测值维持在0值附近时表示网络服务器处于正常状态，从而能够直观地展示出网络服务器的负载请求的情况，清晰地观察网络服务器的负载状态。

附图说明

图1A示出了根据本发明的一示例性实施例的显示负载请求的方法的流程示意图；

图1B示出了根据本发明一示例性实施例的第一负载曲线观测值的曲线示意图；

图1C示出了根据本发明一示例性实施例的第二负载曲线观测值与第三负载曲线观测值的曲线示意图；

图2示出了根据本发明的又一示例性实施例的显示负载请求的方法的流程示意图；

图3示出了根据本发明的再一示例性实施例的显示负载请求的方法的流程示意图；

图4A示出了根据本发明的另一示例性实施例的显示负载请求的方法的流程示意图；

图4B示出了根据本发明的另一示例性实施例的第四负载曲线观测值与第三负载曲线观测值的曲线示意图；

图5示出了根据本发明的一示例性实施例的网络服务器的结构示意图；

图6示出了根据本发明的一示例性实施例的显示负载请求的装置的结构示意图；

图7示出了根据本发明的又一示例性实施例的显示负载请求的装置的结构示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

本申请通过从网络服务器实时采集需要处理的负载请求个数和已处理的负载请求个数，将需要处理的负载请求个数和已处理的负载请求个数的差值作为第一负载曲线观测值进行动态显示，当第一负载曲线观测值为正数时表示网络服务器处理能力足够，处理完成的负载请求数大于需要处理的负载请求数，当第一负载曲线观测值为负数时表示网络服务器超负载，当第一负载曲线观测值维持在0值附近时表示网络服务器处于正常状态，从而能够直观地展示出网络服务器的负载请求负载的情况，清晰地观察网络服务器的负载状态。

为对本申请进行进一步说明，提供下列实施例：

请参考图1A，为根据本发明的一示例性实施例的显示负载请求的方法的流程示意图，包括如下步骤：

步骤101，从网络服务器实时采集需要处理的负载请求个数。

步骤102，从网络服务器实时采集已处理的负载请求个数。

步骤103，将需要处理的负载请求个数和已处理的负载请求个数的差值作为第一负载曲线观测值进行动态显示。

上述步骤101和步骤102中，以网络服务器为web服务器，负载请求为http请求为例进行示例性说明，可以通过Java的代理技术和字节码技术在不重启Web容器及不修改SVN(Subversion)源码的基础上采集web容器需要处理的http请求个数，其中，web容器是web服务器上运行的应用程序，用于处理从客户端发出的http请求，web容器例如为JAVA中的Tomcat容器、Jetty容器等。

在一实施例中，可以在Web容器处理请求的开始位置加入用于统计需要处理的http请求个数的字节码，从而统计需要处理的http请求个数，在Web容器处理请求结束的位置加入用于统计已处理的http请求个数的字节码，从而统计web容器已处理完成的http请求个数。本领域技术人员可以理解的是，针对具体不同的Java类web容器和不同的web应用框架，本发明实施例在web服务器中注入的字节码的位置会有不同。

上述步骤103中，在一实施例中，如图1B所示，需要处理的http请求个数和已处理的http请求个数的差值作为第一负载曲线观测值，在持续时间为0-36秒之间的时间段内，第一负载曲线观测值的最大值为12，最小值为0，在这36秒内的平均值为0个http请求，从而可以说明在0-36秒的时间段内，web服务器处于正常的处理http请求的状态。

本领域技术人员可以理解的是，本发明实施例中的网络服务器可以为文件传输协议(File Transfer Protocol，简称为FTP)服务器、域名系统(DomainName System，简称为DNS)服务器、简单邮件传输协议(Simple Mail TransferProtocol，简称为SMTP)服务器，相应地，负载请求可以为FTP下载文件请求、DNS域名解析请求、SMTP发送邮件请求，因此上述web服务器的示例性说明不能形成对本发明实施例的限制。

由上述实施例可知，本发明实施例将需要处理的负载请求个数和已处理的负载请求个数的差值作为第一负载曲线观测值进行动态显示，当第一负载曲线观测值为正数时表示网络服务器处理能力足够，处理完成的请求数大于需要处理的请求数，当第一负载曲线观测值为负数时表示网络服务器超负载，当第一负载曲线观测值维持在0值附近时表示网络服务器处于正常状态，实现了基于具体的负载请求个数的维度对网络服务器处理负载请求时的压力大小进行统计，能够直观地展示出网络服务器的负载请求的情况清晰地观察web服务器的负载状态。

图1C示出了根据本发明一示例性实施例的第二负载曲线观测值与第三负载曲线观测值的曲线示意图，在上述图1B所示的需要处理的http请求个数和已处理的http请求个数的差值作为第一负载曲线观测值进行显示的基础上，如图1C所示，本公开实施例还可以将需要处理的http请求个数和已处理的http请求个数分别作为第二负载曲线观测值和第三负载曲线观测值进行动态显示，图1C中的不带有圆点的曲线表示需要处理的http请求个数(第二负载曲线观测值)，在不带有圆点的曲线上，在持续时间为0-36秒之间的时间段内，需要处理的http请求个数的最大值为68，最小值为18，在这36秒内共有2138个http请求，平均每秒处理的http请求个数为2138/36＝59.389个；图1C中的带有圆点的曲线表示已处理的http请求个数(第三负载曲线观测值)，已处理的http请求个数的最大值为69，最小值为12，由于已处理的http请求个数的采集晚于需要处理的http请求个数1秒钟(带有圆点的曲线的起始点晚于不带有圆点的曲线的起始点1秒钟)，因此在这36-1＝35秒内共有2138个http请求，平均每秒已处理的http请求个数为2138/35＝61.086个，通过将上述时间段内的与http请求个数相关的指标进行统计，从而可以准确地判断web服务器承受负载压力的能力。

请参见图2，为根据本发明的又一示例性实施例的显示负载请求的方法的流程示意图，本实施例以web服务器如何采集需要处理的http请求个数为例进行示例性说明，包括如下步骤：

步骤201，确定web服务器中用于统计需要处理的http请求个数的第一代码位置。

步骤202，统计在第一代码位置处的函数执行次数。

步骤203，根据第一代码位置处的函数执行次数确定需要处理的http请求个数。

在一实施例中，在web容器处理请求的开始位置加入字节码，统计需要处理的请求个数。本领域技术人员可以理解的是，针对具体不同的Java类web服务器和不同的Web应用框架，第一代码位置随着注入字节码的位置可以不同。本发明实施例以jetty容器和servlet框架下采集需要处理的http请求个数和已处理的http请求个数为例进行示例性说明，在处理请求的Filter的注入如下字节码：

this.visitMethodInsn(Opcodes.INVOKESTATIC，"统计类名"，"onMethodStart"，"()V")。

通过onMethodStart内按周期统计调用次数作为“需要处理的http请求个数”。由此，doFilter()方法开始位置即为本发明实施例所述的第一代码位置，第一代码位置处的函数为this.visitMethodInsn(Opcodes.INVOKESTATIC，"统计类名"，"onMethodStart"，"()V")。

请参见图3，为根据本发明的再一示例性实施例的显示负载请求的方法的流程示意图，本实施例以web服务器如何采集已处理的http请求个数为例进行示例性说明，包括如下步骤：

步骤301，确定web服务器中用于统计已处理的http请求个数的第二代码位置。

步骤302，统计在第二代码位置处的函数执行次数。

步骤303，根据第二代码位置处的函数执行次数确定需要处理的http请求个数。

在一实施例中，在web容器处理请求的结束位置加入字节码，统计已处理的请求个数。本领域技术人员可以理解的是，针对具体不同的Java类web服务器和不同的Web应用框架，第二代码位置随着注入字节码的位置可能不同。本发明实施例以jetty容器和servlet框架下采集需要处理的http请求个数和已处理的http请求个数为例进行示例性说明，在处理请求的Filter方法的结尾处注入如下字节码：

this.visitMethodInsn(Opcodes.INVOKESTATIC，"统计类名"，"onMethodEnd"，"()V")。

在onMethodEnd内按周期统计调用结束次数作为“已处理的请求数”。由此，doFilter()方法结束位置即为本发明实施例所述的第二代码位置，第二代码位置处的函数为this.visitMethodInsn(Opcodes.INVOKESTATIC，"统计类名"，"onMethodEnd"，"()V")。

请参见图4A，为根据本发明的另一示例性实施例的显示负载请求的方法的流程示意图，本实施例以web服务器如何采集积压在线程队列中的http请求个数为例进行示例性说明，包括如下步骤：

步骤401，确定web服务器中用于统计积压在线程队列中的http请求个数的第三代码位置。

步骤402，统计在第三代码位置处的函数执行次数。

步骤403，根据第三代码位置处的函数执行次数确定积压在线程队列中的http请求个数。

步骤404，将积压在线程队列中的http请求个数作为第四负载曲线观测值进行动态显示。

本领域技术人员可以理解的是，针对具体不同的Java类web服务器和不同的Web应用框架，第三代码位置随着注入字节码的位置可能不同。本发明实施例以jetty容器和servlet框架下采集积压在线程队列中的http请求个数为例进行示例性说明，在一实施例中，在jetty线程池派发求QueuedThreadPool.dispatch的开始位置注入如下字节码：

mv.visitVarInsn(Opcodes.ALOAD，0)；

mv.visitFieldInsn(Opcodes.GETFIELD，

"org/eclipse/jetty/util/thread/QueuedThreadPool"，"_jobs"，

"Ljava/util/concurrent/BlockingQueue；")；

mv.visitMethodInsn(Opcodes.INVOKEINTERFACE，

"java/util/concurrent/BlockingQueue"，"size"，"()I")；

this.visitMethodInsn(Opcodes.INVOKESTATIC，CLASS_NAME，

"onJettyMethodStart"，"(I)V")。

在onJettyMethodStart内记录线程池需要处理的http请求队列的大小和参数值，由此，QueuedThreadPool.dispatch的开始位置即为本发明实施例所述的第三代码位置，第三代码位置处的onJettyMethodStart确定积压在线程队列中的http请求个数。

如图4B所示，显示了线程池中的积压在线程队列中的http请求个数的曲线：该曲线用于衡量web容器来不及处理的http请求，即web容器中没有线程资源来处理的http请求，通过图4B所示的曲线，可以实时观察http请求积压的情况，当曲线为0或者在0附近时，说明web容器的http请求负载是正常的，在超负荷的场景中，第四负载曲线观测值会出现不断攀升。

通过上述图2-图4A所示实施例可以看出，本发明实施例通过Java的代理技术和字节码技术在不重启Web容器及不修改JDK源码的基础上采集web容器需要处理的http请求个数、已处理的http请求个数、积压在线程队列中的http请求个数，实现了从http请求个数的角度统计Web容器的负载指标，从而可以清晰地观察Web容器的负载状态。

对应于上述的显示负载请求的方法，本申请还提出了图5所示的根据本申请的一示例性实施例的网络服务器的示意结构图。请参考图5，在硬件层面，该网络服务器包括处理器、内部总线、网络接口、内存以及非易失性存储器，当然还可能包括其他业务所需要的硬件。处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成显示负载请求的装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

请参考图6，在软件实施方式中，该显示负载请求的装置可以包括：第一采集模块61、第一采集模块62、第一显示模块63。其中：

第一采集模块61，用于从网络服务器实时采集需要处理的负载请求个数；

第二采集模块62，用于从网络服务器实时采集已处理的负载请求个数；

第一显示模块63，用于将第一采集模块61采集到的需要处理的负载请求个数和第二采集模块62采集到的已处理的负载请求个数的差值作为第一负载曲线观测值进行动态显示。

请参考图7，装置还可包括：

第二显示模块64，用于将第一采集模块61采集到的需要处理的负载请求个数和第二采集模块62采集到的已处理的负载请求个数分别作为第二负载曲线观测值和第三负载曲线观测值进行动态显示。

在一实施例中，第一采集模块61可包括：

第一确定单元611，用于确定网络服务器中用于统计需要处理的负载请求个数的第一代码位置；

第一统计单元612，用于统计在第一确定单元611确定的第一代码位置处的函数执行次数；

第二确定单元613，用于根据第一统计单元612统计的第一代码位置处的函数执行次数确定需要处理的负载请求个数。

在一实施例中，第二采集模块62包括：

第三确定单元621，用于确定网络服务器中用于统计已处理的负载请求个数的第二代码位置；

第二统计单元622，用于统计在第三确定单元621确定的第二代码位置处的函数执行次数；

第四确定单元623，用于根据第二统计单元622统计的第二代码位置处的函数执行次数确定需要处理的负载请求个数。

在一实施例中，装置还可包括：

第一确定模块65，用于确定网络服务器中用于统计积压在线程队列中的负载请求个数的第三代码位置；

统计模块66，用于统计在确定模块65确定的第三代码位置处的函数执行次数；

第二确定模块67，用于根据统计模块66统计到的第三代码位置处的函数执行次数确定积压在线程队列中的负载请求个数。

在一实施例中，装置还可包括：

第三显示模块68，用于将第二确定模块67确定的积压在线程队列中的负载请求个数作为第四负载曲线观测值进行动态显示。

本领域技术人员可以理解的是，上述第一显示模块63、第二显示模块64、第三显示模块68可以集成到一个显示模块中，从而通过一个显示模块对需要处理的负载请求个数、已处理的负载请求个数、积压在线程队列中的负载请求个数等负载请求指标相关的参数进行显示。

由上述实施例可见，在网络服务器为Web服务器的情况下，本发明实施例可以通过Java的代理技术和字节码技术在不重启Web容器及不修改JDK源码的基础上采集web容器需要处理的负载请求个数、已处理的负载请求个数、积压在线程队列中的负载请求个数，实现了从负载请求个数的角度统计Web容器的负载指标，从而可以清晰地观察Web容器的负载状态。同样地，在网络服务器为FTP服务器、DNS服务器、SMTP服务区等网络服务器时，仍可以通过本发明上述实施例实现对相应的负载请求的显示，从而可以清晰地观察FTP服务器、DNS服务器、SMTP服务区等网络服务器的负载状态。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求指出。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (13)

1.一种显示负载请求的方法，其特征在于，所述方法包括：

从网络服务器实时采集需要处理的负载请求个数；

从所述网络服务器实时采集已处理的负载请求个数；

将所述需要处理的负载请求个数和所述已处理的负载请求个数的差值作为第一负载曲线观测值进行动态显示。

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

将所述需要处理的负载请求个数和所述已处理的负载请求个数分别作为第二负载曲线观测值和第三负载曲线观测值进行动态显示。

3.根据权利要求1所述的方法，其特征在于，所述从网络服务器实时采集需要处理的负载请求个数的步骤，包括：

确定所述网络服务器中用于统计所述需要处理的负载请求个数的第一代码位置；

统计在所述第一代码位置处的函数执行次数；

根据所述第一代码位置处的函数执行次数确定所述需要处理的负载请求个数。

4.根据权利要求1所述的方法，其特征在于，所述从所述网络服务器实时采集已处理的负载请求个数的步骤，包括：

确定所述网络服务器中用于统计所述已处理的负载请求个数的第二代码位置；

统计在所述第二代码位置处的函数执行次数；

根据所述第二代码位置处的函数执行次数确定所述已处理的负载请求个数。

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

确定所述网络服务器中用于统计积压在线程队列中的负载请求个数的第三代码位置；

统计在所述第三代码位置处的函数执行次数；

根据所述第三代码位置处的函数执行次数确定积压在所述线程队列中的负载请求个数。

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

将所述积压在所述线程队列中的负载请求个数作为第四负载曲线观测值进行动态显示。

7.一种显示负载请求负载的装置，其特征在于，所述装置包括：

第一采集模块，用于从所述网络服务器实时采集需要处理的负载请求个数；

第二采集模块，用于从所述网络服务器实时采集已处理的负载请求个数；

第一显示模块，用于将所述第一采集模块采集到的所述需要处理的负载请求个数和所述第二采集模块采集到的所述已处理的负载请求个数的差值作为第一负载曲线观测值进行动态显示。

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

第二显示模块，用于将所述第一采集模块采集到的所述需要处理的负载请求个数和所述第二采集模块采集到的所述已处理的负载请求个数分别作为第二负载曲线观测值和第三负载曲线观测值进行动态显示。

9.根据权利要求7所述的装置，其特征在于，所述第一采集模块包括：

第一确定单元，用于确定所述网络服务器中用于统计所述需要处理的负载请求个数的第一代码位置；

第一统计单元，用于统计在所述第一确定单元确定的所述第一代码位置处的函数执行次数；

第二确定单元，用于根据所述第一统计单元统计的所述第一代码位置处的函数执行次数确定所述需要处理的负载请求个数。

10.根据权利要求7所述的装置，其特征在于，所述第二采集模块包括：

第三确定单元，用于确定所述网络服务器中用于统计所述已处理的负载请求个数的第二代码位置；

第二统计单元，用于统计在所述第三确定单元确定的所述第二代码位置处的函数执行次数；

第四确定单元，用于根据所述第二统计单元统计的所述第二代码位置处的函数执行次数确定所述已处理的负载请求个数。

11.根据权利要求7-10任一所述的装置，其特征在于，所述装置还包括：

第一确定模块，用于确定所述网络服务器中用于统计积压在线程队列中的负载请求个数的第三代码位置；

统计模块，用于统计在所述确定模块确定的所述第三代码位置处的函数执行次数；

第二确定模块，用于根据所述统计模块统计到的所述第三代码位置处的函数执行次数确定积压在所述线程队列中的负载请求个数。

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

第三显示模块，用于将所述第二确定模块确定的积压在所述线程队列中的负载请求个数作为第四负载曲线观测值进行动态显示。

13.一种网络服务器，其特征在于，所述负载包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为：

实时采集需要处理的负载请求个数；

实时采集已处理的负载请求个数；

将所述需要处理的负载请求个数和所述已处理的负载请求个数的差值作为第一负载曲线观测值进行动态显示。