一种前端性能监控方法、装置、设备及可读存储介质

技术领域

本申请涉及计算机技术领域，特别涉及一种前端性能监控方法、装置、设备及可读存储介质。

背景技术

目前，针对WEB前端进行性能监控时，需对前端产生的所有响应数据进行存储。但由于前端响应数据大多为正常数据，而存储较多正常数据无益于前端性能分析，还会浪费存储资源和网络资源。并且，当前仅以加载总时长作为前端响应数据来评估前端性能，评估维度较单一，数据颗粒度也较大，导致前端性能的监控不够精细，难以发现前端问题所在。

因此，如何更精细地评估前端性能，并提高前端性能监控效率，是本领域技术人员需要解决的问题。

发明内容

有鉴于此，本申请的目的在于提供一种前端性能监控方法、装置、设备及可读存储介质，以更精细地评估前端性能，并提高前端性能监控效率。其具体方案如下：

第一方面，本申请提供了一种前端性能监控方法，包括：

获取前端在预设时间段内产生的异常响应数据；

从至少两个维度对所述异常响应数据进行性能评估，得到所述至少两个维度的性能评估数据；所述至少两个维度从项目维度、页面维度和路径维度中确定；

若任意维度的性能评估数据达到预设报警条件，则对该维度进行报警。

可选地，所述获取前端在预设时间段内产生的异常响应数据，包括：

在数据库中查询所述异常响应数据。

可选地，所述在数据库中查询所述异常响应数据之前，还包括：

获取前端发送的报错响应数据和/或响应时间超过预期的目标响应数据；

按照时间戳顺序将报错响应数据和/或目标响应数据暂存至相应内存队列；

将所述内存队列中的数据作为所述异常响应数据存储至所述数据库。

可选地，所述将所述内存队列中的数据作为所述异常响应数据存储至所述数据库之前，还包括：

判断所述内存队列中的数据量是否达到预设队列阈值；

若是，则执行所述将所述内存队列中的数据作为所述异常响应数据存储至所述数据库的步骤；

或

判断当前是否达到入库时间点；

若是，则执行所述将所述内存队列中的数据作为所述异常响应数据存储至所述数据库的步骤。

可选地，所述从至少两个维度对所述异常响应数据进行性能评估，得到所述至少两个维度的性能评估数据，包括：

从所述至少两个维度对所述异常响应数据进行分类，得到所述至少两个维度分别对应的分类数据集；

针对每一分类数据集，确定当前分类数据集中的数据条数以及需评估的目标参数；

基于所述数据条数计算所述目标参数的平均值，并为所述目标参数选择至少一个需监控值；

将所述平均值和/或所述至少一个需监控值作为当前分类数据集的评估项；

汇总同一维度所对应分类数据集的评估项，得到该维度的性能评估数据。

可选地，所述为所述目标参数选择至少一个需监控值，包括：

将当前分类数据集中所述目标参数的各个取值构建为数组；

将所述数组中处于目标位置的数值作为所述需监控值；所述目标位置为：所述数组中的50％位置、90％位置、95％位置和99％位置中的至少一个。

可选地，若所述异常响应数据为：目标响应数据，则所述目标参数包括：通信连接建立时长、服务端响应时长、页面渲染时长和/或加载总时长；若所述异常响应数据为：报错响应数据，则所述目标参数包括：报错次数。

可选地，所述若任意维度的性能评估数据达到预设报警条件，则对该维度进行报警，包括：

将所述至少两个维度的性能评估数据发送至性能监控平台，以使所述性能监控平台在确定任意维度的性能评估数据达到所述预设报警条件时，推送报警通知消息至预设目的端。

可选地，所述若任意维度的性能评估数据达到预设报警条件，则对该维度进行报警，包括：

针对任意维度的性能评估数据中的每一评估项，若当前评估项超过其对应的报警阈值，则对当前评估项进行报警。

第二方面，本申请提供了一种前端性能监控装置，包括：

获取模块，用于获取前端在预设时间段内产生的异常响应数据；

评估模块，用于从至少两个维度对所述异常响应数据进行性能评估，得到所述至少两个维度的性能评估数据；所述至少两个维度从项目维度、页面维度和路径维度中确定；

报警模块，用于若任意维度的性能评估数据达到预设报警条件，则对该维度进行报警。

第三方面，本申请提供了一种电子设备，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序，以实现前述公开的前端性能监控方法。

第四方面，本申请提供了一种可读存储介质，用于保存计算机程序，其中，所述计算机程序被处理器执行时实现前述公开的前端性能监控方法。

通过以上方案可知，本申请提供了一种前端性能监控方法，包括：获取前端在预设时间段内产生的异常响应数据；从至少两个维度对所述异常响应数据进行性能评估，得到所述至少两个维度的性能评估数据；所述至少两个维度从项目维度、页面维度和路径维度中确定；若任意维度的性能评估数据达到预设报警条件，则对该维度进行报警。

可见，本申请仅针对前端产生的异常响应数据进行分析，而不关注前端正常响应数据，因此可以降低数据处理量，提高分析效率；并且，本申请从项目维度、页面维度和路径维度中的至少两个维度对异常响应数据进行性能评估，因此可得到至少两个维度的性能评估数据，由此便可从多个维度评估前端性能，使得数据分析和评估的颗粒度更精细、更全面；当任意维度的性能评估数据达到预设报警条件时，本申请可对该维度进行报警，从而可以发现前端问题所在。

相应地，本申请提供的一种前端性能监控装置、设备及可读存储介质，也同样具有上述技术效果。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本申请公开的一种前端性能监控方法流程图；

图2为本申请公开的一种软件设计示意图；

图3为本申请公开的一种数据存储示意图；

图4为本申请公开的一种前端性能监控装置示意图；

图5为本申请公开的一种电子设备示意图；

图6为本申请提供的一种服务器结构图；

图7为本申请提供的一种终端结构图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

目前，针对WEB前端进行性能监控时，需对前端产生的所有响应数据进行存储。但由于前端响应数据大多为正常数据，而存储较多正常数据无益于前端性能分析，还会浪费存储资源和网络资源。并且，当前仅以加载总时长作为前端响应数据来评估前端性能，评估维度较单一，数据颗粒度也较大，导致前端性能的监控不够精细，难以发现前端问题所在。为此，本申请提供了一种前端性能监控方案，能够更精细地评估前端性能，并提高前端性能监控效率。

参见图1所示，本申请实施例公开了一种前端性能监控方法，包括：

S101、获取前端在预设时间段内产生的异常响应数据。

在本实施例中，异常响应数据可以是报错响应数据和/或响应时间超过预期且未超时的目标响应数据。其中，报错响应数据指：访问出错时产生的响应数据。目标响应数据指：访问时间较长但还未超时的响应数据；也即：预期时间小于响应超时时间。异常响应数据可以提前存储在数据库中，例如：当前端产生报错响应数据和/或目标响应数据时，前端将当前产生的响应数据传输至数据库进行存储。因此在一种具体实施方式中，获取前端在预设时间段内产生的异常响应数据，包括：在数据库中查询异常响应数据。数据库可以为非关系型数据库。如elastic search，其具备较强的搜索能力和更大数据量的存储能力，适用于存储异常响应数据，也便于定位问题数据。

为了使数据的传输与存储不出错，可以借助队列保障数据的顺序和一致性。在一种具体实施方式中，在数据库中查询异常响应数据之前，还包括：获取前端发送的报错响应数据和/或目标响应数据；按照时间戳顺序将报错响应数据和/或目标响应数据暂存至相应内存队列；将内存队列中的数据作为异常响应数据存储至数据库。

其中，将内存队列中的数据作为异常响应数据存储至数据库之前，还包括：判断内存队列中的数据量是否达到预设队列阈值；若是，则执行将内存队列中的数据作为异常响应数据存储至数据库的步骤；或判断当前是否达到入库时间点；若是，则执行将内存队列中的数据作为异常响应数据存储至数据库的步骤，以定时使内存队列中的数据入库存储。

由于异常响应数据为报错响应数据或目标响应数据，因此可以设置两个内存队列来分别暂存报错响应数据、目标响应数据。

S102、从至少两个维度对异常响应数据进行性能评估，得到至少两个维度的性能评估数据；至少两个维度从项目维度、页面维度和路径维度中确定。

在本实施例中，项目维度、页面维度和路径维度这三个维度逐级精细。具体的，一个项目可包括多个页面，一个页面可包括多个路径，因此从这三个维度对异常响应数据进行性能评估，可按照不同颗粒度大小分析异常响应数据，从而得到相应的评估数据。

在一种具体实施方式中，从至少两个维度对异常响应数据进行性能评估，得到至少两个维度的性能评估数据，包括：从至少两个维度对异常响应数据进行分类，得到至少两个维度分别对应的分类数据集；针对每一分类数据集，确定当前分类数据集中的数据条数以及需评估的目标参数；基于数据条数计算目标参数的平均值，并为目标参数选择至少一个需监控值；将平均值和/或至少一个需监控值作为当前分类数据集的评估项；汇总同一维度所对应分类数据集的评估项，得到该维度的性能评估数据。其中，通信连接建立时长指：前端与服务端建立通信连接所花费的时间；服务端响应时长指：服务端处理前端所发请求所花费的时间；页面渲染时长指：前端基于服务端所返数据渲染页面所花费的时间；加载总时长指：通信连接建立时长、服务端响应时长和页面渲染时长之和。

在一种具体实施方式中，为目标参数选择至少一个需监控值，包括：将当前分类数据集中目标参数的各个取值构建为数组；将数组中处于目标位置的数值作为需监控值；目标位置为：数组中的50％位置、90％位置、95％位置和99％位置中的至少一个。若异常响应数据为：目标响应数据，则目标参数包括：通信连接建立时长、服务端响应时长、页面渲染时长和/或加载总时长；若异常响应数据为：报错响应数据，则目标参数包括：报错次数。

在一种示例中，若前端在预设时间段内产生的目标响应数据有5条，若从路径维度对这5条数据分类得到路径1：path＝/order/v1/getOrderDetail和路径2：path＝/order/v1/getOrderList这两个路径，假设属于路径1的有4条数据，分别为：a的通信连接建立时长＝300、页面渲染时长＝350、加载总时长＝240、服务端响应时长＝280；b的通信连接建立时长＝320、页面渲染时长＝310、加载总时长＝260、服务端响应时长＝290；c的通信连接建立时长＝340、页面渲染时长＝330、加载总时长＝270、服务端响应时长＝260；d的通信连接建立时长＝350、页面渲染时长＝340、加载总时长＝250、服务端响应时长＝270；这4条数据便构成了路径1对应的分类数据集1。属于路径2的有1条数据：通信连接建立时长＝370、页面渲染时长＝360、加载总时长＝260、服务端响应时长＝270；这1条数据便构成了路径2对应的分类数据集2。

由于上述路径1：path＝/order/v1/getOrderDetail和路径2：path＝/order/v1/getOrderList属于同一页面，因此从页面维度对上述这5条数据进行分类，这5条数据被分类至同一分类数据集3。

如果从项目维度分类这5条数据，这5条数据仍被分类至同一分类数据集，所以还会得到分类数据集3，由于项目维度的分类与页面维度的分类重复，故此时可放弃项目维度的分析，仅从页面和路径维度进行数据分析。

可见，同一维度下可有至少一个分类数据集，本实施例可针对每一分类数据集进行分析和性能评估。

以上述示例为例，对于分类数据集1，其中包括的数据条数为4，需评估的目标参数有通信连接建立时长、服务端响应时长、页面渲染时长和加载总时长，那么基于数据条数4分别计算通信连接建立时长、服务端响应时长、页面渲染时长和加载总时长的均值，以通信连接建立时长为例，则有：通信连接建立时长的平均值average＝(300+320+340+350)/4＝336；据此，服务端响应时长、页面渲染时长和加载总时长的均值可相应计算得到。下一步为通信连接建立时长、服务端响应时长、页面渲染时长和加载总时长分别选择至少一个需监控值，仍以通信连接建立时长为例，将通信连接建立时长的4个取值300、320、340、350构建为数组arr＝[300,320,340,350]，各取值在数组中从小到大排列，那么位于该数组50％位置的数值为340，可表示为：50p＝arr[int(4*0.5)]＝340，其中的“int(4*0.5)”表示：对4*0.5的结果进行取整，可得到标号2，按照数组中各个数值的标号0、1、2、3，可确定标号2对应340。

相应地，数组arr＝[300,320,340,350]中90％位置、95％位置、99％位置的数值分别为：90p＝arr[int(4*0.9)]＝350，95p＝arr[int(4*0.95)]＝350，99p＝arr[int(4*0.99)]＝350。那么分类数据集1中关于通信连接建立时长的评估项包括：通信连接建立时长：average/path＝/order/v1/getOrderDetail＝336；通信连接建立时长：50p/path＝/order/v1/getOrderDetail＝340；通信连接建立时长：90p/path＝/order/v1/getOrderDetail＝350；通信连接建立时长：95p/path＝/order/v1/getOrderDetail＝350；通信连接建立时长：99p/path＝/order/v1/getOrderDetail＝350。基于上述原理，针对分类数据集1中的页面渲染时长、加载总时长、服务端响应时长分别进行计算，本实施例在此不再赘述。

对于分类数据集2，其中包括的数据条数为1，以通信连接建立时长为例进行计算，得到的均值、50p、90p、95p、99p值都为370，那么分类数据集2中关于通信连接建立时长的评估项包括：通信连接建立时长：average/path＝/order/v1/getOrderList＝370；通信连接建立时长：50p/path＝/order/v1/getOrderList＝370；通信连接建立时长：90p/path＝/order/v1/getOrderList＝370；通信连接建立时长：95p/path＝/order/v1/getOrderList＝370；通信连接建立时长：99p/path＝/order/v1/getOrderList＝370。为避免赘述，分类数据集2中的页面渲染时长、加载总时长、服务端响应时长的计算本实施例不再详述。

对于分类数据集3，其中包括的数据条数为5，以通信连接建立时长为例进行计算，可构建数组arr＝[300,320,340,350,370]，那么分类数据集3中关于通信连接建立时长的评估项包括：通信连接建立时长:average＝(336+370)/2＝353；通信连接建立时长:50p＝arr[int(5*0.5)]＝340；通信连接建立时长:90p＝arr[int(5*0.9)]＝370；通信连接建立时长:95p＝arr[int(5*0.95)]＝370；通信连接建立时长:99p＝arr[int(5*0.99)]＝370；为避免赘述，分类数据集3中的页面渲染时长、加载总时长、服务端响应时长的计算本实施例不再详述。

可见，对于目标响应数据，可对前端所收集的通信连接建立时长、服务端响应时长、页面渲染时长和/或加载总时长进行计算和处理。一般地，一个请求中的这4个参数中的至少一个超过阈值，则认为该请求的响应数据属于异常响应数据。

在一种具体实施方式中，若异常响应数据为：报错响应数据，则按照上述原理，统计不同路径、不同页面的报错次数，得到相应的性能评估数据。报错响应数据中不包含通信连接建立时长、服务端响应时长、页面渲染时长和/或加载总时长等参数，本实施例转而统计每一维度的报错次数。也即：针对异常响应数据，也计算同一页面或同一路径中报错次数average、50p、90p、95p、99p，计算方式参照前述相应介绍。

需要说明的是，计算average、50p、90p、95p、99p，可以据此计算结果判断项目或页面或路径的好坏程度，而好坏程度除了跟响应时间、渲染时间等有关，还与一定时间段内触发的请求次数有关，次数越多代表对应的页面效果更差。

S103、若任意维度的性能评估数据达到预设报警条件，则对该维度进行报警。

以上述示例为例，如果“average/path＝/order/v1/getOrderDetail＝336”中的336超过其对应的报警阈值，则可以对路径1：path＝/order/v1/getOrderDetail以及其通信连接建立时长的平均值进行报警。可见，本实施例对任意维度的性能评估数据进行报警时，可逐项报警，因此可以更为精准地定位前端问题。在一种具体实施方式中，若任意维度的性能评估数据达到预设报警条件，则对该维度进行报警，包括：将至少两个维度的性能评估数据发送至性能监控平台，以使性能监控平台在确定任意维度的性能评估数据达到预设报警条件时，推送报警通知消息至预设目的端。预设目的端如：预设邮箱地址等。

由上述示例可知，一个维度的性能评估数据中包括至少一个评估项，本实施例可以针对每一评估项设定相应的报警阈值，因此在某一评估项超过其报警阈值时，可对该评估项进行报警。在一种具体实施方式中，若任意维度的性能评估数据达到预设报警条件，则对该维度进行报警，包括：针对任意维度的性能评估数据中的每一评估项，若当前评估项超过其对应的报警阈值，则对当前评估项进行报警。例如：某一评估项的取值为40，如果针对该评估项设定的报警阈值为35，那么该评估项就会引起报警。

本实施例仅收集有问题的前端响应数据，可以减少需收集的数据量，节约存储资源和网络资源，并且从路径、页面、项目维度进行对前端异常响应数据进行计算和处理，可从不同颗粒度分析数据，为前端性能评估提供更有利的数据支撑。

可见，本实施例不关注前端正常响应数据，因此可以降低数据处理量，提高分析效率；并且，本申请从项目维度、页面维度和路径维度中的至少两个维度对异常响应数据进行性能评估，因此可得到至少两个维度的性能评估数据，由此便可从多个维度评估前端性能，使得数据分析和评估的颗粒度更精细、更全面；当任意维度的性能评估数据达到预设报警条件时，本申请可对该维度进行报警，从而可以发现前端问题所在。

基于上述实施例在设计具体的软件程序时，可以对软件程序进行模块划分，使代码功能的分工更加明确，代码更加健壮以及扩展性较强。

请参见图2，用户创建工作流实例的软件程序主要实现有以下功能：软件程序的接口接收前端的异常性能数据(即异常响应数据)，并存储到内存队列；定时使内存队列中的所有数据上传到数据库(如elastic search等)；每隔1分钟，从数据库中获取指定时间段内的异常性能数据，并对其进行计算，将计算后的各个监控项(即评估项)上传到性能监控平台(如open falcon等)，使得性能监控平台对各个监控项以阈值进行报警。

异常响应数据为：报错响应数据或目标响应数据。请参见图3，为实现上述软件程序，定义两个定时触发的内存队列，以分别暂存报错响应数据和目标响应数据；每一内存队列可使每一请求的响应数据依次排队进入队列，由此保障数据一致性。为了避免队列过大导致内存溢出，可以设置如下入库动作：(1)每隔10秒，使内存队列中的所有数据上传到数据库；(2)内存队列中的数量达到1000条，则将内存队列中的所有数据上传到数据库，并重置队列中的数量为0。

相应地，在数据库中定义性能信息表、异常信息表；性能信息表用于记录目标响应数据，异常信息表用于记录报错响应数据。针对性能信息表、异常信息表中的数据，可分别计算固定时间段内的响应数据的监控项，具体可参照上述实施例的相关介绍。对于计算得到的各监控项，将其上传至性能监控平台，以逐项确定是否需报警。

具体的，若用户打开前端页面时，有一瞬间的空白响应，且响应时间超过了设置的时间阈值，那么该页面信息、用户信息以及响应时间都会被收集，这些信息暂存在目标响应数据对应的内存队列中，该队列每10秒将其中的数据刷盘上传到数据库；每隔1分钟以uploadEsTimestamp字段从数据库中找一分钟内的目标响应数据出来进行运算，得到各个监控项；之后将各个监控项上传到性能监控平台，这样就可以通过查看指定监控项得出更加细化的性能分析数据，以定位前端异常问题。如果性能监控平台第一次接收到某一监控项，则需设置该监控项对应的报警阈值；如果本次上传到性能监控平台的监控项超出了其对应的报警阈值，则可以在绑定的钉钉群中报警通知。

可见，本实施例对性能数据的收集增加了阈值过滤，可以降低数据收集量，为后续数据分析减少压力；并且，通过队列定时存储异常数据，可有效减少数据频繁传输的资源消耗，数据库elastic search可提供更合适的数据存储能力，便于搜索数据的详细信息，以定位问题。更为重要的是，本实施例从项目维度、路径path维度和页面维度统计数据，更有利于得到多方位且不同颗粒度的评估数据，得到的监控项更加全面、更细致，可以更好的达到前端监控性能的目的，使监控的有效性更高。

下面对本申请实施例提供的一种前端性能监控装置进行介绍，下文描述的一种前端性能监控装置与上文描述的一种前端性能监控方法可以相互参照。

参见图4所示，本申请实施例公开了一种前端性能监控装置，包括：

获取模块401，用于获取前端在预设时间段内产生的异常响应数据；

评估模块402，用于从至少两个维度对异常响应数据进行性能评估，得到至少两个维度的性能评估数据；至少两个维度从项目维度、页面维度和路径维度中确定；

报警模块403，用于若任意维度的性能评估数据达到预设报警条件，则对该维度进行报警。

在一种具体实施方式中，获取模块具体用于：

在数据库中查询异常响应数据。

在一种具体实施方式中，还包括：

入库存储模块，用于获取前端发送的报错响应数据和/或响应时间超过预期的目标响应数据；按照时间戳顺序将报错响应数据和/或目标响应数据暂存至相应内存队列；将内存队列中的数据作为异常响应数据存储至数据库。

在一种具体实施方式中，入库存储模块还用于：

判断内存队列中的数据量是否达到预设队列阈值；

若是，则执行将内存队列中的数据作为异常响应数据存储至数据库的步骤；

或

判断当前是否达到入库时间点；

若是，则执行将内存队列中的数据作为异常响应数据存储至数据库的步骤。

在一种具体实施方式中，评估模块具体用于：

从至少两个维度对异常响应数据进行分类，得到至少两个维度分别对应的分类数据集；

针对每一分类数据集，确定当前分类数据集中的数据条数以及需评估的目标参数；基于数据条数计算目标参数的平均值，并为目标参数选择至少一个需监控值；

将平均值和/或至少一个需监控值作为当前分类数据集的评估项；

汇总同一维度所对应分类数据集的评估项，得到该维度的性能评估数据。

在一种具体实施方式中，评估模块具体用于：

将当前分类数据集中目标参数的各个取值构建为数组；

将数组中处于目标位置的数值作为需监控值；目标位置为：数组中的50％位置、90％位置、95％位置和99％位置中的至少一个。

在一种具体实施方式中，报警模块具体用于：

将至少两个维度的性能评估数据发送至性能监控平台，以使性能监控平台在确定任意维度的性能评估数据达到预设报警条件时，推送报警通知消息至预设目的端。

在一种具体实施方式中，报警模块具体用于：

若任意维度的性能评估数据达到预设报警条件，则对该维度进行报警，包括：

针对任意维度的性能评估数据中的每一评估项，若当前评估项超过其对应的报警阈值，则对当前评估项进行报警。

其中，关于本实施例中各个模块、单元更加具体的工作过程可以参考前述实施例中公开的相应内容，在此不再进行赘述。

可见，本实施例提供了一种前端性能监控装置，能够更精细地评估前端性能，并提高前端性能监控效率。

下面对本申请实施例提供的一种电子设备进行介绍，下文描述的一种电子设备与上文描述的一种前端性能监控方法及装置可以相互参照。

参见图5所示，本申请实施例公开了一种电子设备，包括：

存储器501，用于保存计算机程序；

处理器502，用于执行所述计算机程序，以实现上述任意实施例公开的方法。

进一步的，本申请实施例还提供了一种电子设备。其中，上述电子设备既可以是如图6所示的服务器50，也可以是如图7所示的终端60。图6和图7均是根据一示例性实施例示出的电子设备结构图，图中的内容不能被认为是对本申请的使用范围的任何限制。

图6为本申请实施例提供的一种服务器的结构示意图。该服务器50，具体可以包括：至少一个处理器51、至少一个存储器52、电源53、通信接口54、输入输出接口55和通信总线56。其中，所述存储器52用于存储计算机程序，所述计算机程序由所述处理器51加载并执行，以实现前述任一实施例公开的发布应用程序的监控中的相关步骤。

本实施例中，电源53用于为服务器50上的各硬件设备提供工作电压；通信接口54能够为服务器50创建与外界设备之间的数据传输通道，其所遵循的通信协议是能够适用于本申请技术方案的任意通信协议，在此不对其进行具体限定；输入输出接口55，用于获取外界输入数据或向外界输出数据，其具体的接口类型可以根据具体应用需要进行选取，在此不进行具体限定。

另外，存储器52作为资源存储的载体，可以是只读存储器、随机存储器、磁盘或者光盘等，其上所存储的资源包括操作系统521、计算机程序522及数据523等，存储方式可以是短暂存储或者永久存储。

其中，操作系统521用于管理与控制服务器50上的各硬件设备以及计算机程序522，以实现处理器51对存储器52中数据523的运算与处理，其可以是Windows Server、Netware、Unix、Linux等。计算机程序522除了包括能够用于完成前述任一实施例公开的发布应用程序的监控方法的计算机程序之外，还可以进一步包括能够用于完成其他特定工作的计算机程序。数据523除了可以包括应用程序的更新信息等数据外，还可以包括应用程序的开发商信息等数据。

图7为本申请实施例提供的一种终端的结构示意图，该终端60具体可以包括但不限于智能手机、平板电脑、笔记本电脑或台式电脑等。

通常，本实施例中的终端60包括有：处理器61和存储器62。

其中，处理器61可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器61可以采用DSP(Digital Signal Processing，数字信号处理)、FPGA(Field－Programmable Gate Array，现场可编程门阵列)、PLA(Programmable Logic Array，可编程逻辑阵列)中的至少一种硬件形式来实现。处理器61也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称CPU(Central ProcessingUnit，中央处理器)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器61可以在集成有GPU(Graphics Processing Unit，图像处理器)，GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器61还可以包括AI(Artificial Intelligence，人工智能)处理器，该AI处理器用于处理有关机器学习的计算操作。

存储器62可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器62还可包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。本实施例中，存储器62至少用于存储以下计算机程序621，其中，该计算机程序被处理器61加载并执行之后，能够实现前述任一实施例公开的由终端侧执行的发布应用程序的监控方法中的相关步骤。另外，存储器62所存储的资源还可以包括操作系统622和数据623等，存储方式可以是短暂存储或者永久存储。其中，操作系统622可以包括Windows、Unix、Linux等。数据623可以包括但不限于应用程序的更新信息。

在一些实施例中，终端60还可包括有显示屏63、输入输出接口64、通信接口65、传感器66、电源67以及通信总线68。

本领域技术人员可以理解，图7中示出的结构并不构成对终端60的限定，可以包括比图示更多或更少的组件。

下面对本申请实施例提供的一种可读存储介质进行介绍，下文描述的一种可读存储介质与上文描述的一种前端性能监控方法、装置及设备可以相互参照。

一种可读存储介质，用于保存计算机程序，其中，所述计算机程序被处理器执行时实现前述实施例公开的前端性能监控方法。关于该方法的具体步骤可以参考前述实施例中公开的相应内容，在此不再进行赘述。可读存储介质为计算机可读存储介质，该计算机可读存储介质可以是非暂态的，具体可以为高速随机存取存储器，以及非易失性存储器等。

本申请涉及的“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法或设备固有的其它步骤或单元。

需要说明的是，在本申请中涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本申请要求的保护范围之内。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的可读存储介质中。

本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。