TWI888940B - Method and apparatus of measuring performance of application - Google Patents

Abstract

One aspect of the present invention can provide an application performance measurement device. The device of one aspect of the present invention may include: a communication circuit that communicates with at least one external device; one or more processors; and one or more memories that store the following commands, which, when executed by the one or more processors, cause the one or more processors to perform operations; the one or more processors are configured as follows: a first metric set of a first type of application is obtained, a second metric set of a second type of application is obtained, and based on information of at least one measurement item included in the first metric set and the second metric set, the respective states of the first type of application and the second type of application are determined; the first metric set and the second metric set each include information of at least one common measurement item.

Description

Device and method for measuring performance of an application

The present invention relates to a technology for providing a method for measuring the performance of an application.

The server that provides services using applications is the main body of the service, receives various data (e.g., measurement data) from the devices of each user using the service, and determines whether the service is being implemented normally based on the received data. That is, the server receives information of one or more measurement items from the devices of each user using the service to evaluate the quality of the service provided to the user. In addition, when a server uses different multiple applications to operate multiple services, the server should receive information of one or more measurement items for each of the multiple services separately, and evaluate the quality of each of the multiple services separately.

However, previously, when a server operated multiple services, the code used to manage the quality of the service was implemented separately for each service, so the code for the same function had to be created repeatedly, and a method for managing metrics data in a unified way across multiple services was needed. In addition, during peak hours when the computing processing load of providing services increased, the technical requirements for adjusting the processing volume of the actions for managing metrics data continued to increase.

[The problem the invention is trying to solve]

According to various embodiments of the present invention, the technical subject is to provide a solution for a user-specified subject.

According to various embodiments of the present invention, the technical problem is to enable users to obtain source code for solving specific problems from other users.

According to various embodiments of the present invention, the technical problem is to enable users to obtain source code for solving specific problems based on various source code languages.

According to various embodiments of the present invention, the technical problem is to enable users to obtain source code for solving specific problems, which include non-public information and require the creation of source code. [Technical means for solving the problem]

One aspect of the present invention may provide an application performance measurement device. The device of one aspect of the present invention may include: a communication circuit that communicates with at least one external device; one or more processors; and one or more memories that store the following commands, which, when executed by the one or more processors, cause the one or more processors to perform operations; the one or more processors are configured as follows: a first metric set of a first type of application is obtained, a second metric set of a second type of application is obtained, and based on information of at least one measurement item included in the first metric set and the second metric set, the respective states of the first type of application and the second type of application are determined; the first metric set and the second metric set each include information of at least one common measurement item.

In one embodiment, the first type of application may be an application that provides a measurement API (Application Programming Interface) that returns information about measurement items, and the second type of application may be an application that does not provide the measurement API.

In one embodiment, the one or more processors may obtain the first set of metrics by receiving a response to a call to the metric API from the first type of application, and may obtain the second set of metrics by receiving metric data from the second type of application at a predetermined specific time point.

In one embodiment, the first type of application may be a foreground application that performs actions based on user input, and the second type of application may be a background application that performs actions independent of user input.

In one embodiment, the common measurement items may include Internet speed, API call latency, or at least one of the measurement items predetermined for managing specific software.

In one embodiment, the one or more processors may jointly use a pre-created specific function to obtain information of the at least one common measurement item from each of the first type of application and the second type of application.

In one embodiment, the first metric set or the second metric set may include information of measurement items defined by a user.

In one embodiment, the above-mentioned Type 1 application or the above-mentioned Type 2 application may be an application related to e-commerce, and the measurement items defined by the above-mentioned user include at least one of the application action error code, whether the application error causes an order failure, whether the user cancels the order, or the number of orders per minute.

In one embodiment, the one or more processors may utilize a queue list to sequentially process the information of the at least one measurement item.

In one embodiment, the one or more processors may use a predetermined number of threads to process the information of the at least one measurement item.

Another aspect of the present invention may provide an application performance measurement method. The method of one aspect of the present invention is implemented by an electronic device, the electronic device including a communication circuit for communicating with at least one external device, one or more processors, and one or more memories storing at least one command executed by the one or more processors. The method may include the following steps: obtaining a first metric set of a first type of application; obtaining a second metric set of a second type of application; and determining the respective states of the first type of application and the second type of application based on information of at least one measurement item included in the first metric set and the second metric set; the first metric set and the second metric set respectively include information of at least one common measurement item.

In one embodiment, the first type of application may be an application that provides a measurement API (Application Programming Interface) that returns information of measurement items, and the second type of application may be an application that does not provide the measurement API.

In one embodiment, the step of obtaining the above-mentioned first metric set may include the following steps: obtaining the above-mentioned first metric set by receiving a response to the call to the above-mentioned metric API from the above-mentioned first type application, and the step of obtaining the above-mentioned second metric set includes the following steps: obtaining the above-mentioned second metric set by receiving metric data from the above-mentioned second type application at a predetermined specific time point.

In one embodiment, the first type of application may be a foreground application that performs actions based on user input, and the second type of application may be a background application that performs actions independent of user input.

In one embodiment, the common measurement items may include Internet speed, API call latency, or at least one of the measurement items predetermined for managing specific software.

In one embodiment, the method may further include the following step: jointly using a pre-created specific function to obtain information of the at least one common measurement item from each of the first type of application and the second type of application.

In one embodiment, the first metric set or the second metric set may include information of measurement items defined by a user.

In one embodiment, the above-mentioned Type 1 application or the above-mentioned Type 2 application may be an application related to e-commerce, and the measurement items defined by the above-mentioned user include at least one of the application action error code, whether the application error causes an order failure, whether the user cancels the order, or the number of orders per minute.

In one embodiment, the method may further include the following step: using a queue list to sequentially process the information of the at least one measurement item.

According to another aspect of the present invention, a computer-readable recording medium can be disclosed. A non-transitory computer recording medium records a command that causes the one or more processors to perform an action when executed by one or more processors, wherein the command causes the one or more processors to be configured as follows: obtain a first metric set of a first type of application, obtain a second metric set of a second type of application, match the metric name and metric type based on information of at least one measurement item included in the first metric set and the second metric set, thereby generating matching data, and transmitting the matching data to an external device. [Effect of the invention]

According to various embodiments of the present invention, the application generation time can be shortened by improving the reusability of the created code (i.e., the pre-created specific functions).

According to various embodiments of the present invention, information of measurement items that should be measured by multiple applications can be comprehensively managed.

According to various embodiments of the present invention, the computing burden of the server can be reduced.

According to various embodiments of the present invention, flow management of measurement data can be easily implemented.

The various embodiments described in this specification are exemplified for the purpose of clearly explaining the technical concept of the present invention, and are not intended to limit them to specific implementation methods. The technical concept of the present invention includes various modifications, equivalents, alternatives, and embodiments obtained by selectively combining all or part of the embodiments described in the present invention. In addition, the scope of rights of the technical concept of the present invention is not limited to the various embodiments presented below or their specific descriptions.

Unless otherwise defined, the terms used in the present invention, including technical or scientific terms, shall have the meanings commonly understood by those with common knowledge in the technical field to which the present invention belongs.

The expressions such as "include", "may include", "have", "may have", "have", "may have", etc. used in this specification mean the existence of the target features (such as functions, actions or components, etc.) and do not exclude the existence of other additional features. That is, the expressions as described above should be understood as open-ended terms that have the possibility of including other embodiments.

Singular expressions used in this specification may include plural expressions unless otherwise mentioned. The same applies to singular expressions recorded in the patent application.

Unless otherwise mentioned, the expressions "1st", "2nd" or "first", "second" etc. used in this specification are used to distinguish an object from other objects when referring to multiple similar objects, and are not used to limit the order or importance of such objects.

As used in the present invention, expressions such as "A, B and C", "A, B or C", "A, B and/or C", or "at least one of A, B and C", "at least one of A, B or C", "at least one of A, B and/or C", "at least one selected from A, B and C", "at least one selected from A, B or C", "at least one selected from A, B and/or C" may refer to each of the listed items or all possible combinations of the listed items. For example, "at least one selected from A and B" may refer to (1) A, (2) at least one of A, (3) B, (4) at least one of B, (5) at least one of A and at least one of B, (6) at least one of A and B, (7) at least one of B and A, and (8) both A and B.

The expression "based on..." used in the present invention is used to describe one or more factors that affect the behavior or action of determination or judgment described in the sentence or article containing the expression. The expression does not exclude other factors that affect the behavior or action of determination or judgment.

When used in this specification, the expression that a certain constituent element (for example, the first constituent element) is “connected” or “linked” to another constituent element (for example, the second constituent element) may refer not only to the direct connection or linking of the aforementioned certain constituent element to the aforementioned other constituent element, but also to the connection or linking via another new constituent element (for example, the third constituent element).

The expression "configured to" used in the present invention may have the meanings of "set in a manner of", "having the ability of", "changed in a manner of", "made in a manner of", "capable of performing", etc., depending on the context. The expression is not limited to the meaning of "specially designed in hardware". For example, a processor configured to perform a specific action may refer to a generic purpose processor that can perform a specific action by executing software.

Hereinafter, the various embodiments described in the present invention are described with reference to the attached drawings. In the attached drawings and the attached drawings description, the same reference symbols are given to the same or substantially equivalent components. In the description of the following embodiments, the repeated description of the same or corresponding components may be omitted, but this does not mean that the components are not included in the embodiments.

FIG. 1 schematically shows an example of an electronic device 10 processing metric data 23 obtained from one or more applications 21, 22 installed on a user terminal according to an embodiment of the present invention. In the present invention, metric data can be used as a general term for the following values, that is, the value of at least one metric item representing the performance or status of a service, software, program, or application provided to a user. The metric item can be, for example, whether the Internet is connected, the network speed, etc.

The electronic device 10 may be a user terminal equipped with an application. In addition, the electronic device 10 may also be a server outside the user terminal. In the following, in some embodiments in this specification, the electronic device 10 is assumed to be a server to explain the application performance measurement method, but this is only an assumption for the convenience of explanation and does not limit the present invention. The application performance measurement method disclosed in this specification can also be implemented in a user terminal equipped with an application.

The electronic device 10 can receive measurement data 23 from the first type application 21 and the second type application 22, respectively, and process the received measurement data 23 by a prescribed method, thereby determining the respective states of the first type application 21 and the second type application 22. The first type application 21 may refer to an application of the type that provides a measurement API (Application Programming Interface). The first type application 21 may be referred to as a "long-term running application." Unlike the first type application, the second type application 22 may be an application that does not provide an API that responds to measurement data transmission requests from the outside. The second type application 22 may be referred to as a "batch job application."

The electronic device 10 can process the metric data 23 by using a queue list 11 or a thread pool 13 including a predetermined number of threads. This will be described in detail below.

FIG2 is a diagram showing a system including a server 100, a user terminal 200 and a communication network 300 according to an embodiment of the present invention. The server 100 and the user terminal 200 can send or receive information to each other through the communication network 300 according to the application performance measurement technology disclosed in this specification.

The server 100 may be an electronic device of a service provider using an application. The service provider may be an operator of a service using the application disclosed in this specification. The server 100 is an electronic device that transmits information or provides services to a user terminal 200 connected by wire or wireless, and may be, for example, an application server, a proxy server, or a cloud server.

The user terminal 200 may refer to one or more user terminals or a collection of two or more user terminals. In various embodiments disclosed in this specification, when the user terminal 200 refers to a collection of two or more user terminals, each user terminal may be referred to as the first user terminal 200-1, the second user terminal 200-2, ..., the nth user terminal 200-n (n is a natural number greater than 2).

The user terminal 200 may be a terminal of a user who uses the service provided by the server 100 through an application. The user terminal 200 may be, for example, at least one of a smart phone, a tablet computer, a PC (Personal Computer), a mobile phone, a PDA (Personal Digital Assistant), an audio player, and a wearable device.

In the disclosure of this specification, when describing the configuration or operation of a device, the term "device" may be used as a term to refer to the device as the object of description, and the term "external device" may be used as a term to refer to an external device from the perspective of the device as the object of description. For example, when the server 100 is described as a "device", from the perspective of the server 100, the user terminal 200 may be called an "external device". Also, for example, when the user terminal 200 is described as a "device", from the perspective of the user terminal 200, the server 100 may be called an "external device". That is, the server 100 and the user terminal 200 may be referred to as a "device" and an "external device", or may be referred to as an "external device" and a "device", respectively, according to the perspective of the subject of the action.

The communication network 300 may include a wired or wireless communication network. The communication network 300 may allow data to be exchanged between the server 100 and the user terminal 200. For example, the wired communication network may include a communication network such as USB (Universal Serial Bus), HDMI (High Definition Multimedia Interface), RS-232 (Recommended Standard-232) or POTS (Plain Old Telephone Service). Wireless communication networks may include, for example, eMBB (enhanced Mobile Broadband), URLLC (Ultra Reliable Low-Latency Communications), MMTC (Massive Machine Type Communications), LTE (Long-Term Evolution), LTE-A (LTE Advance), NR (New Radio), UMTS (Universal Mobile Telecommunications System), GSM (Global System for Mobile communications), CDMA (Code Division Multiple Access), WCDMA (Wideband CDMA), WiBro (Wireless Broadband), WiFi (Wireless Fidelity), Bluetooth, NFC (Near Field Communication), GPS (Global Positioning System), etc. The communication network 300 of the present specification is not limited to the above examples, but may include various types of communication networks that allow data to be exchanged between multiple subjects or devices without limitation.

FIG3 is a block diagram of a server 100 of one embodiment of the content disclosed in this specification. The server 100 may include one or more processors 110, communication circuits 120, or memory 130 as components. In a certain embodiment, at least one of the components of the server 100 may be omitted, or other components may be added to the server 100. In a certain embodiment, a portion of the components may be integrated additionally or alternatively to be implemented, or may be implemented as a single or multiple entities. At least some of the components inside or outside the server 100 can be connected to each other via a bus, GPIO (General Purpose Input/Output), SPI (Serial Peripheral Interface) or MIPI (Mobile Industry Processor Interface) to send and receive data or signals.

One or more processors 110 may be referred to as processor 110. Unless otherwise specified, the term processor 110 may refer to a collection of one or more processors. Processor 110 may drive software (e.g., commands, programs, etc.) to control at least one component of server 100 connected to processor 110. Processor 110 may perform various operations such as calculations, processing, data generation or processing, etc. Processor 110 may load data from memory 130 or store it in memory 130.

The communication circuit 120 can implement wireless or wired communication between the server 100 and other devices (e.g., the user terminal 200 or other servers). For example, the communication circuit 120 can implement wireless communication in the form of eMBB, URLLC, MMTC, LTE, LTE-A, NR, UMTS, GSM, CDMA, WCDMA, WiBro, WiFi, Bluetooth, NFC, GPS, or GNSS. Also, for example, the communication circuit 120 can implement wired communication in the form of USB (Universal Serial Bus), HDMI (High Definition Multimedia Interface), RS-232 (Recommended Standard-232), or POTS (Plain Old Telephone Service).

The memory 130 can store various data. The data stored in the memory 130 is data obtained, processed or used by at least one component of the server 100, and may include software (e.g., commands, programs, etc.). The memory 130 may include volatile or non-volatile memory. If not explicitly stated differently in the text, the term memory 130 may refer to a collection of one or more memories. The expression "a set of instructions stored in the memory 130" or "a program stored in the memory 130" mentioned in this specification may be used to refer to an operating system, application software or middleware used to control the resources of the server 100. The middleware provides various functions to the application software so that the application software can use the resources of the server 100. In one embodiment, when the processor 110 executes a specific operation, the memory 130 may store the instructions executed by the processor 110 and corresponding to the specific operation.

In one embodiment, the server 100 may transmit the data of the calculation result of the processor 110, the data received by the communication circuit 120, or the data stored in the memory 130 to the external device. The external device may be a device for outputting (displaying or indicating) the received data. The external device may be, for example, the user terminal 200.

FIG4 is a block diagram of a user terminal 200 of an embodiment of the content disclosed in this specification. The user terminal 200 may include one or more processors 210, communication circuits 220 or memory 230 as components. In addition, the user terminal 200 may further include at least one of an input unit 240 or an output unit 250.

The processor 210 can drive software (e.g., commands, programs, etc.) to control at least one component of the user terminal 200 connected to the processor 110. In addition, the processor 210 can perform various operations such as calculations, processing, data generation or processing, etc. In addition, the processor 210 can load data from the memory 230 or store it in the memory 230.

The communication circuit 220 can implement wireless or wired communication between the user terminal 200 and other devices (e.g., the server 100 or other user terminals). For example, the communication circuit 220 can implement wireless communication in the form of eMBB, URLLC, MMTC, LTE, LTE-A, NR, UMTS, GSM, CDMA, WCDMA, WiBro, WiFi, Bluetooth, NFC, GPS, or GNSS. Also, for example, the communication circuit 220 can implement wired communication in the form of USB, HDMI, RS-232, or POTS.

The memory 230 can store various data. The data stored in the memory 230 is data obtained, processed or used by at least one component of the user terminal 200, and may include software (e.g., commands, programs, etc.). The memory 230 may include volatile or non-volatile memory. If not explicitly stated differently in the text, the term memory 230 may refer to a collection of one or more memories. The expression "a set of instructions stored in the memory 230" or "a program stored in the memory 230" mentioned in this specification may be used to refer to an operating system, application software or middleware used to control the resources of the user terminal 200. The middleware provides various functions to the application software so that the application software can use the resources of the user terminal 200. In one embodiment, when the processor 210 executes a specific operation, the memory 230 may store the instructions executed by the processor 210 and corresponding to the specific operation.

In one embodiment, the user terminal 200 may further include an input unit 240. The input unit 240 may be a component that sends data received from the outside to at least one component included in the user terminal 200. For example, the input unit 240 may include a mouse, a keyboard, or a touch panel.

In one embodiment, the user terminal 200 may further include an output unit 250. The output unit 250 may display (output) information processed in the user terminal 200 or transmit (send) it to the outside. For example, the output unit 250 may visually display information processed in the user terminal 200. The output unit 250 may display UI (User Interface) information or GUI (Graphic User Interface) information, etc. In this case, the output unit 250 may include at least one of a liquid crystal display (LCD), a thin film transistor-liquid crystal display (TFT-LCD), an organic light-emitting diode (OLED), a flexible display, a three-dimensional display (3D Display), and an electronic ink display (E-ink Display). In addition, for example, the output unit 250 may audibly display information processed in the user terminal 200. The output unit 250 may display audio data in any audio file format (e.g., MP3, FLAC, WAV, etc.) through an audio device. In this case, the output unit 250 may include at least one of a speaker, a headphone, and an earphone.

FIG. 5 is a sequence diagram of actions of the server 100 to measure the performance of a plurality of applications according to an embodiment of the present invention.

The server 100 may obtain a first metric set of a first type of application (S510).

In the disclosure of this specification, "Type 1 application" may refer to an application of the type that provides a measurement API (Application Programming Interface). Here, "measurement API" may refer to an API that returns information about a measurement item. Type 1 application may provide an API for responding to a GET request for at least one measurement item (e.g., Internet speed, API call latency, etc.). Type 1 application may be a foreground application that performs actions based on user input. Specifically, Type 1 application may be an application of the type that interacts with a user through the output unit 250 of the user terminal 200, etc., and sends and receives data with the server 100. The first type of application may be an application that provides various APIs that can be called externally, including the above-mentioned measurement API, so as to perform operations as a foreground application.

In the disclosure of this specification, a "measurement set" is a set of measurement data (or measurement index data), which may refer to a set including at least one measurement item. A measurement set may include at least one measurement item and the value of each measurement item. In the following, for the convenience of explanation, a pair of measurement items and the value of the corresponding item may be referred to as "information of the measurement item".

The first metric set may be a metric set that includes information about at least one measurement item related to the first type of application. For example, the server 100 may obtain the first metric set by receiving a response to a call to a metric API from a specific application corresponding to the first type of application (hereinafter, also referred to as the "A" application). The first metric set may include information about at least one measurement item (for example, information about Internet speed, information about API call latency, etc.). Specifically, the processor 110 may call a metric API (for example, a GET request) that returns the speed of the currently connected Internet in the API provided by the "A" application set in the user terminal 200, and receive the value of the Internet speed from the "A" application in response thereto. In addition, the processor 110 may call an API provided by the "A" application set in the user terminal 200 to return a call latency measurement API for a specific API for the application to provide services (for example, in the case of an application providing application e-commerce services, it is an API for obtaining current delivery information from an external delivery company, etc.), and in response, receive the API call latency value from the "A" application.

The server 100 may obtain a second metric set of the second type of application (S520).

In the disclosure of this specification, "Type 2 application" may refer to an application of a type that does not provide a measurement API. For example, unlike Type 1 application, Type 2 application may be an application that does not provide an API that responds to external measurement data transmission requests. Type 2 application may be a background application that performs actions independent of user input. Specifically, Type 2 application may be an application that is set in user terminal 200 and collects specific data of user terminal 200 according to the permissions allowed by the user. Type 2 application is a background application and may be an application of a type that does not provide a measurement API. The second type of application may be an application that transmits measurement data to an external device (e.g., server 100, etc.) when a predetermined specific event (e.g., an error occurs) or a specified period has passed. That is, the second type of application is an application that does not provide a measurement API that can be freely called from the outside, and may be an application that transmits the calculated measurement data to an external device only at a specific time point defined by the application.

The second metric set may be a metric set including information of at least one measurement item related to the second type of application. For example, the server 100 may obtain the second metric set by receiving metric data from a specific application corresponding to the second type of application (hereinafter, also referred to as the "B" application) at a predetermined specific time point. The predetermined specific time point may be set as a default value when the "B" application is generated or downloaded to the user terminal 200. The second metric set may include information of at least one measurement item (for example, information of Internet speed, information of API call delay time, etc.). Specifically, the processor 110 may receive the value of Internet speed from the "B" application set in the user terminal 200 at a predetermined specific time point. Furthermore, the processor 110 may receive the value of the API call delay time from the "B" application set in the user terminal 200 at a predetermined specific time point.

The first metric set and the second metric set disclosed in this specification may each include information of at least one common measurement item. For example, the common measurement item may include Internet speed, API call latency, or at least one of the measurement items predetermined for managing specific software. At this time, as an example of a measurement item predetermined for managing specific software, when both the first type of application and the second type of application use the so-called "Kafka" data processing platform, the first metric set and the second metric set may include one or more indicators for monitoring the current status of Kafka (for example, the amount of unprocessed data, the amount of data processed per unit time, etc.) as a common measurement item. Furthermore, as another example of a measurement item predetermined for managing specific software, when both the first type application and the second type application use a database called "Redis", the first metric set and the second metric set may include one or more indicators for monitoring the current state of Redis (e.g., database capacity, etc.) as common measurement items. Furthermore, as another example of a measurement item predetermined for managing specific software, when both the first type application and the second type application use a database management program called "HikariCP", the first metric set and the second metric set may include one or more indicators for monitoring the current state of HikariCP (e.g., performance of the connection pool, etc.) as common measurement items.

In one embodiment of the present invention, the server 100 can use a pre-created specific function in common to obtain information of at least one common measurement item from each of the first type of application and the second type of application. Here, the pre-created specific function is a collection of source code, which can refer to functions that can be commonly applied to the first type of application or the second type of application. For example, a specific function for obtaining Internet speed can be pre-generated by receiving an application identification number, a user terminal identification number, etc. as input parameters. At this time, the server 100 can use the specific function for obtaining Internet speed in common by changing the input parameters, and obtain information of Internet speed from each of the first type of application and the second type of application. Thus, the application generation time can be shortened by improving the reusability of the created code (i.e., the pre-created specific function). Furthermore, according to the present invention, even for different types of applications such as the first type application and the second type application, information on measurement items that should be measured in common by multiple applications can be managed in an integrated manner by using the pre-created specific function for each application.

The first metric set or the second metric set disclosed in this specification may include information of measurement items defined by the user. For example, when the first type of application and/or the second type of application is an application related to e-commerce, the first metric set or the second metric set may include at least one of the application action error code, whether the application error causes an order failure, whether the user cancels the order, and the number of orders per minute. The application action error code may, for example, refer to the corresponding error code (e.g., 401, 404, etc.) when an error occurs when the application performs a specific action. Whether an application error causes an order failure may, for example, refer to a measurement item value that has a value of "1" when a user's order fails due to an application action error, and is otherwise assigned a value of "0". Whether a user cancels an order may, for example, refer to a measurement item value that has a value of "1" when the user directly cancels the order, and is otherwise assigned a value of "0".

The server 100 may determine the status of the first type of application and the second type of application based on the information of at least one measurement item included in the first measurement set and the second measurement set (S530). For example, the server 100 may determine whether the application is operating normally based on the information of the Internet speed of each application, the API call delay time information, etc. Specifically, if the information of a specific measurement item among the information of each measurement item included in the measurement set is abnormal, the processor 110 may generate information that the application has an error and notify the user of the server 100.

In one embodiment of the present invention, the server 100 may process the information of at least one measurement item included in the first measurement set and the second measurement set in sequence using a queue list. The processor 110 may input the information of the measurement items included in each measurement set into the queue list according to the time when the first measurement set or the second measurement set is received. For example, the processor 110 may input the information of the measurement items included in the measurement set received first into the queue list with priority. In addition, the processor 110 may input the information of the measurement items included in the measurement set into the queue list according to the priority of each application. For example, when the priority of the first type of application is set higher than that of the second type of application, the processor 110 receives both the first metric set of the first type of application and the second metric set of the second type of application. Even if the second metric set is received first, if the second metric set has not been input into the queue list, the first metric set may be input into the queue list with priority. The processor 110 may sequentially extract and process the information of the measurement items from the queue list. That is, the processor 110 may process the information of at least one measurement item received from different applications in a first-in-first-out manner. In the present invention, the size of the queue list may be variably determined according to the number of applications managed by the server 100 or the performance of the server 100.

The processor 110 may use a predetermined number of threads to process the information of at least one measurement item. The predetermined number of threads for processing the information of the measurement items may be set to an appropriate number in consideration of the number of main threads for managing services. For example, the predetermined number of threads for processing the information of the measurement items may be variably determined in consideration of the current time, service conditions, the amount of computing power of the server 100, etc. The processor 110 processes the information of the measurement items in sequence according to the queue list. When there are currently available threads, the processor 110 may process the measurement data by deriving the information of the measurement items from the queue list and assigning it to the available threads.

As described above, according to an embodiment of the present invention that uses a queue list to process information of at least one measurement item, even if information of measurement items is received from multiple applications in a specific time period, the information can be processed in sequence while using the queue list to adjust the flow, thereby reducing the computational burden of the server 100. In addition, since the present invention uses a queue list and a predetermined number of threads to process measurement data, the measurement data management operation of the server 100 can be efficiently implemented without compromising the performance of basic service operations.

The following describes an additional embodiment, which is an embodiment in which the electronic device 10 for implementing the application performance measurement method of the present invention as described above with reference to FIG. 1 is a user terminal 200. In addition, the contents that overlap with the contents described above in the case where the electronic device 10 is a server 100 are omitted, and the differences are mainly described.

When the application performance measurement method of the present invention is implemented in the user terminal 200, the user terminal 200 can classify the metric data received from each application and send the classification results of each metric data to the server 100. That is, when the user terminal 200 implements the application performance measurement method, S510 and S520 in each step of FIG. 5 can be implemented by the user terminal 200 as described above. In addition, the processor 210 can send the information of the measurement items included in each metric set to the server 100 in a prescribed manner. Specifically, the processor 210 may process the first and second metric sets received from each of the first and second type applications by at least one thread managed by the processor 210 and then send them to the server 100. The thread used by the processor 210 to process the metric data may be a thread different from the thread used to drive the first or second type applications. The number of threads used to process the metric data may be variably determined according to the situation or performance of the user terminal 200 driving each application.

The processor 210 can match the metric name and metric type of the received measurement item information, and transmit the matching data to the server 100. The server 100 can reduce the computational burden by receiving the matching data corresponding to the classification result of the metric data from the processor 210. The metric name can be the name of the above-mentioned pre-created specific function, and can be predetermined according to the measurement item as the measurement object. For example, the metric name can be predetermined as "order_succeed_metric", "status_true_metric", "status_false_metric", etc. In addition, the metric type is a value used to classify multiple measurement items, which can be predetermined according to the metric name and stored in the memory 230. The processor 210 can determine the metric type that matches the metric name by referring to the memory 230 and generate matching data. When the metric types are different between the measurement items, the corresponding measurement items can be displayed to the administrator in visually different ways or sent to the administrator at different times. In addition, when the metric types are the same between the measurement items, the corresponding measurement items can be displayed to the administrator in visually the same way or sent to the administrator at the same time. As an example, the metric data can be visually displayed by a display (e.g., a dashboard) of the server 100. Metric types can include, for example, Counter, Gauge, Summary, Histogram, etc.

As described above, when the application performance measurement method of the present invention is implemented in the user terminal 200, the user terminal 200 can independently process the measurement data representing the performance of each application while driving each application. In this way, the computing burden on the server 100 side can be reduced. In addition, in order not to affect the performance or quality of the basic service provided by the application (for example, the ordering function of e-commerce), the user terminal 200 can be allocated a separate thread to process the measurement data asynchronously, thereby having the effect of facilitating the management of the flow of the measurement data.

The method of the present invention may be a method implemented by a computer. In the present invention, each step of the method is represented and described in a prescribed order, but each step may be implemented in a sequence or in any order combined by the present invention. In one embodiment, at least a part of the steps may be implemented in parallel, repeatedly or heuristically. The present invention does not exclude changes or modifications to the method. In one embodiment, at least a part of the steps may be omitted or other steps may be added.

Various embodiments of the present invention may be implemented in the form of software recorded in a machine-readable recording medium. The software may be software used to implement the various embodiments of the present invention described above. The software may be inferred by a programmer in the technical field to which the present invention belongs based on the various embodiments of the present invention. For example, the software may be a machine-readable command (e.g., code or code segment) or a program. A machine is a device that can perform actions based on commands called from a recording medium, such as a computer. In one embodiment, the machine may be an electronic device 10, a server 100, or a user terminal 200 of an embodiment of the present invention. In one embodiment, the processor of the machine can execute the called command, so that the components of the machine perform the function corresponding to the command. The recording medium can refer to all kinds of recording media (recording medium) that store data read by the machine. The recording medium may include, for example, ROM (Read only memory), RAM (Random-access memory), CD-ROM (Compact Disc Read-Only Memory), magnetic tape, floppy disk, optical data storage device, etc. In one embodiment, the recording medium can also be implemented in a form distributed in a computer system connected by a network. The software can be distributed and stored in a computer system, etc. for execution. The recording medium may be a non-transitory recording medium. Non-transitory recording media refers to a tangible medium that is not related to semi-permanent or temporary storage of information, and does not include transitory transmission signals.

The technical concept of the present invention has been described above based on various embodiments, but the technical concept of the present invention includes various substitutions, changes and modifications that can be realized within the scope that can be understood by those with common sense in the technical field to which the present invention belongs. In addition, it should be understood that such substitutions, changes and modifications can be included in the scope of the accompanying invention application. The embodiments of the present invention can be combined with each other. Each embodiment can be combined in various ways according to the number of situations, and the combined embodiments also belong to the scope of the present invention.

10: electronic device 11: queue list 13: thread pool 21: first type application 22: second type application 23: measurement data 100: server 110: processor 120: communication circuit 130: memory 200: user terminal 200-1: first user terminal 200-2: second user terminal 200-n: nth user terminal 210: processor 220: communication circuit 230: memory 240: input unit 250: output unit 300: communication network S510: step S520: step S530: step

FIG. 1 schematically shows an example of an electronic device processing metric data obtained from one or more applications installed in a user terminal according to an embodiment of the present invention. FIG. 2 is a diagram showing a system including a server, a user terminal and a communication network according to an embodiment of the present invention. FIG. 3 is a block diagram of a server according to an embodiment of the content disclosed in this specification. FIG. 4 is a block diagram of a user terminal according to an embodiment of the content disclosed in this specification. FIG. 5 is a sequence diagram of an action of a server measuring the performance of multiple applications according to an embodiment of the present invention.

10: Electronic devices

11: Queue list

13: Thread pool

21: Type 1 applications

22: Type 2 applications

23: Measurement data

Claims (18)

An electronic device, comprising: a communication circuit, which communicates with at least one external device; one or more processors; and one or more memories, which store the following commands, which, when executed by the one or more processors, cause the one or more processors to perform operations; the one or more processors are configured as follows: obtaining a first metric set of a first type of application, obtaining a second metric set of a second type of application, and based on at least one of the first metric set and the second metric set, The information of the measurement items is used to determine the respective status of the above-mentioned first type application and the above-mentioned second type application, wherein the above-mentioned first measurement set is different from the above-mentioned second measurement set, and the above-mentioned first measurement set and the above-mentioned second measurement set respectively include information of at least one common measurement item, and wherein the above-mentioned one or more processors are further configured to: jointly use a pre-created specific function to obtain the above-mentioned at least one common measurement item information from each of the above-mentioned first type application and the above-mentioned second type application. The electronic device of claim 1, wherein the first type of application is an application that provides a measurement API, and the measurement API returns information of measurement items, and the second type of application is an application that does not provide the measurement API. An electronic device as claimed in claim 2, wherein the one or more processors obtain the first metric set by receiving a response to a call to the metric API from the first type of application, and obtain the second metric set by receiving metric data from the second type of application at a predetermined specific time point. As in claim 2, the electronic device, wherein the above-mentioned type 1 application is a foreground application that performs actions based on user input, and the above-mentioned type 2 application is a background application that performs actions independent of user input. An electronic device as claimed in claim 1, wherein the common measurement items include Internet speed, API call latency, or at least one of the measurement items predetermined for managing specific software. An electronic device as claimed in claim 1, wherein the first measurement set or the second measurement set includes information of measurement items defined by a user. The electronic device of claim 6, wherein the above-mentioned first type of application or the above-mentioned second type of application is an application related to e-commerce, and the measurement items defined by the above-mentioned user include at least one of the application action error code, whether the application error leads to order failure, whether the user cancels the order, or the number of orders per minute. An electronic device as claimed in claim 1, wherein the one or more processors use a queue list to sequentially process the information of the at least one measurement item. An electronic device as claimed in claim 1, wherein the one or more processors use a predetermined number of threads to process information of the at least one measurement item. A method implemented by an electronic device, the electronic device includes a communication circuit for communicating with at least one external device, one or more processors, and one or more memories storing at least one command executed by the one or more processors, the method including the following steps: obtaining a first metric set of a first type of application; obtaining a second metric set of a second type of application; and based on at least one measurement item included in the first metric set and the second metric set, The information of the first type of application and the second type of application is used to determine the respective status of the first type of application and the second type of application, wherein the first metric set is different from the second metric set, and the first metric set and the second metric set respectively include information of at least one common measurement item, and wherein the method further includes the following steps: jointly using a pre-created specific function to obtain the information of the at least one common measurement item from each of the first type of application and the second type of application. As in the method of claim 10, the first type of application is an application of the type that provides a measurement API, and the measurement API returns information of a measurement item, and the second type of application is an application of the type that does not provide the measurement API. The method of claim 11, wherein the step of obtaining the first metric set comprises the following steps: obtaining the first metric set by receiving a response to a call to the metric API from the first type of application, and the step of obtaining the second metric set comprises the following steps: obtaining the second metric set by receiving metric data from the second type of application at a predetermined specific time point. As in the method of claim 11, the first type of application is a foreground application that performs actions based on user input, and the second type of application is a background application that performs actions independent of user input. The method of claim 10, wherein the common measurement items include Internet speed, API call latency, or at least one of the measurement items predetermined for managing specific software. The method of claim 10, wherein the first measurement set or the second measurement set includes information of measurement items defined by a user. The method of claim 15, wherein the above-mentioned first type application or the above-mentioned second type application is an application related to e-commerce, and the measurement items defined by the above-mentioned user include at least one of the application action error code, whether the application error causes order failure, whether the user cancels the order, or the number of orders per minute. The method of claim 10 further includes the following steps: using a queue list to sequentially process the information of at least one measurement item. A computer-readable recording medium is a non-transitory computer recording medium that records commands that, when executed by one or more processors, cause the one or more processors to perform actions, wherein the commands cause the one or more processors to be configured as follows: obtain a first metric set of a first type of application, obtain a second metric set of a second type of application, match metric names and metric types based on information of at least one measurement item included in the first metric set and the second metric set type, thereby generating matching data, transmitting the matching data to an external device, wherein the first measurement set is different from the second measurement set, wherein the first measurement set and the second measurement set respectively include information of at least one common measurement item, and wherein the command is further configured so that the one or more processors: jointly use a pre-created specific function to obtain the information of the at least one common measurement item from each of the first type application and the second type application.