Network request duration determination method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention discloses a network request duration determination method and device, electronic equipment and a storage medium, and the method comprises the steps: responding to the triggering of a network request, and sequentially running the life cycle of a preset stage in the network request; in the running process of the life cycle, calling a corresponding operation plug-in, recording a first timestamp, receiving calling return of the operation plug-in, and recording a second timestamp; and according to the first timestamp and the second timestamp, determining the consumption duration of the network request in a preset dimension. Accurate and fine-grained time length measurement can be carried out on the network request.

Description

Technical Field

[0001] This disclosure relates to the field of communication technology, and in particular to a method, apparatus, electronic device, and storage medium for determining the duration of a network request. Background Technology

[0002] In application software (APP), the time taken to make network interface requests can be used as an important indicator of its quality. Related technologies allow APPs to determine a timestamp before initiating a network request, and then subtract the timestamp from the current time within the API's response processing logic to obtain the network request duration. However, because there is no unified industry standard for defining network request duration, the timing of timestamp determination and network request duration determination is unclear, leading to inconsistent and inaccurate measurement of network request duration. Summary of the Invention

[0003] This disclosure provides a method, apparatus, electronic device, and storage medium for determining the duration of a network request, which can accurately and finely measure the duration of a network request.

[0004] In a first aspect, embodiments of this disclosure provide a method for determining the duration of a network request, including:

[0005] In response to a network request, the lifecycle of the preset stages in the network request is executed sequentially.

[0006] During the lifecycle operation, the corresponding operation plugin is invoked and a first timestamp is recorded, and the return value of the operation plugin is received and a second timestamp is recorded.

[0007] Based on the first timestamp and the second timestamp, the duration of the network request in the preset dimension is determined.

[0008] Secondly, embodiments of this disclosure also provide a device for determining the duration of a network request, comprising:

[0009] The execution module is used to respond to the triggering of a network request and sequentially execute the lifecycle of the preset stages in the network request;

[0010] The timestamp recording module is used to call the corresponding operation plugin and record the first timestamp during the lifecycle operation, and to receive the call return of the operation plugin and record the second timestamp.

[0011] The duration determination module is used to determine the duration of the network request in a preset dimension based on the first timestamp and the second timestamp.

[0012] Thirdly, embodiments of this disclosure also provide an electronic device, the electronic device comprising:

[0013] One or more processors;

[0014] Storage device for storing one or more programs.

[0015] When the one or more programs are executed by the one or more processors, the one or more processors implement the method for determining the duration of a network request as described in any embodiment of this disclosure.

[0016] Fourthly, embodiments of this disclosure also provide a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform a method for determining the duration of a network request as described in any of the embodiments of this disclosure.

[0017] Fifthly, this disclosure also provides a computer program product, characterized in that the computer program product includes a computer program, which, when executed by a processor, implements the method for determining the network request duration as described in any of the embodiments of this disclosure.

[0018] In the technical solution of this disclosure embodiment, in response to the triggering of a network request, the lifecycle of a preset stage in the network request can be executed sequentially. During the lifecycle execution, the corresponding operation plugin is invoked and a first timestamp is recorded, and the return of the operation plugin is received and a second timestamp is recorded. Based on the first and second timestamps, the consumption time of the network request in a preset dimension is determined. By dividing the lifecycle of the network request into several preset stages, the lifecycle of each preset stage can be executed sequentially when the network request is triggered. By invoking the corresponding operation plugin in the lifecycle of each stage, not only can various business operations in the network request be executed, but the timestamps before and after the execution of each operation plugin can also be determined. Furthermore, based on the timestamps, the time consumption statistics of the preset stage lifecycle, operation plugins, and other preset dimensions can be performed, thereby achieving accurate and fine-grained measurement of the network request's duration. Attached Figure Description

[0019] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0020] Figure 1 A flowchart illustrating a method for determining network request duration provided in an embodiment of this disclosure;

[0021] Figure 2 A flowchart illustrating a method for determining network request duration provided in an embodiment of this disclosure;

[0022] Figure 3 A signaling interaction diagram illustrating a method for determining network request duration provided in an embodiment of this disclosure;

[0023] Figure 4 A schematic diagram of a network request duration determination device provided in an embodiment of this disclosure;

[0024] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0025] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0026] It should be understood that the steps described in the method embodiments of this disclosure may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this disclosure is not limited in this respect.

[0027] The term "comprising" and its variations as used herein are open-ended inclusions, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the description below.

[0028] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0029] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0030] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0031] Figure 1This is a flowchart illustrating a method for determining the duration of a network request according to an embodiment of this disclosure. This disclosure is applicable to situations requiring the determination of network request duration. The method can be executed by a device for determining the duration of a network request, which can be implemented in software and / or hardware and can be configured in an electronic device, such as a mobile phone or computer.

[0032] like Figure 1 As shown, the method for determining the network request duration provided in this embodiment may include:

[0033] S110. In response to the triggering of a network request, the lifecycle of the preset stages in the network request is executed sequentially.

[0034] In this context, the application software installed on the electronic device can be referred to as the client, and the apparatus executing the method for determining the duration of a network request provided in this disclosure can be considered as the client. A network request can be understood as a request from the client to obtain data from the server through a network interface. When there is a need to request data from the server, the client can trigger a network request. In response to the triggering of a network request, the client can run the code for the network request. The execution of the network request code can include several preset lifecycle stages, and the lifecycle of each preset stage can be executed according to a pre-set stage execution order.

[0035] The preset phase can include at least the pre-request phase, the request phase, and the post-request phase. The request phase can be understood as the phase where the client and server interact; the pre-request / post-request phases can be understood as the phase where the client unilaterally performs several operations before / after the request based on specific business requirements. Furthermore, the pre-request and post-request phases can be further subdivided into preset phases based on specific business scenarios.

[0036] For example, in the case of a network request for data from a content aggregation page, the pre-request stage may include inserting cached data into the page, thereby avoiding a blank content aggregation page before the data is requested and improving user experience. The post-request stage may include a data processing stage, such as clearing some data (e.g., masked data) from the requested data, thereby meeting diverse content display needs. It is understood that the division of the pre-request and post-request stages under different business scenarios, and their further fine-grained divisions, are all within the scope of protection of this embodiment and will not be exhaustively described here.

[0037] S120. During the lifecycle operation, the corresponding operation plugin is called and the first timestamp is recorded, and the return of the operation plugin is received and the second timestamp is recorded.

[0038] The operation plugins can be used to execute specific business operations within network requests. The code for several business operations can be pre-registered as plugins to their corresponding preset lifecycle phases. Furthermore, if at least two operation plugins are registered in a preset lifecycle phase, their execution order can be configured. Accordingly, during the execution of each preset lifecycle phase, the corresponding operation plugins can be called according to their execution order, and the timestamp of the call can be recorded as the first timestamp. Upon completion of the business operation executed by the operation plugin, its return value can be received, and the timestamp of the return value can be recorded as the second timestamp.

[0039] When the operation corresponding to the last plugin in the execution order of the current preset stage's lifecycle is completed, the lifecycle of the current preset stage can be considered complete. In response to the completion of the lifecycle of the current preset stage, the lifecycle of the next preset stage can continue to be executed until the lifecycle of each preset stage of the network request is completed. Then, the first and second timestamps corresponding to each operation plugin included in the lifecycle of each preset stage can be obtained.

[0040] S130. Determine the duration of network request consumption in the preset dimension based on the first timestamp and the second timestamp.

[0041] In this embodiment of the disclosure, the preset dimensions may include, but are not limited to, preset stage dimensions and / or operation plugin dimensions. When the preset dimensions include preset stage dimensions, the duration of each preset stage's lifecycle can be determined based on the difference between the first timestamp of the first called operation plugin and the second timestamp of the last called operation plugin within the lifecycle of each preset stage. When the preset dimensions include operation plugin dimensions, the duration of each operation plugin can be determined based on the difference between the first and second timestamps of each operation plugin. Specifically, the duration can be determined based on the difference in timestamps using an existing timestamp-duration conversion method.

[0042] Because clients typically perform several business operations before and after network requests, and there is no unified industry standard for defining network request duration, the timing for determining the timestamp before the network request and the timing for determining the network request duration within the processing logic returned by the interface are unclear, leading to inconsistent measurement of network request duration in related technologies. Furthermore, since different network requests execute numerous private business operations before and after the request, even when measuring network request duration under a unified standard, it may include the time consumed by some unknown private business operations, resulting in inaccurate measurement of network request duration. Therefore, the measurement of network request duration in related technologies is inconsistent and inaccurate.

[0043] In the method for determining the duration of a network request provided in this embodiment, the entire lifecycle of the network request is divided into multiple preset stages, and the code of several business operations is pre-registered as a plugin to the corresponding preset stage lifecycle. This allows for a more precise and clear segmentation of the duration of each preset stage and each operation plugin in the network request.

[0044] In some optional implementations, after determining the network request's consumption time in a preset dimension, at least one of the following is also included: in response to the preset dimension's consumption time exceeding a preset threshold, sending a timeout message to the server; sending the preset dimension's consumption time to the server so that the server displays the interface based on the consumption time.

[0045] Among these optional implementations, preset thresholds can be pre-set for the lifecycle of each preset stage and / or for each operation plugin. When the consumption time of a preset dimension exceeds the corresponding preset threshold, a timeout message corresponding to the preset dimension can be generated and sent to the server. This enables timely notification of exceptions during the request process, avoiding chain reactions caused by business timeouts and ensuring the efficient and stable operation of network services. Furthermore, the consumption time of preset dimensions for different network requests can be sent to the server at preset time intervals. The server can then analyze the received consumption time from different dimensions and display the results on a graphical interface. This provides an intuitive reference for identifying areas for optimization in software requests, facilitating targeted software iteration and optimization, and improving the user experience.

[0046] In the technical solution of this disclosure embodiment, in response to the triggering of a network request, the lifecycle of a preset stage in the network request can be executed sequentially. During the lifecycle execution, the corresponding operation plugin is invoked and a first timestamp is recorded, and the return of the operation plugin is received and a second timestamp is recorded. Based on the first and second timestamps, the consumption time of the network request in a preset dimension is determined. By dividing the lifecycle of the network request into several preset stages, the lifecycle of each preset stage can be executed sequentially when the network request is triggered. By invoking the corresponding operation plugin in the lifecycle of each stage, not only can various business operations in the network request be executed, but the timestamps before and after the execution of each operation plugin can also be determined. Furthermore, based on the timestamps, the time consumption statistics of the preset stage lifecycle, operation plugins, and other preset dimensions can be performed, thereby achieving accurate and fine-grained measurement of the network request's duration.

[0047] This embodiment can be combined with various optional solutions in the network request duration determination method provided in the above embodiments. In the network request duration determination method provided in this embodiment, sequentially running the lifecycle of a preset stage in the network request can include: distributing the lifecycle of the preset stage in the network request sequentially to the plugin manager through the network request manager, so that the plugin manager calls the operation plugin corresponding to the lifecycle, and receives the call return of the operation gap.

[0048] This disclosure provides an engineering architecture for network request code, which may include a network request manager and a plugin manager. It can be understood that the code for different network requests can be constructed according to this engineering architecture, and the code for the network request manager and plugin manager corresponding to different network requests can be identical. Therefore, during the execution of different network request code, the network request manager can sequentially distribute the lifecycle of a preset stage in the network request to the plugin manager; during the lifecycle of each preset stage, the plugin manager can call the corresponding operation plugin and record a first timestamp, and receive the return from the operation plugin call and record a second timestamp; and the plugin manager can determine the duration of the network request in a preset dimension based on the first and second timestamps.

[0049] Furthermore, it is understandable that at least one of the following may differ: the operation plugins corresponding to different network requests, the preset lifecycle of the operation plugins, and the execution order of the operation plugins. This allows for network requests in different business scenarios. For example, in the case of a network request for data from a content aggregation page, operation plugins may include, but are not limited to, caching plugins, deletion plugins, and affinity ranking plugins. Taking a caching plugin as an example, the caching plugin may correspond to the lifecycle of the data caching stage before the network request, or it may correspond to the lifecycle of the data processing stage after the network request.

[0050] This disclosure provides an engineering architecture for network request code. A network manager within the architecture can dispatch different preset lifecycle stages, and a plugin manager can invoke different operation plugins within these stages. This enables sliced ​​measurement of network request durations under different business scenarios. This not only helps in locating abnormal network interfaces during client operation and ensuring the efficient and stable operation of network services, but also provides a reference for client optimization to improve user experience.

[0051] Figure 2 This is a flowchart illustrating a method for determining network request duration provided in an embodiment of this disclosure. Figure 2 As shown, the method for determining the network request duration provided in this embodiment may include:

[0052] S210. In response to the triggering of a network request, the lifecycle of the preset stages in the network request is sequentially distributed to the plugin manager through the network request manager.

[0053] For example, Figure 3 This is a signaling interaction diagram illustrating a method for determining network request duration provided in an embodiment of this disclosure. See also... Figure 3 The client can respond to accessing a preset function page by triggering a network request, and can start and run the code for the network request based on the trigger. The code for the network request can include a network request manager, a plugin manager, and code segments corresponding to the operation plugins. During the execution of the network request code, the network request manager can sequentially distribute the lifecycle of preset stages 1 to preset stage n of the network request to the plugin manager.

[0054] S220. During the lifecycle operation, the corresponding operation plugin is called through the plugin manager and the first timestamp is recorded, and the return of the operation plugin call is received and the second timestamp is recorded.

[0055] See you again Figure 3 When the plugin manager receives the lifecycle of each preset stage distributed by the network request manager, it can call the corresponding operation plugins according to the plugin execution order to perform the corresponding business operations through the operation plugins. Figure 3 In this context, the operation plugins can include operation plugin 1 to operation plugin m, and the operation plugins called in different preset stages of the lifecycle and the order in which the operation plugins are called can be different.

[0056] Figure 3 In this process, each operation plugin can return a call response to the plugin manager upon completion. The plugin manager records the first timestamp of each operation plugin's call and the second timestamp of each operation plugin's return response. Furthermore, upon completion of each lifecycle phase, the plugin manager can also return a completion message to the network manager, enabling the network request manager to distribute the next preset phase of the lifecycle.

[0057] S230. Using the plugin manager, determine the duration of network requests in a preset dimension based on the first and second timestamps.

[0058] If the lifecycles of preset phases 1 through n are all completed, the network request duration in preset dimensions can be determined through the plugin manager based on the first and second timestamps of each operation plugin. For example, the plugin manager can be used to calculate the lifecycle duration of each preset phase; similarly, the plugin manager can be used to calculate the lifecycle duration of each operation plugin.

[0059] See you again Figure 3 The lifecycle of preset phases 1 through n may include the lifecycle of the request phase. Preset phases preceding the request phase can be considered pre-request phases, and preset phases following the request phase can be considered post-request phases. During the lifecycle of the request phase, the network request manager can make data requests to the server, and the plugin manager can perform business operations without calling operation plugins. Correspondingly, the plugin manager can determine the duration of the request phase's lifecycle based on the difference between the second timestamp of the last operation plugin called in the preset phase preceding the request phase and the first timestamp of the first operation plugin called in the preset phase following the request phase.

[0060] Figure 3 In the process, once the lifecycle of the last preset stage is completed, the network request can be considered complete. At this point, the client can render and display the preset function page based on the data obtained from the request.

[0061] In addition, the network request manager can also send a timeout message to the server in response to the consumption time of a preset dimension exceeding a preset threshold; and / or, the network request manager can send the consumption time of a preset dimension to the server so that the server can display the interface according to the consumption time.

[0062] In some alternative implementations, the code construction process for network requests may include: configuring the network request manager for a preset stage of its lifecycle in response to configuration instructions; and registering the operation plugin to the corresponding preset stage of its lifecycle in response to registration instructions.

[0063] In the engineering architecture of network request code, the code segments corresponding to the network request manager and plugin manager can be pre-built. Furthermore, during the construction process of different network request codes, the lifecycle of the network request manager can be configured with preset stages as needed. Specifically, several preset lifecycle stages of the network request manager can be configured according to configuration instructions.

[0064] For example, in some implementations, the entire network request process can be divided into the following eight preset lifecycle stages: pre-return stage before network request, pre-return stage before network request, parameter concatenation stage before network request, request stage, pre-return stage after network request, data processing stage after network request, and non-data processing stage after network request. The preset stage before the request stage can be considered part of the pre-return stage, and the preset stage after the request stage can be considered part of the post-return stage.

[0065] The network request pre-return phase can be understood as a probing phase before making the network request, laying the groundwork for subsequent processes. For example, in this phase, operations such as returning network status information can be performed. The network request pre-phase can be understood as a phase of preparatory operations before making the network request. For example, in the case of a data request for a content aggregation page, operations such as inserting cached data into the page can be performed in the network request pre-phase. The network request parameter concatenation phase can be understood as a phase of combining parameters before making the network request. For example, in the case of a data request for a content aggregation page, operations such as concatenating parameters corresponding to the pinned content can be performed in the network request parameter concatenation phase. The request phase can be understood as a phase of interactive operations with the server requesting data. The network request post-return phase can be understood as a phase of initial feedback information after making the network request. For example, in the early return phase after a network request, operations such as checking if the system is in "teenager mode" can be performed. If it is in "teenager mode," corresponding related operations can be performed, such as discarding the request. The data processing phase after a network request can be understood as the phase where processing operations related to the data obtained from the request are performed. For example, if the network request is for a content aggregation page, operations such as clearing some data (e.g., blocked data) from the obtained data can be performed in the data processing phase after the network request. The non-data processing phase after a network request can be understood as the phase where business operations are performed after the network request. For example, if the network request is for a content aggregation page, business operations such as counting the number of displayed content can be performed in the non-data processing phase after the network request to facilitate other business operations.

[0066] The network request manager, configured with preset lifecycle stages, can be applied to code building for different network requests. Furthermore, when building code for different networks, business operation code can be registered as a plugin to the corresponding preset lifecycle stage based on registration instructions.

[0067] Among these optional implementations, the engineering architecture of the network request code can possess high flexibility and low coupling. High flexibility is reflected in the ability to break down the entire lifecycle of a network request into several pre-defined lifecycle stages based on different business scenario requirements. Low coupling is reflected in the ability to implement network request logic for different business scenarios through a simple method of registering at the pre-defined lifecycle stages. This engineering architecture not only enables sliced ​​measurement of network request duration under different business scenarios but also effectively reduces the risk of network request crashes due to business coupling, enhancing network request stability.

[0068] In some further implementations, the code iteration process for network requests may include updating the registered operation plugins in response to update instructions.

[0069] In related technologies, there is no unified code engineering architecture in the construction of network request code. This leads to high degradation of network request duration measurement schemes. Assuming there is a unified standard and accurate solution for measuring network request duration, the accuracy of the measurement scheme will still be affected by the iterative updates of the network request code and changes in business operations.

[0070] In these further implementations disclosed herein, the network manager and plugin manager can remain unchanged during the iteration of the network request code within the project architecture. Only update operations such as modification, deletion, and addition of new plugins according to update instructions are required to achieve rapid iterative updates of the network request code. This measurement method effectively avoids measurement degradation and maintains high accuracy and fine-grained time-length metrics.

[0071] In some optional implementations, the network request manager and plugin manager are built based on binary code. Binary code can be understood as code that has been simplified from source code into binary form. In these optional implementations, by converting the code segments of the network request manager and plugin manager into binary code, changes to the execution logic of the network request manager and plugin manager can be effectively prevented during iterative updates of the network request code. This allows the iterative process of the network request code to follow the engineering framework, enabling operations such as adding, deleting, and modifying plugins. It also effectively avoids metric degradation, maintaining high accuracy and fine-grained time-length metrics at all times.

[0072] The technical solution of this disclosure provides an engineering architecture for network request code. A network manager within the engineering architecture can dispatch lifecycles of different preset stages, and a plugin manager within the engineering architecture can call different operation plugins within the lifecycles of different preset stages, thereby enabling sliced ​​measurement of network request duration under different business scenarios. The method for determining network request duration provided in this disclosure belongs to the same disclosed concept as the method for determining network request duration provided in the above embodiments. Technical details not described in detail in this embodiment can be found in the above embodiments, and the same technical features have the same beneficial effects in this embodiment and the above embodiments.

[0073] Figure 4 This is a schematic diagram of a network request duration determination device provided in an embodiment of this disclosure. The network request duration determination device provided in this embodiment is applicable to situations where the duration of a network request needs to be determined.

[0074] like Figure 4As shown, the network request duration determination device provided in this embodiment may include:

[0075] The execution module 410 is used to respond to the triggering of a network request and sequentially execute the lifecycle of the preset stages in the network request;

[0076] The timestamp recording module 420 is used to call the corresponding operation plugin and record the first timestamp during the lifecycle operation process, and to receive the call return of the operation plugin and record the second timestamp.

[0077] The duration determination module 430 is used to determine the duration of network requests in a preset dimension based on the first timestamp and the second timestamp.

[0078] In some alternative implementations, the running module can be used for:

[0079] The network request manager sequentially distributes the lifecycle of the preset stages in the network request to the plugin manager, so that the plugin manager can call the operation plugin corresponding to the lifecycle and receive the call return of the operation gap.

[0080] In some alternative implementations, the device for determining the duration of a network request may further include:

[0081] The code building module is used to construct the code for network requests based on the following process:

[0082] In response to configuration instructions, configure the lifecycle of the network request manager for preset phases;

[0083] In response to the registration command, the operation plugin is registered to the corresponding preset stage of the lifecycle.

[0084] In some alternative implementations, the device for determining the duration of a network request may further include:

[0085] The code iteration module is used to iterate over the code for network requests based on the following process:

[0086] In response to the update command, the registered operation plugins are updated.

[0087] In some alternative implementations, the network request manager and plugin manager are built based on binary code.

[0088] In some optional implementations, the preset dimensions include preset stage dimensions and / or operation plugin dimensions;

[0089] The device for determining the duration of a network request may further include:

[0090] The sending module, after determining the duration of the network request in a preset dimension, performs at least one of the following:

[0091] If the consumption time of a preset dimension exceeds a preset threshold, a timeout message is sent to the server.

[0092] Send the consumption time of the preset dimensions to the server so that the server can display the interface based on the consumption time.

[0093] In some alternative implementations, the default phases include the pre-request phase, the request phase, and the post-request phase.

[0094] The network request duration determination apparatus provided in this disclosure can execute the network request duration determination method provided in any embodiment of this disclosure, and has the corresponding functional modules and beneficial effects of the method execution.

[0095] It is worth noting that the various units and modules included in the above-mentioned device are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be realized; in addition, the specific names of each functional unit are only for easy differentiation and are not used to limit the protection scope of the embodiments of this disclosure.

[0096] The following is for reference. Figure 5 It illustrates an electronic device suitable for implementing embodiments of the present disclosure (e.g., Figure 5 The diagram below shows the structure of the terminal device or server 500. The terminal device in this embodiment may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), and vehicle terminals (e.g., vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 5 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0097] like Figure 5 As shown, the electronic device 500 may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 501, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 502 or a program loaded from storage device 508 into random access memory (RAM) 503. The RAM 503 also stores various programs and data required for the operation of the electronic device 500. The processing unit 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0098] Typically, the following devices can be connected to I / O interface 505: input devices 506 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 507 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 508 including, for example, magnetic tapes, hard disks, etc.; and communication devices 509. Communication device 509 allows electronic device 500 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 5 An electronic device 500 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0099] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 509, or installed from a storage device 508, or installed from a ROM 502. When the computer program is executed by the processing device 501, it performs the functions defined in the method for determining the network request duration of embodiments of this disclosure.

[0100] The electronic device provided in this embodiment and the method for determining the network request duration provided in the above embodiments belong to the same disclosed concept. Technical details not described in detail in this embodiment can be found in the above embodiments, and this embodiment has the same beneficial effects as the above embodiments.

[0101] This disclosure provides a storage medium for computer-executable instructions, which, when executed by a computer processor, can be used to perform the method for determining the duration of a network request provided in the above embodiments.

[0102] It should be noted that the storage medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM) or flash memory (FLASH), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium that contains or stores executable instructions that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable executable instructions. Such transmitted data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit executable instructions for use by or in connection with an instruction execution system, apparatus, or device. Executable instructions contained on the storage medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0103] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and end-to-end networks (e.g., ad hoc end-to-end networks), as well as any currently known or future-developed networks.

[0104] The aforementioned storage medium may be included in the aforementioned electronic device; or it may exist independently and not be assembled into the electronic device.

[0105] The aforementioned storage medium carries one or more executable instructions, which, when executed by the electronic device, cause the electronic device to:

[0106] In response to a network request, the lifecycle of the network request is executed sequentially through preset stages. During the lifecycle execution, the corresponding operation plugin is invoked and the first timestamp is recorded, and the return of the operation plugin is received and the second timestamp is recorded. Based on the first and second timestamps, the duration of the network request in the preset dimension is determined.

[0107] Executable instructions for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including but not limited to object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The executable instructions can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0108] This disclosure also provides a computer program product, including a computer program that, when executed by a processor, can implement the method for determining the duration of a network request as provided in any embodiment of this disclosure.

[0109] In implementing a computer program product, computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0110] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0111] The units described in the embodiments of this disclosure can be implemented in software or hardware. The names of the units and modules do not, in certain circumstances, constitute a limitation on the unit or module itself.

[0112] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Array (FPGA), Application Specific Integrated Circuit (ASIC), Application Specific Standard Parts (ASSP), System on Chip (SOC), Complex Programmable Logic Device (CPLD), and so on.

[0113] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0114] According to one or more embodiments of this disclosure, a method for determining the duration of a network request is provided, the method comprising:

[0115] In response to a network request, the lifecycle of the preset stages in the network request is executed sequentially.

[0116] During the lifecycle operation, the corresponding operation plugin is invoked and a first timestamp is recorded, and the return value of the operation plugin is received and a second timestamp is recorded.

[0117] Based on the first timestamp and the second timestamp, the duration of the network request in the preset dimension is determined.

[0118] According to one or more embodiments of this disclosure, a method for determining the duration of a network request is provided, further comprising:

[0119] In some optional implementations, the lifecycle of a preset phase in the network request is executed sequentially, including:

[0120] The network request manager sequentially distributes the lifecycle of the preset stage in the network request to the plugin manager, so that the plugin manager can call the operation plugin corresponding to the lifecycle and receive the call return of the operation gap.

[0121] According to one or more embodiments of this disclosure, a method for determining the duration of a network request is provided, further comprising:

[0122] In some alternative implementations, the code construction process for the network request includes:

[0123] In response to configuration instructions, the network request manager is configured with the lifecycle of the preset phase;

[0124] In response to the registration instruction, the operation plugin is registered to the lifecycle corresponding to the preset stage.

[0125] According to one or more embodiments of this disclosure, a method for determining the duration of a network request is provided, further comprising:

[0126] In some alternative implementations, the code iteration process for the network request includes:

[0127] In response to the update command, the registered operation plugins are updated.

[0128] According to one or more embodiments of this disclosure, a method for determining the duration of a network request is provided, further comprising:

[0129] In some alternative implementations, the network request manager and the plugin manager are built based on binary code.

[0130] According to one or more embodiments of this disclosure, a method for determining the duration of a network request is provided, further comprising:

[0131] In some optional implementations, the preset dimension includes the preset stage dimension and / or the operation plugin dimension;

[0132] After determining the duration of the network request in the preset dimension, the method further includes at least one of the following:

[0133] If the consumption time of the preset dimension exceeds a preset threshold, a timeout message is sent to the server.

[0134] The time consumed in the preset dimension is sent to the server so that the server can display the interface based on the time consumed.

[0135] According to one or more embodiments of this disclosure, a method for determining the duration of a network request is provided, further comprising:

[0136] In some optional implementations, the preset phase includes a pre-request phase, a request phase, and a post-request phase.

[0137] According to one or more embodiments of this disclosure, a network request duration determination apparatus is provided, the apparatus comprising:

[0138] The execution module is used to respond to the triggering of a network request and sequentially execute the lifecycle of the preset stages in the network request;

[0139] The timestamp recording module is used to call the corresponding operation plugin and record the first timestamp during the lifecycle operation, and to receive the call return of the operation plugin and record the second timestamp.

[0140] The duration determination module is used to determine the duration of the network request in a preset dimension based on the first timestamp and the second timestamp.

[0141] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features disclosed in this disclosure that have similar functions.

[0142] Furthermore, while the operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0143] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.

Claims

1. A method for determining the duration of a network request, characterized in that, include: In response to a network request, the lifecycle of the preset stages in the network request is executed sequentially. During the lifecycle operation, the corresponding operation plugin is invoked and a first timestamp is recorded, and the return value of the operation plugin is received and a second timestamp is recorded. Based on the first timestamp and the second timestamp, the duration of the network request in the preset dimension is determined.

2. The method according to claim 1, characterized in that, The lifecycle of the network request is executed sequentially through preset stages, including: The network request manager sequentially distributes the lifecycle of the preset stage in the network request to the plugin manager, so that the plugin manager can call the operation plugin corresponding to the lifecycle and receive the call return of the operation gap.

3. The method according to claim 2, characterized in that, The code construction process for the network request includes: In response to configuration instructions, the network request manager is configured with the lifecycle of the preset phase; In response to the registration instruction, the operation plugin is registered to the lifecycle corresponding to the preset stage.

4. The method according to claim 3, characterized in that, The code iteration process for the network request includes: In response to the update command, the registered operation plugins are updated.

5. The method according to claim 2, characterized in that, The network request manager and the plugin manager are built based on binary code.

6. The method according to claim 1, characterized in that, The preset dimension includes the preset stage dimension and / or the operation plugin dimension; After determining the duration of the network request in the preset dimension, the method further includes at least one of the following: If the consumption time of the preset dimension exceeds a preset threshold, a timeout message is sent to the server. The time consumed in the preset dimension is sent to the server so that the server can display the interface based on the time consumed.

7. The method according to any one of claims 1-6, characterized in that, The preset stages include a pre-request stage, a request-in-request stage, and a post-request stage.

8. A device for determining the duration of a network request, characterized in that, include: The execution module is used to respond to the triggering of a network request and sequentially execute the lifecycle of the preset stages in the network request; The timestamp recording module is used to call the corresponding operation plugin and record the first timestamp during the lifecycle operation, and to receive the call return of the operation plugin and record the second timestamp. The duration determination module is used to determine the duration of the network request in a preset dimension based on the first timestamp and the second timestamp.

9. An electronic device, characterized in that, The electronic device includes: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the method for determining the duration of a network request as described in any one of claims 1-7.

10. A storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the method for determining the duration of a network request as described in any one of claims 1-7.

11. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method for determining the duration of a network request as described in any one of claims 1-7.

Images