掌桥专利:专业的专利平台
掌桥专利
首页

一种程序性能的确定方法和装置、电子设备和存储介质

文献发布时间:2023-06-19 13:26:15


一种程序性能的确定方法和装置、电子设备和存储介质

技术领域

本申请涉及分析技术领域,尤其涉及一种程序性能的确定方法和装置、电子设备和存储介质。

背景技术

相关技术中采用数据埋点进行应用程序的性能分析,比如注册账号、登录、点赞、评论等等。通常事件包括点击事件(用户点击按钮即算点击事件,不管点击后有无结果)、曝光事件(成功打开一次页面记一次,刷新页面一次记一次,加载下一页新页,加载一次记一次)、页面停留时间事件(表示一个用户在X页面的停留时长记为停留时长)等。

相关技术中,同一时间的不同埋点数据可能会对同一事件进行记录,进而存在事件记录重复,导致采用重复的事件记录对应用程序重复分析,进行导致性能浪费的问题。

针对相关技术中存在的采用重复的事件记录对应用程序重复分析,进行导致性能浪费的技术问题,目前尚未提供有效的解决方案。

发明内容

为了解决上述采用重复的事件记录对应用程序重复分析,进行导致性能浪费技术问题,本申请提供了一种程序性能的确定方法和装置、电子设备和存储介质。

第一方面,本申请实施例提供了一种程序性能的确定方法,包括:

获取目标程序触发的目标事件,其中,所述目标事件为所述目标程序响应于对所述目标程序中的目标页面元素的目标操作后触发;

按照所述目标事件的触发时间,生成所述目标事件对应的事件记录;

通过所述事件记录确定所述目标程序的响应性能。

可选地,如前述的方法,在所述目标事件包括至少两个的情况下,所述通过所述事件记录确定所述目标程序的响应性能包括:

在所有所述事件记录中,确定出对应于同一目标交互行为的事件记录组,其中,所述事件记录组包括:所述目标程序执行请求操作对应的第一事件的第一事件记录,以及所述目标程序执行获取操作对应的第二事件的第二事件记录,所述请求操作用于指示所述目标程序为了实现所述目标交互行为向目标服务器发送目标请求,所述获取操作用于指示所述目标程序获取所述目标服务器响应所述目标请求反馈的响应数据;

根据所述第二事件记录中的第二触发时间与所述第一事件记录中的第一触发时间之间的时间差,确定出所述目标交互行为对应的交互周期;

根据所述交互周期确定所述目标程序的响应性能。

可选地,如前述的方法,所述在所有所述事件记录中,确定出对应于同一目标交互行为的事件记录组包括:

对于每个所述事件记录,获取所述事件记录中的接口信息,其中,所述接口信息用于指示所述事件记录对应的事件中,所述目标程序对目标服务器进行通信的接口;

按照所述接口信息对所有所述事件记录进行分组,得到所述事件记录组,其中,同一个所述事件记录组中的不同的所述事件记录中具有相同的所述接口信息。

可选地,如前述的方法,所述根据所述交互周期确定所述目标程序的响应性能包括:

根据所述事件记录组对应的所述接口信息,确定所述目标服务器中与所述事件记录组对应的目标服务,其中,所述目标服务器中的服务与所述接口信息一一对应;

将所述交互周期确定为所述目标服务的当前响应效率;

通过将所述当前响应效率与所述目标服务的预设响应效率进行比对,确定出所述目标服务的子响应性能;

根据所述子响应性能得到出所述目标程序的响应性能。

可选地,如前述的方法,在所述通过所述事件记录确定所述目标程序的响应性能之前,所述方法还包括:

获取待分析的所有所述事件记录的记录数量;

在所述记录数量达到预设数量的情况下,执行用于跳转至所述通过所述事件记录确定所述目标程序的响应性能的跳转操作;

在所述记录数量未达到预设数量的情况下,继续获取所述目标程序触发的事件。

可选地,如前述的方法,在所述按照所述目标事件的触发时间,生成所述目标事件对应的事件记录之后,所述方法还包括:

在确定所述目标程序完成对所述目标操作的响应触发的最后事件的情况下,确定所述最后事件的最后触发时间。

可选地,如前述的方法,在所述确定所述最后事件的最后触发时间之后,所述方法还包括:

判断所述目标操作对应的所有事件记录中是否记录有所述目标程序响应于所述目标操作触发的第一个事件的初始时间;

在确定所述目标操作对应的所有事件记录中记录有所述初始时间的情况下,执行用于跳转至所述通过所述事件记录确定所述目标程序的响应性能的跳转操作;

在确定所述目标操作对应的所有事件记录中未记录有所述初始时间的情况下,对所述目标操作对应的所有事件记录进行删除。

第二方面,本申请实施例提供了一种程序性能的确定装置,包括:

获取模块,用于获取目标程序触发的目标事件,其中,所述目标事件为所述目标程序响应于对所述目标程序中的目标页面元素的目标操作后触发;

生成模块,用于按照所述目标事件的触发时间,生成所述目标事件对应的事件记录;

确定模块,用于通过所述事件记录确定所述目标程序的响应性能。

第三方面,本申请实施例提供了一种电子设备,包括:处理器、通信接口、存储器和通信总线,其中,所述处理器、通信接口和存储器通过通信总线完成相互间的通信;

所述存储器,用于存放计算机程序;

所述处理器,用于执行所述计算机程序时,实现如前述任一项所述的方法。

第四方面,本申请实施例提供了一种计算机可读存储介质,所述存储介质包括存储的程序,其中,所述程序运行时执行如前任一项所述的方法。

本申请实施例提供的上述技术方案与现有技术相比具有如下优点:

本申请实施例提供了一种程序性能的确定方法和装置、电子设备和存储介质,包括:获取目标程序触发的目标事件,其中,所述目标事件为所述目标程序响应于对所述目标程序中的目标页面元素的目标操作后触发;按照所述目标事件的触发时间,生成所述目标事件对应的事件记录;通过所述事件记录确定所述目标程序的响应性能。的该方法,通过本实施例中的方法,通过按照触发时间对各个事件进行记录,可以便于在分析时可以按照触发时间,并根据各个事件记录计算得到目标程序的响应性能,进而可以解决采用重复的事件记录对应用程序重复分析,进行导致性能浪费的问题。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本发明的实施例,并与说明书一起用于解释本发明的原理。

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

图1为本申请实施例提供的一种程序性能的确定方法的流程示意图;

图2为本申请实施例另一提供的一种程序性能的确定方法的流程示意图;

图3为本申请实施例另一提供的一种程序性能的确定方法的流程示意图;

图4为本申请实施例提供的一种时间段事件的上报和/或存储过程的流程示意图;

图5为本申请一个应用例提供的一种程序性能的确定装置的框图;

图6为本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

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

根据本申请实施例的一个方面,提供了一种程序性能的确定方法。可选地,在本实施例中,上述程序性能的确定方法可以应用于由终端和服务器所构成的硬件环境中。服务器通过网络与终端进行连接,可用于为终端或终端上安装的客户端提供服务(如广告推送服务、应用服务等),可在服务器上或独立于服务器设置数据库,用于为服务器提供数据存储服务。

上述网络可以包括但不限于以下至少之一:有线网络,无线网络。上述有线网络可以包括但不限于以下至少之一:广域网,城域网,局域网,上述无线网络可以包括但不限于以下至少之一:WIFI(Wireless Fidelity,无线保真),蓝牙。终端可以并不限定于为PC、手机、平板电脑等。

本申请实施例的程序性能的确定方法可以由服务器来执行,也可以由终端来执行,还可以是由服务器和终端共同执行。其中,终端执行本申请实施例的程序性能的确定方法也可以是由安装在其上的客户端来执行。

以由终端来执行本实施例中的程序性能的确定方法为例,图1为本申请实施例提供的一种程序性能的确定方法,包括如下所述步骤:

步骤S101,获取目标程序触发的目标事件,其中,目标事件为目标程序响应于对目标程序中的目标页面元素的目标操作后触发;

本实施例中的程序性能的确定方法可以应用于需要确定终端的应用程序针对某种操作进行响应的性能(例如,响应时长)的场景,例如:应用程序开启的性能的场景、网页端程序登录的性能的场景等,也可以是对其他程序进行其他操作时的场景。本申请实施例中以应用程序为例说明上述的程序性能的确定,对于其他类型的程序,在不矛盾的情况下,上述的程序性能的确定同样适用。

以应用程序开启的性能的场景为例,通过对所有应用程序针对开启过程中的每个操作的响应,确定出应用程序的响应性能。

目标程序触发的目标事件,可以是目标程序的目标页面中的目标页面元素被执行目标操作后触发的事件。例如,目标事件可以是用户点击应用程序图标后,触发打开该图标对应的应用程序的事件。

目标页面元素可以是能够被操作的元素,并且,目标页面元素一般情况下具有对应的操作类型,也就是说,只有在对目标页面元素进行对应操作类型的操作之后,才能使目标程序触发目标事件。例如,在目标页面元素为展示在终端主界面的应用程序图标时,则对应的目标操作为点击操作,并且在应用程序图标被执行点击操作之后,对应的目标事件则为打开该应用程序图标对应的目标程序,并完成程序加载。

步骤S102,按照目标事件的触发时间,生成目标事件对应的事件记录。

在目标程序触发目标事件之后,则可以确定出目标事件的触发时间,并对该目标事件的相关信息进行记录,得到目标事件对应的事件记录。

目标事件的触发事件可以通过埋点进行记录,例如,设置开始时间startTime为打开APP(即,目标程序)的时间点,结束时间endTime为APP加载完成的时间点,从startTime到endTime中间APP请求服务器获取数据、校验token等设置为中间点pointTime。在埋点确定APP启动的同时生成一条用于指示APP启动的事件记录;APP加载过程中请求服务器获取数据的同时,将发送一条或多条事件记录,用于对进行数据请求的事件或者进行数据获取的事件进行记录;APP全部加载完成同时生成一条用于指示APP加载完成的事件记录。并且,在每个事件记录中,可以包括对应事件的触发时间的时间信息,以及事件的类型等信息,进而,即使将时间记录发送至其他设备进行处理,仍然可以确定各个事件的触发时间。

步骤S103,通过事件记录确定目标程序的响应性能。

在获取事件记录之后,即可根据事件记录确定出目标程序的响应性能。

响应性能可以是能够指示目标程序对于目标操作的响应的快慢的性能,当目标程序需要对远程服务器进行目标服务访问以完成响应的情况下,响应性能还可以用于指示服务器针对该目标服务访问的性能。

当通过多个事件记录可以确定目标程序的多个响应的情况下,则可以通过多个事件记录确定目标程序针对多个响应中的每个响应的响应性能。并且,在分析响应性能时,可以按照事件记录中的触发时间,可以先对事件记录按照触发时间进行去重,即,同一触发时间的事件记录只取其中一个用于进行响应性能的计算,避免采用多个对应于同一触发时间的时间记录进行响应性能的分析,造成性能浪费。

例如,当事件记录只包括两个(例如,包括:用于触发响应A的事件记录和用于指示响应A完成的事件记录)时,则可以用于确定目标程序针对响应A的响应性能。

通过本实施例中的方法,通过按照触发时间对各个事件进行记录,可以便于在分析时可以按照触发时间,并根据各个事件记录计算得到目标程序的响应性能,进而可以解决采用重复的事件记录对应用程序重复分析,进行导致性能浪费的问题。

如图2所示,作为一种可选的实施方式,如前述的方法,在目标事件包括至少两个的情况下,所述步骤S103通过事件记录确定目标程序的响应性能包括如下所述步骤:

步骤S201,在所有事件记录中,确定出对应于同一目标交互行为的事件记录组,其中,事件记录组包括:目标程序执行请求操作对应的第一事件的第一事件记录,以及目标程序执行获取操作对应的第二事件的第二事件记录,请求操作用于指示目标程序为了实现目标交互行为向目标服务器发送目标请求,获取操作用于指示目标程序获取目标服务器响应目标请求反馈的响应数据。

在确定出所有事件记录之后,由于相关技术中的应用大多数需要与服务器进行数据交互,因此一个数据交互行为至少会包括两个事件,即对应有请求的事件,以及接收服务器响应请求发送的数据的事件,因此,对应于同一个目标交互行为的事件记录组中也至少包括两个事件记录,即,目标程序执行请求操作对应的第一事件的第一事件记录,以及目标程序执行获取操作对应的第二事件的第二事件记录,除此之外,还可以包括其它事件对应的事件记录。

在所有事件记录中,确定出对应于同一目标交互行为的事件记录组的方法可以是:确定每个事件对应的请求的接口,或者获取每个事件对应的请求体(其中包括请求的接口);进而可以通过接口确定出各个事件记录是否对应于同一个事件记录组。

作为一种可选的实施方式,如前述的方法,所述步骤S201在所有事件记录中,确定出对应于同一目标交互行为的事件记录组包括如下所述步骤:

步骤S301,对于每个事件记录,获取事件记录中的接口信息,其中,接口信息用于指示事件记录对应的事件中,目标程序对目标服务器进行通信的接口。

在每个事件记录中,可以包括所记录事件的接口信息,并且该接口信息为对应的事件中,目标程序与目标服务器进行通信的接口的信息。因此,可以通过事件记录确定出每个事件对应的接口。

步骤S302,按照接口信息对所有事件记录进行分组,得到事件记录组,其中,同一个事件记录组中的不同的事件记录中具有相同的接口信息。

一般的,对于目标服务器来说,每个接口对应于的服务都是固定的,因此,在确定每个事件记录的接口信息之后,即可根据接口信息对所有事件记录进行分组,得到事件记录组,一般的,每个事件记录组中会包括至少两个事件记录,并且,同一个事件记录组中的不同的事件记录中具有相同的接口信息。

例如,当包括事件记录I、事件记录II、事件记录III、事件记录IV时,若事件记录II中的接口信息与事件记录III中的接口信息一致时,则事件记录II和事件记录III可以被分至同一个事件记录组中。

进而,采用本实施例中的方法,可以快速确定出对应于同一个目标交互行为的事件记录组。

步骤S202,根据第二事件记录中的第二触发时间与第一事件记录中的第一触发时间之间的时间差,确定出目标交互行为对应的交互周期。

在事件记录中,会记录有事件对应的触发时间,因此,可以根据第二事件记录中的第二触发时间与第一事件记录中的第一触发时间之间的时间差,确定出目标交互行为对应的交互周期。

交互周期可以是用于指示完成目标交互行为所需的总时长。

例如,当第二事件记录中的第二触发时间为2021年9月22日14:48:15,第一事件记录中的第一触发时间为2021年9月22日14:48:12时,则时间差为3秒,则确定出目标交互行为对应的交互周期为3秒。

步骤S203,根据交互周期确定目标程序的响应性能。

在确定出交互周期之后,可以直接将交互周期作为目标程序的响应性能,在此情况下,交互周期越长,响应性能越低。

还可以通过对交互周期t进行换算,计算为用于评价目标程序的响应性能的评价值R,例如:R=100(K-t)/K;其中,K为常数,例如10,则当交互周期t为3时,R为70。

可选的,步骤S202以及步骤S203中的相关步骤的实现方式,还可以在服务器端实现,即,终端将事件记录发送至数据分析服务器,以使数据分析服务器执行上述步骤S202以及步骤S203。并且终端在将时间记录发送至数据分析服务器之前,可以按照触发时间对各个事件记录进行去重,每个触发时间只保留一个事件记录。

通过本实施例中的方法,可以基于事件记录中的触发时间,快速计算得到目标程序的交互周期,并通过交互周期计算得到对应的响应性能,进而达到了通过事件记录对目标程序的性能进行分析的目的。

如图3所示,作为一种可选的实施方式,如前述的方法,所述步骤S203根据交互周期确定目标程序的响应性能包括如下所述步骤:

步骤S401,根据事件记录组对应的接口信息,确定目标服务器中与事件记录组对应的目标服务,其中,目标服务器中的服务与接口信息一一对应;

步骤S402,将交互周期确定为目标服务的当前响应效率;

步骤S403,通过将当前响应效率与目标服务的预设响应效率进行比对,确定出目标服务的子响应性能;

步骤S404,根据子响应性能得到出目标程序的响应性能。

在确定出时间记录组之后,按照前述方法可以确定出事件记录组的接口信息,进而可以按照事件记录组的接口信息确定出与该时间记录组对应的目标服务。

进一步的,在前述步骤S202中已计算得到交互周期,进而,可以根据交互周期确定出目标服务器的当前相应效率,并且交互周期越长,对应的当前响应效率也越低。

预先的,可以事先确定目标服务分别与不同的响应性能值对应的预设响应效率,可选地,与每个子响应性能对应的预设响应效率可以是一个区间值,进而可以将包括当前响应效率的预设响应效率所对应的响应性能值作为子响应性能。

可以按照上述方法确定目标程序对应于每个服务的子响应性能,进而得到目标程序的响应性能。

例如,当服务A的当前响应效率为3秒,并且在服务A下,预设响应效率T与响应性能值P之间的对应关系为:(0,1)对应于100,[1,2)对应于90,[2,3)对应于80,[3,4)对应于70,……,[9,+∞)对应于10等等。进而可以确定出服务A对应的区间为[3,4),因此服务A的子响应性能为70。在得到服务A的子响应性能为70之后,可以按照上述方法,确定出其他服务的子响应性能,最后按照每个服务对应的权重,对各个子响应性能进行加权后,计算得到目标程序的响应性能。

通过本实施例中的方法,可以快速确定出目标程序的响应性能。

作为一种可选的实施方式,如前述的方法,在所述步骤S103通过事件记录确定目标程序的响应性能之前,方法还包括如下所述步骤:

步骤S501,获取待分析的所有事件记录的记录数量;

步骤S502,在记录数量达到预设数量的情况下,执行用于跳转至通过事件记录确定目标程序的响应性能的跳转操作;

步骤S503,在记录数量未达到预设数量的情况下,继续获取目标程序触发的事件。

记录数量为所有事件记录的总数量,当记录数量少于预设数量(例如,10个)的情况下,说明该记录数量过少,继续获取目标程序触发的事件。

当记录数量达到预设数量的情况,执行用于跳转至通过事件记录确定目标程序的响应性能的跳转操作。即,通过事件记录确定目标程序的响应性能。

进一步的,响应性能的分析可以通过指定的性能分析服务器进行分析,因此,在记录数量达到预设数量的情况下,将所有事件记录发送给性能分析服务器,在记录数量达到预设数量的情况下,继续进行事件记录的生成,直至事件记录的数量达到预设数量为止,才将所有未发送的事件记录发送给性能分析服务器。因此,在记录数量达到预设数量的情况下,执行用于跳转至通过事件记录确定目标程序的响应性能的跳转操作,可以是:在记录数量达到预设数量的情况下,将所有事件记录发送给性能分析服务器,以使性能分析服务器通过事件记录分析得到目标程序的响应性能。

通过本实施例中的方法,只在记录数量达到预设数量的情况下,才执行用于跳转至通过事件记录确定目标程序的响应性能的跳转操作,可以避免在事件记录无法构成一个完整交互周期的情况下执行无效的分析,并且可以在响应性能的分析需要在服务器端执行的情况下,避免频繁的对服务器进行访问,影响服务器的性能。

作为一种可选的实施方式,如前述的方法,在所述步骤S102按照目标事件的触发时间,生成目标事件对应的事件记录之后,方法还包括如下所述步骤:

步骤S601,在确定目标程序完成对目标操作的响应触发的最后事件的情况下,确定最后事件的最后触发时间。

也就是说,在目标程序完成对目标操作的响应触发的最后事件的情况下,将该最后事件对应的时间记录为最后触发事件。

例如,在目标程序的图标被点击后,进过多个事件之后,完成加载,则将完成加载记为最后事件,并将完成加载的时间记为最后触发时间。

作为一种可选的实施方式,如前述的方法,在所述步骤确定最后事件的最后触发时间之后,方法还包括如下所述步骤:

步骤S701,判断目标操作对应的所有事件记录中是否记录有目标程序响应于目标操作触发的第一个事件的初始时间。

可以通过埋点的方式获取,目标程序在被执行目标操作之后触发的所有事件的事件记录,并且,由于每个事件记录中包括有触发时间,以及事件的类型等信息,因此,可以确定出所有事件记录中是否记录有目标程序响应于目标操作触发的第一个事件的初始时间。

可选地,可以通过确定事件被触发的条件(事件记录中可以记录相关信息),确定出第一个事件。例如,当事件a被触发的条件为目标应用的图标被点击,则可判定为该事件a为第一个事件,并且事件a的事件记录中的触发时间为初始事件。

步骤S702,在确定目标操作对应的所有事件记录中记录有初始时间的情况下,执行用于跳转至通过事件记录确定目标程序的响应性能的跳转操作。

步骤S703,在确定目标操作对应的所有事件记录中未记录有初始时间的情况下,对目标操作对应的所有事件记录进行删除。

在确定出目标操作的初始时间以及最后触发时间之后,即可将在初始时间与最后触发时间之间的时间段中的事件记为目标程序针对于目标操作的所有中间点事件,并且,可以确定目标程序针对与目标操作的所有事件的事件记录均记录完整,进而可以执行用于跳转至通过事件记录确定目标程序的响应性能的跳转操作,以通过所有事件记录分析得到目标程序的响应性能;反之,在确定目标操作对应的所有事件记录中未记录有初始时间的情况下,通过所有事件记录无法分析得到目标程序的响应性能,则可对目标操作对应的所有事件记录进行删除。

如图4所示,根据本申请前述任一实施例中的方法,提供如下所述的应用例:

首先,定义一种用于记录用户某个动作的开始到结束的过程中发生的一系列事件,即时间段事件,并定义了该时间段事件的事件记录的模板(可以包括如下所述字段信息:事件ID、状态(1:开始,2:中间时间点,3:结束)、params字段(即,事件的类型):具体事件的业务属性。比如视频播放事件可以在params中放视频名称等。如果没有业务需要该字段也可以为空),通过该类型的事件记录对用户的操作行为进行准确记录,便于后续对用户行为数据的准确分析。

时间段事件需要设置开始时间、结束时间和中间点时间,该事件记录的是从开始时间到结束时间的这个时间段内,用户的一系列操作(例如,目标操作)以及APP(即,目标程序)的一系列处理,时间段内的一系列事件都可以设置为中间点。请求参数中可以包含标识事件状态(即开始、中间点、结束)的字段,假设该字段为status,1表示开始(即,初始时间),2表示中间时间点(即,触发时间),3表示结束(即,最后触发时间)。例如:设置开始时间startTime为打开APP的时间点,结束时间endTime为APP加载完成的时间点,从startTime到endTime中间APP请求服务器获取数据、校验token等设置为中间点pointTime。APP启动的同时发送一条事件记录请求(用于生成事件记录的请求),status为1,此时增加一条新纪录;APP加载过程中请求服务器获取数据的同时,将发送一条或多条事件请求记录(即,事件记录),status为2,每发送一个中间点事件则更新一条时间段事件记录;APP全部加载完成同时发送一条事件记录请求,status为3,后台接口根据时间差计算事件发生的时间存入数据库。整体数据统计出来后,就可以用于分析APP的性能,分析出哪一步响应比较慢,从而进行优化。也可以将该事件埋在用户打开APP到登录完成这个时间段内。

当根据一个触发条件触发时间段事件时,时间段事件的上报和/或存储过程可以包括:

服务器收到记录时间段事件的请求,首先判断该条事件的状态,如果是开始(即,startTime),则插入一条新的记录用于记录该新的时间段事件,如果是中间点(即pointTime,状态既不是开始也不是结束)则更新该记录下最后一条时间段事件的记录(这条时间段事件已经记录了开始),如果是结束(即,endTime)则先看是否记录了开始状态的事件,没有的话说明没有记录到这个时间段事件对应的开始事件,那么这个时间段事件作废不记录,如果都不属于这三个状态说明不是合法的时间段事件,接口会返回相应错误信息提示。

判断是否是正式环境:测试服务器时,上拉取参数列表是为了测试时间段事件模板的参数是否正确,所以需要拉取参数列表,正式服务器中不需要这一步。

事件记录数量达到一定数值(即,触发值)时就会调用事件上报方法将事件上报到相应的服务器。

此时该事件的状态是开始,之后触发的中间点都会发送时间段事件记录请求,事件状态为中间时间点,当触发条件对应的所有事件结束时再发送一条时间段事件记录请求,此时事件状态为结束。

发送结束时间点后需要判断是否记录了对应的开始时间点,如果没有记录开始时间点,则该时间段事件将会被作废删除,如果有开始时间点记录,则根据时间差计算事件发生的时间并存入数据库中。当事件数量达到上报触发值,就会调用事件上报方法将事件全部上报给服务器。

如图5所示,根据本申请另一方面的一个实施例,还提供了一种服务器性能的确定装置,包括:

获取模块1,用于获取目标程序触发的目标事件,其中,目标事件为目标程序响应于对目标程序中的目标页面元素的目标操作后触发;

生成模块2,用于按照目标事件的触发时间,生成目标事件对应的事件记录;

确定模块3,用于通过事件记录确定目标程序的响应性能。

具体的,本发明实施例的装置中各模块实现其功能的具体过程可参见方法实施例中的相关描述,此处不再赘述。

根据本申请的另一个实施例,还提供一种电子设备,包括:如图6所示,电子设备可以包括:处理器1501、通信接口1502、存储器1503和通信总线1504,其中,处理器1501,通信接口1502,存储器1503通过通信总线1504完成相互间的通信。

存储器1503,用于存放计算机程序;

处理器1501,用于执行存储器1503上所存放的程序时,实现上述方法实施例的步骤。

上述电子设备提到的总线可以是外设部件互连标准(Peripheral ComponentInterconnect,PCI)总线或扩展工业标准结构(Extended Industry StandardArchitecture,EISA)总线等。该总线可以分为地址总线、数据总线、控制总线等。为便于表示,图中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。

通信接口用于上述电子设备与其他设备之间的通信。

存储器可以包括随机存取存储器(Random Access Memory,RAM),也可以包括非易失性存储器(Non-Volatile Memory,NVM),例如至少一个磁盘存储器。可选的,存储器还可以是至少一个位于远离前述处理器的存储装置。

上述的处理器可以是通用处理器,包括中央处理器(Central Processing Unit,CPU)、网络处理器(Network Processor,NP)等;还可以是数字信号处理器(Digital SignalProcessor,DSP)、专用集成电路(Application Specific Integrated Circuit,ASIC)、现场可编程门阵列(Field-Programmable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

本申请实施例还提供一种计算机可读存储介质,存储介质包括存储的程序,其中,程序运行时执行上述方法实施例的方法步骤。

需要说明的是,在本文中,诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅是本发明的具体实施方式,使本领域技术人员能够理解或实现本发明。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的,本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下,在其它实施例中实现。因此,本发明将不会被限制于本文所示的这些实施例,而是要符合与本文所申请的原理和新颖特点相一致的最宽的范围。

技术分类

06120113678583