CN107819623A - 应用性能分析方法及装置 - Google Patents

Abstract

本申请公开了一种应用性能分析方法及装置，涉及应用分析技术领域，可以提高了统计应用功能响应时长的效率，进而可以提高应用性能的分析效率。所述方法包括：收集应用系统日志文件中的应用请求相关信息；根据所述应用请求相关信息，统计在预定时间间隔内相同应用功能的应用请求平均响应时长；将所述应用请求平均响应时长与预先建立的性能基线标准进行比对分析，得到相应的应用性能分析结果。本申请适用于应用性能的分析。

Description

应用性能分析方法及装置

技术领域

本申请涉及应用分析技术领域，特别是涉及一种应用性能分析方法及装置。

背景技术

随着市场上平板电脑、智能手机等智能终端的兴起，智能终端已经成为人们生活中不可或缺的一部分，人们可以通过智能终端上安装的应用进行在线聊天、网络游戏、网上购物等操作。但是有时用户在体验应用某些功能时，会存在卡顿现象，其一个主要原因是由于该功能的应用请求响应时长过长造成的，因此需要统计应用这些功能的响应时长，以便后续进行应用分析，找到问题所在。

目前，在统计应用某一功能的响应时长时，需要借助测试工具，或人工翻查万维网(World Wide Web，WEB)服务器记录的日志文件，从该日志文件中查找WEB服务器对与该功能相应的应用请求处理响应时长，进而得到应用该功能的响应时长，然而这种方式步骤繁琐且较耗费时间，会影响统计应用功能响应时长的效率，进而会影响应用性能的分析效率。

发明内容

有鉴于此，本申请提供了一种应用性能分析方法及装置，主要目的在于解决目前通过借助测试工具或人工翻查WEB服务器记录的日志文件，查查找应用某一功能的响应时长时步骤繁琐且较耗费时间，会影响统计应用功能响应时长的效率，进而会影响应用性能的分析效率的问题。

依据本申请一个方面，提供了一种应用性能分析方法，该方法包括：

收集应用系统日志文件中的应用请求相关信息；

根据所述应用请求相关信息，统计在预定时间间隔内相同应用功能的应用请求平均响应时长；

将所述应用请求平均响应时长与预先建立的性能基线标准进行比对分析，得到相应的应用性能分析结果。

依据本申请另一个方面，提供了一种应用性能分析装置，该装置包括：

收集单元，用于收集应用系统日志文件中的应用请求相关信息；

统计单元，用于根据所述收集单元收集到的应用请求相关信息，统计在预定时间间隔内相同应用功能的应用请求平均响应时长；

分析单元，用于将所述应用请求平均响应时长与预先建立的性能基线标准进行比对分析，得到相应的应用性能分析结果。

依据本申请又一个方面，提供了一种存储设备，其上存储有计算机程序，所述程序被处理器执行时实现上述应用性能分析方法。

依据本申请再一个方面，提供了一种应用性能分析的实体装置，包括存储设备、处理器及存储在存储设备上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述应用性能分析方法。

借由上述技术方案，本申请提供的一种应用性能分析方法及装置，与目前通过借助测试工具或人工翻查WEB服务器记录的日志文件的方式相比，本申请可以从应用系统日志文件中自动收集应用请求相关信息，并根据该信息统计得到预定时间间隔内相同应用功能的应用请求平均响应时长，进而依据该平均响应时长自动分析得到应用性能分析结果，无需借助测试工具或人工翻查，操作简单省时，提高了统计应用功能响应时长的效率，从而提高了应用性能的分析效率。

上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，而可依照说明书的内容予以实施，并且为了让本申请的上述和其它目的、特征和优点能够更明显易懂，以下特举本申请的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本申请的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了本申请实施例提供的一种应用性能分析方法流程示意图；

图2示出了本申请实施例提供的另一种应用性能分析方法流程示意图；

图3示出了本申请实施例提供的一种应用性能分析装置的结构示意图；

图4示出了本申请实施例提供的另一种应用性能分析装置的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

本申请实施例提供了一种应用性能分析方法，操作简单省时，可以提高统计应用功能响应时长的效率，进而可以提高应用性能的分析效率，如图1所示，该方法包括：

101、收集应用系统日志文件中的应用请求相关信息。

其中，应用请求相关信息包括客户端向WEB服务器发送应用请求的时间、WEB服务器接收到应用请求的时间、该应用请求的请求内容、WEB服务器返回该应用请求处理结果的时间、该应用请求的处理结果内容及发送该应用请求的客户端信息(如所在终端设备的设备标识、登录的用户信息等)等内容。应用系统日志文件用于保存WEB服务器处理应用请求时所记录的应用请求相关信息。

对于本申请实施例的执行主体可以为用于应用性能分析的装置，具体可以用于分析应用某一功能相应的应用请求响应时长，找到应用请求响应时长大于一定阈值的应用功能，做到应用的性能分析，以便后续对该应用功能进行改进。

102、根据收集到的应用请求相关信息，统计在预定时间间隔内相同应用功能的应用请求平均响应时长。

其中，预定时间间隔可以根据实际需求预先进行设定。例如，预定时间间隔可以为每天、每周、每月等。

例如，根据应用请求相关信息包含的客户端发送应用请求的时间、以及WEB服务器返回应用请求处理结果的时间，计算应用请求的响应时长，具体可以将WEB服务器返回应用请求处理结果的时间减去客户端发送该应用请求的时间，得到该应用请求的响应时长，在得到每个应用请求的响应时长后，统计在预定时间间隔内相同应用功能的应用请求平均响应时长。

103、将应用请求平均响应时长与预先建立的性能基线标准进行比对分析，得到相应的应用性能分析结果。

在本实施例中，可以预先收集大量的应用请求响应时长的样本数据，然后对样本数据进行统计分析，找到符合普遍标准的性能基线标准。

例如，将每日相同应用功能的应用请求平均响应时长与性能基线标准进行比对分析，将应用请求平均响应时长小于性能基线标准的应用功能记为正常，并将应用请求平均响应时长大于性能基线标准的应用功能记为危险；根据每个应用功能的标记结果，以及相应的应用请求平均响应时长等信息，生成每日应用性能分析结果，最后可以以图或表等形式展示给应用分析人员，以便及时找到出现异常的应用功能。

本申请实施例提供的一种应用性能分析方法，与目前通过借助测试工具或人工翻查WEB服务器记录的日志文件的方式相比，本申请实施例可以根据收集到的应用系统日志文件中应用请求相关信息自动统计得到预定时间间隔内相同应用功能的应用请求平均响应时长，进而依据该平均响应时长自动分析得到应用性能分析结果，无需借助测试工具或人工翻查，操作简单省时，提高了统计应用功能响应时长的效率，从而提高了应用性能的分析效率。

进一步的，作为上述实施例具体实施方式的细化和扩展，提供了另一种应用性能分析方法，如图2所示，该方法包括：

201、预先根据不同倍数的性能基线标准，划分不同的时长区间范围。

具体可以根据不同的实际需要，划分不同的时长区间范围。例如，根据实际需要划分三个时长区间范围，具体将小于1倍的性能基线标准的时长区间范围划分为A时长区间范围；将大于1倍的性能基线标准、且小于2倍的性能基线标准的时长区间范围划分为B时长区间范围；将大于2倍的性能基线标准的时长区间范围划分为C时长区间范围。

202、配置每个时长区间范围对应的标记信息。

例如，在上述201中实例的基础上，配置A时长区间范围对应的标记信息为正常；配置B时长区间范围对应的标记信息为警告；配置C时长区间范围对应的标记信息为危险。

203、当接收到应用性能分析的指令时，收集应用系统日志文件中的应用请求相关信息。

在本实施例中，可以实时收集WEB服务器上相关应用系统的日志文件中的应用请求相关信息；然后将收集到的应用请求相关信息同步到核心服务器上，在核心服务器上遍历并执行已同步的这些应用请求相关信息的文件，以便将这些应用请求相关信息及时插入到核心数据库中，通过这种方式可以使新增的已配置监控的应用请求相关信息也及时插入到核心数据库中。

204、根据收集到的应用请求相关信息，统计在预定时间间隔内相同应用功能的应用请求平均响应时长。

在核心数据库中按照预定时间间隔分析插入的这些应用请求相关信息，统计在预定时间间隔内相同应用功能的应用请求平均响应时长。在本实施例中，通过在核心数据库中进行分析，不在WEB服务器中分析，可以减轻WEB服务器的压力。

205、从不同的时长区间范围中确定应用请求平均响应时长所处于的时长区间范围。

例如，在步骤201和步骤202的实例中，如果应用功能a在一天内的应用请求平均响应时长小于1倍的性能基线标准，说明处于A时长区间范围内；如果应用功能b在一天内的应用请求平均响应时长大于2倍的性能基线标准，说明处于C时长区间范围内。

206、依据确定的时长区间范围对应的标记信息，确定应用功能响应情况的性能分析结果。

例如，基于步骤205的实例，将每日相同应用功能的应用请求平均响应时长与性能基线标准进行比对分析，得到应用功能a的标记信息为正常、应用功能b的标记信息为危险，根据应用功能a和b的标记结果，以及相应的应用请求平均响应时长等信息，生成应用性能分析结果，最后可以以图或表等形式展示给应用分析人员，在图中可以将应用功能a的“正常”分析结果标记为绿色，将应用功能b的“危险”的分析结果标记为红色，以便应用分析人员及时发现出现异常的应用功能b。

进一步的，为了更加全面的分析应用功能的性能状况，在本申请的一个可选实施例中，在步骤206之前，还可以包括：根据收集到的应用请求相关信息，统计在预定时间间隔内相同应用功能的应用请求最长响应时长以及应用请求数量；相应的，步骤206具体可以包括：依据确定的时长区间范围对应的标记信息、应用请求最长响应时长以及应用请求数量，确定应用功能响应情况的性能分析结果。

通过统计相同应用功能的应用请求最长响应时长以及应用请求数量，可以分析应用功能响应最差的情况以及该应用功能的普遍使用情况；还可以预先设定最差响应时长基准，然后统计在预定时间间隔内该应用功能的各个应用请求中，应用请求响应时长大于该最差响应时长基准的应用请求个数，以及该个数分析该应用功能的性能情况，如果该个数较多说明该应用功能经常响应延迟，已经给用户带来不好的体验；如果该个数较少，只是众多应用请求中的零散几个，说明该应用功能偶尔会发生响应延迟，不影响正常使用。

对于本可选实施例，为了使得分析人员快速了解分析结果的准确性，在确定应用功能响应情况的性能分析结果之后，还可以包括：检测统计得到的在预定时间间隔内该应用功能的应用请求数量所处于的预设数量区间范围，其中不同的预设数量区间范围分别对应不同的分析可信度；根据检测到的该应用功能的应用请求数量所处于的预设数量区间范围，标记在预定时间间隔内对应的应用功能响应情况的性能分析结果的分析可信度。

预先根据不同的数量区间范围，分别配置对应的可信度，并且随着数量区间范围的数量级越多，相应的可信度越高。例如，参照预定时间间隔为每天，可以将小于100的数量区间范围对应的可信度配置为40％，将大于或等于100且小于1000的数量区间范围对应的可信度配置为50％，将大于或等于1000且小于5000的数量区间范围对应的可信度配置为60％，类似的，最后将大于1000000的数量区间范围对应的可信度配置为95％等；在通过上述方法得到一天内应用功能响应情况的性能分析结果之后，可以根据该应用功能在这一天内的应用请求数量，检测其所在的预设数量区间范围，如果该应用请求数量处于大于1000000的数量区间范围内，可以将得到的性能分析结果的分析可信度标记为95％，进而使得分析人员了解该分析结果的分析可靠性很高。

进一步的，为了更加全面的分析应用的不同应用功能的性能状况，在本申请的一个可选实施例中，还可以包括：统计在预定时间间隔内不同应用功能分别对应的应用请求数量；及结合发送应用请求的客户端信息，统计在预定时间间隔内使用相同应用功能的用户数量；相应的，步骤206具体还可以包括：依据比对结果、不同应用功能分别对应的应用请求数量和使用相同应用功能的用户数量，确定得到相应的应用性能分析结果。

其中，客户端信息可以包含客户端所在终端设备的设备相关信息、用户账号信息等。例如设备相关信息可以为设备型号、国际移动设备识别码(International MobileEquipment Identity，IMEI)等；用户账号信息可以为用户登录账号、身份标识号码(Identity，ID)等。客户端信息用于区别不同的用户，例如，根据发送应用请求的客户端所在终端设备的设备相关信息，统计每日有多少终端设备使用了相同的应用功能。

通过分析在预定时间间隔内不同应用功能分别对应的应用请求数量，以及使用相同应用功能的用户数量，可以分析应用不同功能的使用占比，得到哪些应用功能比较受到用户青睐，哪些应用功能是用户不常用的，结合上述应用功能的应用请求响应时长分析，对于出现异常的应用功能，可以依照用户青睐程度，有选择性的优先进行处理维护，相对于用户不常用的应用功能，优先维护用户普遍经常使用的出现异常的应用功能，以便及时满足用户的需求。

为了结合应用的市场前景进一步分析应用性能的改进之处，在本申请的一个可选实施例中，还可以包括：查询发送应用请求的客户端对应的用户账户信息；从查询到的用户账户信息相应的用户注册信息中获取用户属性信息；结合获取到的用户属性信息，统计在预定时间间隔内使用相同应用功能的所有用户人群中具有类似用户属性特征的人群数量，并根据统计得到的人群数量统计占比大于预设比例阈值的用户人群的用户属性特征信息；相应的，步骤206具体还可以包括：依据比对结果、统计得到的人群数量和统计得到的用户属性特征信息，确定得到相应的应用性能分析结果。其中，用户属性信息可以包含用户的性别、年龄、职业、兴趣爱好等信息。

例如，结合用户的属性信息，统计在一天内使用应用功能b的所有用户人群中具有类似用户属性特征的人群数量，如性别相同、年龄相仿、职业类似、兴趣爱好类似的用户人群数量，然后找到人群数量占比大于一定阈值的用户人群的用户属性特征信息，即在这一天内使用应用功能a的所有用户人群中具有共性的用户属性特征，如这些用户基本都是20岁至30岁之间的女性用户、且职业基本都是文员相关的职业，统计这些用户属性特征；然后如果通过比对分析，得到应用功能b的应用请求平均响应时长大于2倍的性能基线标准，处于危险的时长区间范围内，基于这些信息内容生成应用功能b响应情况的性能分析结果，以便后续技术人员对应用功能b进行性能维护时，增加一些20岁至30岁之间的、且职业是文员相关职业的女性用户所青睐的元素内容，以便增加用户体验应用的粘性。

通过上述这种方式不但可以分析应用的性能，还可以统计体验应用的用户人群中具有共性的用户属性特征，可以为后续对应用性能改进提供参考建议，便于用户更好的体验应用。

进一步的，为了提醒技术人员对应用出现异常状况时及时进行维护处理，对应用请求响应时长过长的应用功能进行及时维护，在本申请的一个可选实施例中，在确定得到应用性能分析结果之后，还可以包括：获取应用系统对应的应用维护模块的通信方式信息；根据获取到的通信方式信息，将分析得到的应用性能分析结果实时推送给应用维护模块。其中，应用维护模块可以为根据应用功能响应情况的性能分析结果，对应用进行性能维护的单元模块，具体处理过程可以参见现有技术中的处理方式，在此不再赘述；通信方式信息可以包含理赔维护模块的电子邮箱(Electronic MAIL，E-mail)地址、IP地址、电话号码、即时通信工具的账号等。

在本实施例中，在确定得到应用性能分析结果之后，可以将该分析结果实时推送给应用维护模块进行处理，以便及时对存在异常状况的应用功能进行维护处理，保证用户对应用的良好体验。

本申请实施例提供的另一种应用性能分析方法，无需借助测试工具或人工翻查，操作简单省时，提高了统计应用功能响应时长的效率，进而提高了应用性能的分析效率；可以在核心数据库中进行分析，不在WEB服务器中分析，可以减轻WEB服务器的压力；并且还可以统计应用功能的应用请求最长响应时长、应用请求数量，可以分析应用功能响应最差的情况以及该应用功能的普遍使用情况；通过对分析结果增加分析可信度的标记，使得分析人员了解该分析结果的分析可靠性；还可以分析应用的不同应用功能的性能状况，以及可以结合应用的市场前景进一步分析应用性能的改进之处。

进一步的，作为图1和图2所述方法的具体实现，本申请实施例提供了一种应用性能分析装置，如图3所示，所述装置包括：收集单元31、统计单元32、分析单元33。

收集单元31，可以用于收集应用系统日志文件中的应用请求相关信息；

统计单元32，可以用于根据所述收集单元31收集到的应用请求相关信息，统计在预定时间间隔内相同应用功能的应用请求平均响应时长；

分析单元33，可以用于将所述应用请求平均响应时长与预先建立的性能基线标准进行比对分析，得到相应的应用性能分析结果。

在具体的应用场景中，为了细粒度的分析得到应用性能分析结果，如图4所示，所述装置还包括：划分单元34、配置单元35；

划分单元34，可以用于根据不同倍数的所述性能基线标准，划分不同的时长区间范围；

配置单元35，可以用于配置每个时长区间范围对应的标记信息；

分析单元33，具体可以用于从所述不同的时长区间范围中确定所述应用请求平均响应时长所处于的时长区间范围；依据确定的所述时长区间范围对应的标记信息，确定所述应用功能响应情况的性能分析结果。

在具体的应用场景中，为了更加全面的分析应用功能的性能状况，统计单元32，还可以用于根据所述应用请求相关信息，统计在预定时间间隔内相同应用功能的应用请求最长响应时长以及应用请求数量；

分析单元33，具体还可以用于依据确定的所述时长区间范围对应的标记信息、所述应用请求最长响应时长以及所述应用请求数量，确定所述应用功能响应情况的性能分析结果。

在具体的应用场景中，为了使得分析人员快速了解分析结果的准确性，如图4所示，所述装置还包括：检测单元36、标记单元37；

检测单元36，用于检测所述应用请求数量所处于的预设数量区间范围，不同的预设数量区间范围分别对应不同的分析可信度；

标记单元37，用于根据检测单元36检测到的所述应用请求数量所处于的预设数量区间范围，标记在所述预定时间间隔内对应的所述应用功能响应情况的性能分析结果的分析可信度。

在具体的应用场景中，为了更加全面的分析应用的不同应用功能的性能状况，统计单元32，还可以用于统计在预定时间间隔内不同应用功能分别对应的应用请求数量；及结合发送应用请求的客户端信息，统计在预定时间间隔内使用相同应用功能的用户数量；

相应的，分析单元33，具体还可以用于依据比对结果、所述应用请求数量和所述用户数量，确定得到相应的应用性能分析结果。

在具体的应用场景中，为了结合应用的市场前景进一步分析应用性能的改进之处，如图4所示，所述装置还包括：查询单元38、获取单元39；

查询单元38，可以用于查询发送应用请求的客户端对应的用户账户信息；

获取单元39，可以用于从所述用户账户信息相应的用户注册信息中获取用户属性信息；

统计单元32，还可以用于结合所述用户属性信息，统计在预定时间间隔内使用相同应用功能的所有用户人群中具有类似用户属性特征的人群数量，并根据所述人群数量统计占比大于预设比例阈值的用户人群的用户属性特征信息；

相应的，分析单元33，具体还可以用于依据比对结果、所述人群数量和所述用户属性特征信息，确定得到相应的应用性能分析结果。

在具体的应用场景中，为了提醒技术人员对应用出现异常状况时及时进行维护处理，对应用请求响应时长过长的应用功能进行及时维护，如图4所示，所述装置还包括：推送单元310；

获取单元39，还可以用于获取所述应用系统对应的应用维护模块的通信方式信息；

推送单元310，可以用于根据所述通信方式信息，将所述应用性能分析结果实时推送给所述应用维护模块。

需要说明的是，本申请实施例提供的一种应用性能分析装置所涉及各功能单元的其他相应描述，可以参考图1和图2中的对应描述，在此不再赘述。

基于上述如图1和图2所示方法，相应的，本申请实施例还提供了一种存储设备，其上存储有计算机程序，该程序被处理器执行时实现上述如图1和图2所示的应用性能分析方法。

基于上述如图1和图2所示方法和如图3和如图4所示虚拟装置的实施例，为了实现上述目的，本申请实施例还提供了一种应用性能分析的实体装置，该实体装置包括存储设备和处理器；所述存储设备，用于存储计算机程序；所述处理器，用于执行所述计算机程序以实现上述如图1和图2所示的应用性能分析方法。

通过应用本申请的技术方案，无需借助测试工具或人工翻查，操作简单省时，提高了统计应用功能响应时长的效率，进而提高了应用性能的分析效率；可以在核心数据库中进行分析，不在WEB服务器中分析，可以减轻WEB服务器的压力；并且还可以统计应用功能的应用请求最长响应时长、应用请求数量，可以分析应用功能响应最差的情况以及该应用功能的普遍使用情况；通过对分析结果增加分析可信度的标记，使得分析人员了解该分析结果的分析可靠性；还可以分析应用的不同应用功能的性能状况，以及可以结合应用的市场前景进一步分析应用性能的改进之处。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本申请可以通过硬件实现，也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施场景所述的方法。

本领域技术人员可以理解附图只是一个优选实施场景的示意图，附图中的模块或流程并不一定是实施本申请所必须的。

本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中，也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块，也可以进一步拆分成多个子模块。

上述本申请序号仅仅为了描述，不代表实施场景的优劣。

以上公开的仅为本申请的几个具体实施场景，但是，本申请并非局限于此，任何本领域的技术人员能思之的变化都应落入本申请的保护范围。

Claims (10)

1.一种应用性能分析方法，其特征在于，包括：

收集应用系统日志文件中的应用请求相关信息；

根据所述应用请求相关信息，统计在预定时间间隔内相同应用功能的应用请求平均响应时长；

将所述应用请求平均响应时长与预先建立的性能基线标准进行比对分析，得到相应的应用性能分析结果。

2.根据权利要求1所述的方法，其特征在于，将所述应用请求平均响应时长与预先建立的性能基线标准进行比对分析，得到相应的应用性能分析结果之前，所述方法还包括：

根据不同倍数的所述性能基线标准，划分不同的时长区间范围；及

配置每个时长区间范围对应的标记信息；

所述将所述应用请求平均响应时长与预先建立的性能基线标准进行比对分析，得到相应的应用性能分析结果，包括：

从所述不同的时长区间范围中确定所述应用请求平均响应时长所处于的时长区间范围；

依据确定的所述时长区间范围对应的标记信息，确定所述应用功能响应情况的性能分析结果。

3.根据权利要求2所述的方法，其特征在于，所述依据确定的所述时长区间范围对应的标记信息，确定所述应用功能响应情况的性能分析结果之前，所述方法还包括：

根据所述应用请求相关信息，统计在预定时间间隔内相同应用功能的应用请求最长响应时长以及应用请求数量；

所述依据确定的所述时长区间范围对应的标记信息，确定所述应用功能响应情况的性能分析结果，包括：

依据确定的所述时长区间范围对应的标记信息、所述应用请求最长响应时长以及所述应用请求数量，确定所述应用功能响应情况的性能分析结果。

4.根据权利要求3所述的方法，其特征在于，所述依据确定的所述时长区间范围对应的标记信息、所述应用请求最长响应时长以及所述应用请求数量，确定所述应用功能响应情况的性能分析结果之后，所述方法还包括：

检测所述应用请求数量所处于的预设数量区间范围，不同的预设数量区间范围分别对应不同的分析可信度；

根据检测到的所述应用请求数量所处于的预设数量区间范围，标记在所述预定时间间隔内对应的所述应用功能响应情况的性能分析结果的分析可信度。

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

统计在预定时间间隔内不同应用功能分别对应的应用请求数量；及

结合发送应用请求的客户端信息，统计在预定时间间隔内使用相同应用功能的用户数量；

所述将所述应用请求平均响应时长与预先建立的性能基线标准进行比对分析，得到相应的应用性能分析结果，具体包括：

依据比对结果、所述应用请求数量和所述用户数量，确定得到相应的应用性能分析结果。

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

查询发送应用请求的客户端对应的用户账户信息；

从所述用户账户信息相应的用户注册信息中获取用户属性信息；

结合所述用户属性信息，统计在预定时间间隔内使用相同应用功能的所有用户人群中具有类似用户属性特征的人群数量，并根据所述人群数量统计占比大于预设比例阈值的用户人群的用户属性特征信息；

所述将所述应用请求平均响应时长与预先建立的性能基线标准进行比对分析，得到相应的应用性能分析结果，包括：

依据比对结果、所述人群数量和所述用户属性特征信息，确定得到相应的应用性能分析结果。

7.根据权利要求1至6中任一项所述的方法，其特征在于，所述将所述应用请求平均响应时长与预先建立的性能基线标准进行比对分析，得到相应的应用性能分析结果之后，所述方法还包括：

获取所述应用系统对应的应用维护模块的通信方式信息；

根据所述通信方式信息，将所述应用性能分析结果实时推送给所述应用维护模块。

8.一种应用性能分析装置，其特征在于，包括：

收集单元，用于收集应用系统日志文件中的应用请求相关信息；

统计单元，用于根据所述收集单元收集到的应用请求相关信息，统计在预定时间间隔内相同应用功能的应用请求平均响应时长；

分析单元，用于将所述应用请求平均响应时长与预先建立的性能基线标准进行比对分析，得到相应的应用性能分析结果。

9.一种存储设备，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现权利要求1至7中任一项所述的应用性能分析方法。

10.一种应用性能分析装置，包括存储设备、处理器及存储在存储设备上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求1至7中任一项所述的应用性能分析方法。