Detailed Description
In order that those skilled in the art will better understand the present invention, a technical solution in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in which it is apparent that the described embodiments are only some embodiments of the present invention, not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the present invention without making any inventive effort, shall fall within the scope of the present invention.
It should be noted that the terms "first," "second," and the like in the description and the claims of the present invention and the above figures are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments of the invention described herein may be implemented in sequences other than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.
According to an aspect of the embodiment of the present invention, there is provided a data acquisition method, optionally, as an optional implementation manner, the data acquisition method may be applied to, but not limited to, a data acquisition system in a hardware environment as shown in fig. 1, where the data acquisition system may be applied to, but not limited to, the terminal device 102 and the terminal device 112. The terminal device 102 may be a mobile terminal (for example, a mobile phone), and the terminal device 112 may be a computer terminal for writing and developing a program for data acquisition and performing hardware performance analysis based on the data acquisition result. The terminal device 102 includes a man-machine interaction screen 104, a processor 106 and a memory 108. The man-machine interaction screen 104 is used for collecting man-machine interaction operation in the test process and displaying a test response interface, the processor 106 is used for running a test program and executing data collection operation, and the memory 108 is used for storing relevant test data and intermediate data and result data in the data collection process. The terminal device 112 may include a database 114 and a processing engine 116. The database 114 is used for providing basic source codes for developing a data collection executable program, and the processing engine 116 is used for performing hardware performance analysis based on the result data, specifically, a data frame with high time consumption can be extracted based on the result data output by the terminal device 102, and the hardware performance analysis can be performed based on the data frame.
The specific process includes the following steps that in step S102, a data collection executable program is developed through the terminal device 112, specifically, an executable file and an automation script for data collection are developed based on HWCPIPE (Hard Ware Count Pipe) source code through an Android NDK (Native Development Kit) tool set. Then, as shown in steps S104-S108, a data acquisition request is received, and then a data acquisition process is invoked according to the data acquisition request, and the result data output by the data acquisition process is acquired. It will be appreciated that the data acquisition request is a data acquisition request generated during a hardware performance test performed on the terminal 102. Meanwhile, the data acquisition process runs the process generated by the executable file and the automation script for data acquisition in the terminal so as to acquire hardware data in the test process. Then, as by step S110, the result data is output. Specifically, the terminal device 102 may output CSV (Comma Separated Value) file format result data to the terminal device 112 through the ADB (Android Debug Bridge) port. Finally, as in step S112, a step of performing hardware performance analysis based on the result data is performed on the terminal device 112.
As an alternative embodiment, the steps S102 and S112 may be performed by the terminal device 102 when the terminal device 102 has a relatively high computing capability. Here, this is an example, and is not limited in any way in the present embodiment.
It should be noted that the Android NDK (Native Development Kit) is an Android development kit, which enables users to use languages such as C and c++ to implement each part of an Android application with native codes, and has the advantages of high operation efficiency, high code security, support of cross-platform and the like.
HWCPIPE (Hard Ware Count Pipe) is a hardware detection tool issued by Arm corporation as an open source that provides a pipeline interface to read the CPU and GPU hardware counters.
The CSV (Comma Separated Value) file format described above refers to storing tabular data (numbers and text) in plain text form. Plain text means that the file is a sequence of characters, free of data that must be interpreted as binary digits. A CSV file consists of any number of records separated by a line break of some sort, each record consisting of fields, the separator between fields being other characters or strings, most commonly commas or tab.
Optionally, in this embodiment, the terminal device may be a terminal device for running a target service, and may include, but is not limited to, at least one of a Mobile phone (such as an Android Mobile phone, an iOS Mobile phone, etc.), a notebook computer, a tablet computer, a palm computer, a MID (Mobile INTERNET DEVICES, a Mobile internet device), a PAD, a desktop computer, a smart tv, etc. The target client may be a video client, an instant messaging client, a browser client, an educational client, etc. that supports providing shooting game tasks. Such networks may include, but are not limited to, wired networks including local area networks, metropolitan area networks, and wide area networks, wireless networks including bluetooth, WIFI, and other networks that enable wireless communications. The server may be a single server, a server cluster composed of a plurality of servers, or a cloud server. The above is merely an example, and is not limited in any way in the present embodiment.
According to the embodiment provided by the application, the executable file and the automation script for data acquisition are developed on the basis of HWCPIPE (Hard Ware Count Pipe) source codes by running the Android NDK (Native Development Kit) tool set on the mobile terminal for hardware testing, then the data acquisition process running with the automation control script is called according to the data acquisition request, the automation data acquisition is realized according to the automation sampling control information contained in the automation control script, and finally the output result data of the acquisition process is acquired, so that the technical effect of automatic acquisition of hardware data is realized, and the technical problem of low data acquisition efficiency in the prior art is solved.
Optionally, as an optional embodiment, as shown in fig. 2, the data collection method includes:
S202, receiving a data acquisition request, wherein the data acquisition request is used for requesting to acquire hardware performance data generated by target equipment in the process of running a target service;
S204, calling a data acquisition process according to the data acquisition request, wherein an automatic control script is operated in the data acquisition process, and the automatic control script contains automatic sampling control information of target service configuration;
s206, obtaining result data output by a data acquisition process.
It is understood that the target device may include, but is not limited to, at least one of a Mobile phone (e.g., an Android Mobile phone, an iOS Mobile phone, etc.), a notebook computer, a tablet computer, a palm computer, a MID (Mobile INTERNET DEVICES, mobile internet device), a PAD, a desktop computer, a smart tv, etc. Meanwhile, the target service can be at least one of various application software including, but not limited to, system software such as various operating systems, specifically Windows, linux, unix, android, IOS and the like, patch programs of the operating systems, namely hardware drivers, and application software such as tool software, game software, management software and the like.
The hardware performance data is further explained below. It can be understood that the hardware performance data is various data such as state parameters and operation parameters generated by various hardware devices included in the target device in the process of operating the target service, so as to evaluate the integrity of the function of the target device in operating the target service, the release degree of performance and the reliability of operation.
Alternatively, the invoking the data acquisition process according to the data acquisition request may be invoking the data acquisition process during the operation of the target service, in other words, the data acquisition process may be invoked while the target service is operated, so as to acquire real-time hardware data during the operation of the target service.
Based on the above-mentioned call to the data acquisition process in the process of operating the target service, the result output by the data acquisition process is obtained, which can be understood that various hardware data sets of the target device in the process of operating the target service are obtained by the data acquisition process. It can be appreciated that the target process can convert the hardware data set into a suitable data file format, such as json, csv, stdf, according to the test requirement in the process of outputting the result data, so as to facilitate the subsequent analysis of the already-data set.
According to the embodiment of the application, the data acquisition request is received, then the data acquisition process running with the automation control script is called according to the data acquisition request, the automation data acquisition is realized according to the automation sampling control information contained in the automation control script, and finally the output result data of the acquisition process is acquired, so that the technical effect of automatic acquisition of hardware data is realized, and the technical problem of low data acquisition efficiency in the prior art is solved.
As an optional solution, the invoking the data acquisition process according to the data acquisition request includes:
S1, reading automatic sampling control information, wherein the automatic sampling control information comprises a self-defined sampling frequency and a self-defined sampling data type;
s2, collecting the hardware performance data belonging to the custom sampling data type according to the custom sampling frequency in the hardware performance data generated in the running process of the target service.
It can be appreciated that in the above embodiment, the automated sampling control information is defined in the data acquisition process, where the automated sampling control information includes a custom sampling frequency and a custom sampling data type. The self-defined sampling frequency indicates the frequency of the data acquisition process for acquiring the hardware data, for example, the process can be defined to acquire the hardware data every 1ms in the running process according to actual needs, and the process can be defined to acquire the hardware data every 0.01ms in the running process according to actual needs, which is not limited in any way. Meanwhile, the custom sampling data types may include Instructions, shadercycles and other performance indexes related to CPU (Central Processing Unit) and GPU (Graphics Processing Unit).
According to the embodiment provided by the application, the required hardware data is more accurately obtained through the data acquisition program by customizing the sampling frequency and the custom sampling data type in the data acquisition process, so that the technical effect of improving the data acquisition efficiency is realized.
As an alternative, the collecting the hardware performance data belonging to the custom sampling data type according to the custom sampling frequency in the hardware performance data generated in the operation process of the target service includes:
s1, acquiring candidate performance data collected from pipeline interfaces corresponding to hardware components in target equipment, wherein the candidate performance data comprises a performance data set generated by each hardware component in the running process of target service;
S2, determining at least one target performance data set belonging to the custom sampling data type from the candidate performance data;
s3, collecting the target performance data set according to the self-defined sampling frequency.
The above scheme is specifically described below with reference to fig. 3. As shown in fig. 3, within the target device 305, there are a plurality of hardware components, as illustrated by hardware component 301, hardware component 302, hardware component 303, hardware component 304. Corresponding to the above hardware components 301 to 304, the generated performance data sets corresponding to the respective hardware components are acquired through the pipeline interfaces 301-1, 301-2, 301-3, and 301-4, respectively. For example, as illustrated in FIG. 3, a first set of performance data 301-2 generated from hardware component 301 is obtained via pipeline interface 301-1, a second set of performance data 302-2 generated from hardware component 302 is obtained via pipeline interface 302-1, and so on. It will be appreciated that the data sets from different hardware components are candidate performance data in the method, and after acquiring candidate performance data collected from pipeline interfaces corresponding to the hardware components in the target device, the candidate performance data is stored in the data collection process space 307, and the target performance data set 306 is determined from the collected candidate performance data.
It is appreciated that different numbers and different types of performance data sets may be generated for different hardware components in the target device 305. In other words, the types of hardware performance data that different hardware components may produce may be different, and furthermore, the different amounts of hardware performance data that may be produced may also be different in size.
It will be appreciated that after the candidate performance data is obtained, at least one target performance data set is determined from the candidate performance data based on the custom sample data type. For example, in the case that the custom sampling data types are Instructions and SHADERCYCLES types, the data sets with the data types of Instructions and SHADERCYCLES are determined from the candidate performance data, and the data sets are used as the target performance data sets.
Further, after the target performance data set is determined, data in the target performance data set is collected according to the self-defined sampling rate. Specifically, in the case of a custom sampling rate of 1 ms/time, data generated in the target performance dataset is collected every 1 ms.
According to the embodiment provided by the application, the required hardware data is more accurately obtained through the data acquisition program by customizing the sampling frequency and the custom sampling data type in the data acquisition process, so that the technical effect of improving the data acquisition efficiency is realized.
According to the embodiment provided by the application, the required hardware data is more accurately obtained through the data acquisition program by customizing the sampling frequency and the custom sampling data type in the data acquisition process, so that the technical effect of improving the data acquisition efficiency is realized.
As an alternative, the collecting the target performance dataset according to the custom sampling frequency includes:
S1, under the condition that a sampling starting condition matched with a target performance data set is reached, starting to acquire according to a self-defined sampling frequency;
And S2, ending the collection of the target performance data set under the condition that the sampling closing condition matched with the target performance data set is reached.
It can be understood that in the running process of the data acquisition process, the running of the data acquisition process can be controlled by the sampling on condition and the sampling off condition, so that the acquisition is started according to the self-defined sampling frequency when the sampling on condition matched with the target performance data set is reached, and the acquisition of the target performance data set is ended when the sampling off condition matched with the target performance data set is reached. In other words, the operation of the data acquisition can execute the starting and ending logic at any time according to the requirement of the data acquisition.
By setting the sampling opening condition and the sampling closing condition, the embodiment provided by the application achieves the technical effect of acquiring the needed hardware data information at any time.
As an alternative, in the case that the automatic sampling control information includes the type of the sampling result file and the output path, the obtaining the result data output by the data collecting process includes storing the result data matched with the type of the sampling result file in the output path of the sampling result file.
It will be appreciated that the above automated sampling control information may also include the file type of the sampling result file, and the output path of the sampling result file. That is, the file type and output path of the output result file may be determined according to the control automation sampling control information parameter information. Alternatively, the file type of the result file may be a CSV file.
According to the embodiment provided by the application, the file type of the sampling result file and the output path of the sampling result file are defined in the automatic sampling control information, so that the result file is matched with the result file analysis process, and the technical effect of improving the efficiency of result file analysis is realized.
As an alternative, before receiving the performance test request, the method further includes:
s1, modifying a data collection control strategy of a pipeline interface corresponding to each hardware component in target equipment, wherein the data collection control strategy carries self-defined automatic sampling control information;
S2, generating an automatic control script based on the data collection control strategy.
According to the embodiment of the application, before the hardware performance data is acquired by adopting the data acquisition process, the data acquisition control strategy of the pipeline interface corresponding to each hardware component in the target equipment is required to be modified so as to be suitable for the data acquisition program. Meanwhile, an automatic control script can be generated based on a data collection control strategy, so that automatic control collection of hardware data is realized, and further the technical effect of acquiring needed hardware data information at any time is realized.
As an alternative, the generating an automation control script based on the data collection control policy includes:
s1, compiling interface source codes corresponding to a data collection control strategy to obtain an executable file;
s2, compiling and generating an automatic control script based on the executable file.
It will be appreciated that, as an alternative, the data collection control policy may be a collection control policy defined by Hwcpipe (HardWareCountPipe), so that after the modification of the interface source code corresponding to the data collection control policy, the interface source code is compiled by cmake to obtain the executable file. The method for modifying the interface source code corresponding to the data collection control strategy can specifically modify Hwcpipe source codes so as to meet the requirements of self-defined sampling frequency, self-defined sampling data and self-defined sampling results.
The above Hwcpipe is modified and compiled with cmake to obtain an executable program HARDENPERF. It will be appreciated that the executable program HARDENPERF described above may be used to collect hardware performance data. After the executable program HARDENPERF is obtained, an automation control script is written HARDENPERF based on the executable program HARDENPERF, which may further include parameter conditions such as automatic condition preparation, acquisition start, acquisition shut-off, and the like.
It will be appreciated that cmake is a compilation tool that allows a developer to write a platform-independent cmakelist.txt file to customize the entire compilation process, and then further generate the required localized Makefile and engineering files, such as Unix Makefile or Windows Visual Studio engineering, based on the target user's platform.
According to the embodiment provided by the application, the source code of the hardware counter pipeline interface Hwcpipe is modified and secondarily packaged, and the automatic control script file is written according to the executable file obtained by packaging, so that the hardware performance data required by the user can be acquired at any time according to the requirement, the data acquisition process can be stopped at any time, and the technical effects of acquiring the hardware performance data and reducing the maintenance and access cost are realized.
One embodiment of the present application is described below with reference to fig. 4 and 5.
As shown in the flowchart of fig. 5, first, step S502 is performed to modify the data collection control policy;
specifically, as shown in fig. 4, the NDK toolkit may be used to perform development work, and modify Hwcpipe source codes so as to enable the source codes to meet the requirement of custom sampling data. After the Hwcpipe source code is modified, cmake is used to compile and generate an executable file HARDENPERF, it can be understood that, in the execution process of the executable file HARDENPERF, hwcpipe can be invoked by the modified data collection control policy, so that the requirements of the custom sampling frequency, the custom sampling data type and the custom sampling result file of hardware performance data collection can be met.
Then, as step S504, an automation control script is generated based on the data collection control policy;
Specifically, the automation control script is a Python automation script file written based on HARDENPERF, and is used for executing on a pc, so as to realize that the control target device (such as a mobile phone) executes related operation logic, such as preparation performance execution conditions, control HARDENPERF starts data acquisition logic, control HARDENPERF closes data acquisition logic, and the like. As shown in fig. 4, a framework Gautomator for performing an automated test on a mobile phone game is running on the PC side, and in the process of performing an automated test through the automated test framework Gautomator, a Python automated script file written based on HARDENPERF may be called to implement automatic collection of hardware performance of a hardware device running the mobile phone game. More specifically, the hardware device running the mobile game herein may be any mobile hardware suitable for use in versions of arm architecture maliGPU driver abi greater than 10.
Then, as step S506, the target task is run;
As shown in fig. 4, the PC device and the mobile phone a are connected through the ADB port, and a target task is executed on the mobile phone a, and specifically, the target task may be any unit or ue4 game task.
It will be appreciated that the ADB (Android Debug Bridge) port is a versatile command line tool that can be used to communicate between devices. ADB commands can be used to perform various device operations (e.g., install and debug applications) and provide access to Unix shell (which can be used to run various commands on a device). It is a client-server program that includes three components, client, daemon (adbd), and server.
Then, if yes, step S508 is executed, and if no, step S510 is executed, and step S506 is executed again;
As shown in fig. 4, on a PC end device running with a manual automatic test framework Gautomator, an ADB forward command is used to control pushing an executable file HARDENPERF to a mobile phone a through an ADB port, and according to the control command pushed through the ADB port on the PC end, whether to run a data acquisition process is determined.
It will be appreciated that the logic for performing the determination of whether to run the data collection process herein may be implemented by the above-described Python automation script file written based on HARDENPERF running on the PC side.
Step S510, under the condition of judging to run the data acquisition process, reading the automatic sampling control information;
In particular, the automated sampling control information herein may include a custom sampling frequency, a custom sampling data type, a custom sampling result file type, and an output path of the custom sampling result file.
It will be appreciated that the custom sampling frequency is used to determine a hardware data sampling period, the custom sampling data type is used to determine a hardware performance data type to be acquired, the custom sampling result file type is used to determine an output file type of the data acquisition process, and the output path is used to determine a storage path after the output file is acquired.
As shown in fig. 4, in the case of judging that the data acquisition process is executed according to the control instruction pushed by the PC side, the HARDENPERF program is executed on the mobile phone a, and the start and stop of the HARDENPERF program are controlled through the perf_ harden () instruction parameter.
Then, step S512 is executed to determine whether the data belongs to the custom sampling data type, step S514 is executed if the acquired data is determined to be the custom sampling data type, and step S512 is executed back if the acquired data is determined not to be the custom sampling data type;
determining a target performance dataset as in step S514;
It will be appreciated that in the process of collecting data, candidate performance data collected from pipeline interfaces corresponding to each hardware component in the target device is first obtained, and at least one target performance data set belonging to the custom sampling data type is determined from the candidate performance data. For example, in the case where the custom sampling data type is determined to be instraction, hadercycles, only hardware performance data of the instraction, hadercycles type is acquired, and the data set of the hardware performance data of the instraction, hadercycles type is the target performance data set.
Step S516 is then executed, and data acquisition is carried out according to the self-defined sampling frequency;
it will be appreciated that after the target performance dataset is determined, data in the target performance dataset is collected at a custom sampling rate. Specifically, in the case of a custom sampling rate of 1 ms/time, data generated in the target performance dataset is collected every 1 ms.
Then, step S518 is executed to determine whether the data acquisition process is finished, step S520 is executed if the data acquisition process is determined to be finished, and step S516 is executed again if the data acquisition process is determined to be not finished;
It will be appreciated that the logic for performing the determination herein as to whether to end the data collection process may be implemented by the Python automation script file written based on HARDENPERF as described above. As shown in fig. 4, a Python automation script file written based on HARDENPERF is run on the PC side, and a control instruction is pushed to the mobile phone a through the ADB port, so as to control start and stop of a HARDENPERF program running on the mobile phone side.
Executing step S520 to obtain result data under the condition that the data acquisition process is judged to be ended;
It will be appreciated that the result data may be determined according to the type of the custom sampling result file and the output path of the custom sampling result file, and optionally, the file type of the result file may be a CSV format data file.
As shown in fig. 4, a HARDENPERF program running in the mobile phone a collects and obtains a hardware performance data file in a CSV format, and transmits the data file back to a Gautomator automatic test framework running in the terminal through an ADB port, so as to perform a subsequent test task.
According to the embodiment provided by the application, the executable file and the automation script for data acquisition are developed on the basis of HWCPIPE (Hard Ware Count Pipe) source codes by running the Android NDK (Native Development Kit) tool set on the mobile terminal for hardware testing, then the data acquisition process running with the automation control script is called according to the data acquisition request, the automation data acquisition is realized according to the automation sampling control information contained in the automation control script, and finally the output result data of the acquisition process is acquired, so that the technical effect of automatic acquisition of hardware data is realized, and the technical problem of low data acquisition efficiency in the prior art is solved.
It should be noted that, for simplicity of description, the foregoing method embodiments are all described as a series of acts, but it should be understood by those skilled in the art that the present invention is not limited by the order of acts described, as some steps may be performed in other orders or concurrently in accordance with the present invention. Further, those skilled in the art will also appreciate that the embodiments described in the specification are all preferred embodiments, and that the acts and modules referred to are not necessarily required for the present invention.
According to another aspect of the embodiment of the present invention, there is also provided a data acquisition apparatus for implementing the above data acquisition method. As shown in fig. 6, the apparatus includes:
a receiving unit 602, configured to receive a data acquisition request, where the data acquisition request is used to request to acquire hardware performance data generated by a target device in a process of running a target service;
The calling unit 604 is configured to call a data acquisition process according to the data acquisition request, where an automation control script is run in the data acquisition process, and the automation control script contains automation sampling control information of target service configuration;
The acquiring unit 606 is configured to acquire result data output by the data acquisition process.
Alternatively, in this embodiment, the embodiments to be implemented by each unit module may refer to the embodiments of each method described above, which are not described herein again.
According to still another aspect of the embodiment of the present invention, there is also provided an electronic device for implementing the above data acquisition method, where the electronic device may be a terminal device or a server as shown in fig. 7. The present embodiment is described taking the electronic device as a terminal device as an example. As shown in fig. 7, the electronic device comprises a memory 702 and a processor 704, the memory 702 storing a computer program, the processor 704 being arranged to perform the steps of any of the method embodiments described above by means of the computer program.
Alternatively, in this embodiment, the electronic device may be located in at least one network device of a plurality of network devices of the computer network.
Alternatively, in the present embodiment, the above-described processor may be configured to execute the following steps by a computer program:
s1, receiving a data acquisition request, wherein the data acquisition request is used for requesting to acquire hardware performance data generated by target equipment in the process of running a target service;
S2, calling a data acquisition process according to the data acquisition request, wherein an automatic control script is operated in the data acquisition process, and the automatic control script contains automatic sampling control information of target service configuration;
S3, obtaining result data output by a data acquisition process.
Alternatively, it will be understood by those skilled in the art that the structure shown in fig. 7 is only schematic, and the electronic device may also be a smart phone (such as an Android Mobile phone, an iOS Mobile phone, etc.), a tablet computer, a palm computer, a Mobile internet device (Mobile INTERNET DEVICES, MID), a PAD, etc. Fig. 7 is not limited to the structure of the electronic device and the electronic apparatus described above. For example, the electronics may also include more or fewer components (e.g., network interfaces, etc.) than shown in fig. 7, or have a different configuration than shown in fig. 7.
The memory 702 may be used to store software programs and modules, such as program instructions/modules corresponding to the data acquisition methods and apparatuses in the embodiments of the present invention, and the processor 704 executes the software programs and modules stored in the memory 702, thereby performing various functional applications and data processing, that is, implementing the data acquisition methods described above. The memory 702 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid state memory. In some examples, the memory 702 may further include memory remotely located relative to the processor 704, which may be connected to the terminal via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof. The memory 702 may be used for storing various parts of hardware performance data, data acquisition information, and the like. As an example, as shown in fig. 7, the memory 702 may include, but is not limited to, the receiving unit 602, the calling unit 604, and the acquiring unit 606 in the data acquiring apparatus. In addition, other module units in the data acquisition device may be included, but are not limited to, and are not described in detail in this example.
Optionally, the transmission device 706 is used to receive or transmit data via a network. Specific examples of the network described above may include wired networks and wireless networks. In one example, the transmission device 706 includes a network adapter (Network Interface Controller, NIC) that can connect to other network devices and routers via a network cable to communicate with the internet or a local area network. In one example, the transmission device 706 is a Radio Frequency (RF) module that is configured to communicate wirelessly with the internet.
The electronic device further includes a display 708 for displaying hardware performance data acquisition processes in the interface, and a connection bus 710 for connecting the various modular components in the electronic device.
In other embodiments, the terminal device or the server may be a node in a distributed system, where the distributed system may be a blockchain system, and the blockchain system may be a distributed system formed by connecting the plurality of nodes through a network communication. Among them, the nodes may form a Peer-To-Peer (P2P) network, and any type of computing device, such as a server, a terminal, etc., may become a node in the blockchain system by joining the Peer-To-Peer network.
According to one aspect of the present application, there is provided a computer program product comprising a computer program/instruction containing program code for executing the method shown in the flow chart. In such embodiments, the computer program may be downloaded and installed from a network via a communication portion, and/or installed from a removable medium. When executed by a central processing unit, performs various functions provided by embodiments of the present application.
The foregoing embodiment numbers of the present invention are merely for the purpose of description, and do not represent the advantages or disadvantages of the embodiments.
According to an aspect of the present application, there is provided a computer-readable storage medium, from which a processor of a computer device reads the computer instructions, the processor executing the computer instructions, causing the computer device to perform the above-described data acquisition method.
Alternatively, in the present embodiment, the above-described computer-readable storage medium may be configured to store a computer program for performing the steps of:
s1, receiving a data acquisition request, wherein the data acquisition request is used for requesting to acquire hardware performance data generated by target equipment in the process of running a target service;
S2, calling a data acquisition process according to the data acquisition request, wherein an automatic control script is operated in the data acquisition process, and the automatic control script contains automatic sampling control information of target service configuration;
S3, obtaining result data output by a data acquisition process.
Alternatively, in this embodiment, all or part of the steps in the various methods of the above embodiments may be implemented by a program for instructing the terminal device related hardware, and the program may be stored in a computer readable storage medium, where the storage medium may include a flash disk, a Read-Only Memory (ROM), a random access Memory (Random Access Memory, RAM), a magnetic disk, or an optical disk.
The integrated units in the above embodiments may be stored in the above-described computer-readable storage medium if implemented in the form of software functional units and sold or used as separate products. Based on such understanding, the technical solution of the present invention may be embodied in essence or a part contributing to the prior art or all or part of the technical solution in the form of a software product stored in a storage medium, comprising several instructions for causing one or more computer devices (which may be personal computers, servers or network devices, etc.) to perform all or part of the steps of the above-described method of the various embodiments of the present invention.
In the foregoing embodiments of the present invention, the descriptions of the embodiments are emphasized, and for a portion of this disclosure that is not described in detail in this embodiment, reference is made to the related descriptions of other embodiments.
In several embodiments provided by the present application, it should be understood that the disclosed client may be implemented in other manners. The above-described embodiments of the apparatus are merely exemplary, and the division of the units, such as the above, is merely a logical function division, and may be implemented in another manner, for example, a plurality of units or components may be combined or may be integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be through some interfaces, units or modules, or may be in electrical or other forms.
The units described above as separate components may or may not be physically separate, and components shown as units may or may not be physical units, may be located in one place, or may be distributed over a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
In addition, each functional unit in the embodiments of the present invention may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.
While the foregoing is directed to the preferred embodiments of the present invention, it will be appreciated by those skilled in the art that changes and modifications may be made without departing from the principles of the invention, and such changes and modifications are intended to be included within the scope of the invention.