CN113971115A - Method and device for determining demand of container resource, server and storage medium - Google Patents

Method and device for determining demand of container resource, server and storage medium Download PDF

Info

Publication number
CN113971115A
CN113971115A CN202010724633.2A CN202010724633A CN113971115A CN 113971115 A CN113971115 A CN 113971115A CN 202010724633 A CN202010724633 A CN 202010724633A CN 113971115 A CN113971115 A CN 113971115A
Authority
CN
China
Prior art keywords
container
information
resource
resources
configuration information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202010724633.2A
Other languages
Chinese (zh)
Inventor
董逸轩
叶晓龙
王璇
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China Mobile Communications Group Co Ltd
China Mobile Group Zhejiang Co Ltd
Original Assignee
China Mobile Communications Group Co Ltd
China Mobile Group Zhejiang Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by China Mobile Communications Group Co Ltd, China Mobile Group Zhejiang Co Ltd filed Critical China Mobile Communications Group Co Ltd
Priority to CN202010724633.2A priority Critical patent/CN113971115A/en
Publication of CN113971115A publication Critical patent/CN113971115A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/34Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3442Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for planning or managing the needed capacity
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/34Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3447Performance evaluation by modeling
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3664Environments for testing or debugging software
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing
    • G06F11/3672Test management
    • G06F11/3688Test management for test execution, e.g. scheduling of test suites
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/815Virtual

Abstract

The invention discloses a method, a device, a server and a storage medium for determining the demand of container resources, wherein the method comprises the following steps: receiving system requirement information input by a user; the system requirement information comprises environment configuration information and container performance index information; deploying container resources of various configurations according to the environment configuration information; utilizing various configured container resource bearing systems to operate and simulate service calling for pressure testing, and acquiring test result data; constructing a plurality of relation models of pressure tests corresponding to a plurality of configurations; and calculating an optimal relation model according to the container performance index information and the multiple relation models, and converting the optimal relation model into resource information. According to the scheme, the configuration and the number of the optimal container resources are determined through the pressure test, so that the determined container resources are highly matched with the actual demand, and the accuracy of resource calculation is improved.

Description

Method and device for determining demand of container resource, server and storage medium
Technical Field
The invention relates to the technical field of cloud computing, in particular to a method and a device for determining demand of container resources, a server and a storage medium.
Background
With the development and wide application of the Docker container technology, the container resources of the carrying system are very important. The number of container resource offerings determines the attributes of the system in terms of non-functionality, such as performance, reliability, and security. How to calculate the container resources needed by the system quickly and reasonably is a significant problem faced by all large systems.
The existing common technical solutions mainly include the following two types:
scheme one, the mode of human brain transformation assessment is adopted: based on traditional human experience, resource calculation is carried out by means of conversion of a mode summarized by the human experience, and the method mainly depends on the historical experience, the technical ability and the summarized induction ability of personnel.
Scheme two, the resource mode of the existing system is referred to: the existing system is a system which has been stably and normally operated for a period of time in the IT industry, the system architecture and the service types are similar, and a calculation method for generating resource requirements is generated based on resource reference data provided by the similar system.
However, the inventor finds that the prior art has at least the following problems in the process of implementing the embodiment of the invention: first, the evaluation mode of human brain transformation has strong dependence on human ability. Meanwhile, the calculation method of human brain transformation is relatively simple and has no reasonable scientific basis; and as the system becomes more complex and bulky, the calculation accuracy of the required resources is low from the viewpoint of the effect of the calculation method, and the situations of system bottleneck and error evaluation are easy to occur. Secondly, the resource mode of the existing system is introduced, the requirement on the similarity of the system is high, and other resource types exceeding the existing resource category are dead zones; in practical application, these blind areas are often the core resource points of the system; and, from an overlay perspective, there are fewer systems that reference the resource patterns of the existing systems for evaluation.
In summary, the existing technical solutions all have serious deficiencies, and cannot adapt to the resource calculation requirements of the current system maintenance in the aspects of accuracy, adaptability, coverage rate, and the like.
Disclosure of Invention
In view of the above, embodiments of the present invention are proposed in order to provide a demand determination method, apparatus, server and storage medium for container resources that overcome or at least partially solve the above-mentioned problems.
According to an aspect of the embodiments of the present invention, there is provided a method for determining a demand for a container resource, including:
receiving system requirement information input by a user; the system requirement information comprises environment configuration information and container performance index information;
deploying container resources of various configurations according to the environment configuration information; utilizing various configured container resource bearing systems to operate and simulate service calling for pressure testing, and acquiring test result data;
constructing a plurality of relation models of pressure tests corresponding to a plurality of configurations, wherein each relation model comprises configuration information of container resources, pressure test conditions and test result data;
and calculating an optimal relation model according to the container performance index information and the multiple relation models, and converting the optimal relation model into resource information.
According to another aspect of the embodiments of the present invention, there is provided a demand determination apparatus for container resources, including:
the client module is suitable for receiving system requirement information input by a user; the system requirement information comprises environment configuration information and container performance index information;
the pressure testing module is suitable for deploying container resources with various configurations according to the environment configuration information; utilizing various configured container resource bearing systems to operate and simulate service calling for pressure testing, and acquiring test result data;
the resource calculation module is suitable for constructing a plurality of relation models of pressure tests corresponding to a plurality of configurations, wherein each relation model comprises configuration information of container resources, pressure test conditions and test result data; and calculating an optimal relation model according to the container performance index information and the multiple relation models, and converting the optimal relation model into resource information.
According to still another aspect of the embodiments of the present invention, there is provided a server including: the system comprises a processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface complete mutual communication through the communication bus;
the memory is used for storing at least one executable instruction, and the executable instruction enables the processor to execute the operation corresponding to the requirement determination method of the container resource.
According to a further aspect of the embodiments of the present invention, there is provided a computer storage medium, where at least one executable instruction is stored, and the executable instruction causes a processor to perform an operation corresponding to the method for determining demand for container resources as described above.
According to the method, the device, the server and the storage medium for determining the requirement of the container resource, disclosed by the embodiment of the invention, system requirement information input by a user is received, the container resources with various configurations are deployed according to environment configuration information in the system requirement information, then a pressure test is carried out, and test result data are collected; and aiming at multiple tests, respectively establishing a relation model consisting of the configuration information of the container resources, the pressure test conditions and the test result data to obtain multiple relation models, selecting an optimal relation model according to the container performance indexes in the system demand information and the multiple relation models, and then converting to obtain the optimal configuration information of the container resources and the most appropriate container quantity. Therefore, according to the scheme of the invention, through simulating service calling and performing pressure testing on various configured container resources, and then performing resource screening and conversion as required, the resource information highly matched with the actual requirement of any system can be determined, and compared with the existing technical scheme of evaluating human brain or introducing the resource mode of the existing system, the accuracy, coverage rate and effectiveness of resource calculation are greatly improved.
The foregoing description is only an overview of the technical solutions of the embodiments of the present invention, and the embodiments of the present invention can be implemented according to the content of the description in order to make the technical means of the embodiments of the present invention more clearly understood, and the detailed description of the embodiments of the present invention is provided below in order to make the foregoing and other objects, features, and advantages of the embodiments of the present invention more clearly understandable.
Drawings
Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the following detailed description of the preferred embodiments. The drawings are only for purposes of illustrating the preferred embodiments and are not to be construed as limiting the embodiments of the invention. Also, like reference numerals are used to refer to like parts throughout the drawings. In the drawings:
FIG. 1 is a flow chart illustrating a method for determining demand for container resources according to an embodiment of the present invention;
FIG. 2 is a flow chart illustrating a method for determining the demand for container resources according to another embodiment of the present invention;
FIG. 3 is a diagram illustrating user-entered key environmental configuration information in one particular embodiment;
FIG. 4 shows a simplified flow diagram of a simulated pressure measurement process in an alternative embodiment;
FIG. 5 is a diagram illustrating data contained in a relational model in one particular embodiment;
FIG. 6 is a schematic structural diagram of a demand determination apparatus for container resources according to an embodiment of the present invention;
fig. 7 shows a schematic structural diagram of a server provided in an embodiment of the present invention.
Detailed Description
Exemplary embodiments of the present invention will be described in more detail below with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention can be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.
Fig. 1 shows a flowchart of a demand determination method for container resources according to an embodiment of the present invention. The method is used for configuring and quantity of container resources operated by the bearing system. As shown in fig. 1, the method comprises the steps of:
step S110: receiving system requirement information input by a user; wherein the system requirement information comprises environment configuration information and container performance index information.
The system requirement information refers to requirement information of a target system that needs container resources to carry operation, and the target system (as the system in the following) may be any system that needs to be tested or brought online.
Specifically, through a user operating a terminal, a user can input system requirement information necessary for calculating required container resources, where the system requirement information at least needs to include environment configuration information to subsequently configure container resources of different specifications, and container performance index information, where the container performance index information is limitation information on the number of concurrences that can be carried by a single container and a response result of a service invocation, so as to subsequently calculate an optimal relationship model, for example, if a response time in a container performance index is 5ms, it is equivalent to limiting that the response time of the service invocation should be less than or equal to 5ms when a container bearer system operates. In addition, the system requirement information also includes information necessary for simulating the system operation, such as code packets and the like.
Step S120: deploying container resources of various configurations according to the environment configuration information; and operating and simulating service call by utilizing various configured container resource bearing systems to perform pressure test, and acquiring test result data.
The environment configuration information may reflect, among other things, the hardware and/or software configuration required for the system to operate, e.g., the required memory size.
Specifically, a plurality of container configurations are set based on the environment configuration information, for example, the plurality of memory configurations of the container are respectively set to 1G, 2G, 4G, and so on. And then, carrying system operation by using various configured container resources, and simulating service call and collecting test result data by using a pressure test tool. In the process of simulating service invocation, pressure test is completed by continuously adjusting test conditions for any configured container resource, and test result data under different test conditions are collected.
Step S130: and constructing a plurality of relation models of the pressure test corresponding to the plurality of configurations, wherein each relation model comprises configuration information of the container resource, pressure test conditions and test result data.
A relationship model is a state or content at a certain time or under a certain condition, represented by a single result type, relationship, the relationship model is static and stable, and the relationship is dynamic and constantly changes with time or condition.
In this step, a relationship model between the configuration information of the container resource and the corresponding test result data is established for the pressure test condition, and thus, a plurality of relationship models can be obtained through a plurality of tests.
For example, if the configuration information of a certain test is a container resource of a 2G memory, the test condition is a concurrency number of 500, and the test result data is a response time of 6ms, a relationship model can be constructed as (configuration: 2G memory; concurrency number: 500; response time: 6 ms).
Step S140: and calculating an optimal relation model according to the container performance index information and the multiple relation models, and converting the optimal relation model into resource information.
In practice, the container resources allocated for the system are both "essential" and "essential". In order to ensure that resource allocation is 'necessary', the information meeting the container performance index needs to be considered, and the normal operation of the system is ensured; meanwhile, in order to ensure that resource allocation is "necessary", allocation of additional resources should be avoided as much as possible, wherein the additional resources are of two types, one is idle resources and one is wasted resources.
Based on the above-described considerations of both "necessity" and "necessity", a relationship model that can satisfy the container performance index information using the lowest-allocated container resource is selected from among the plurality of relationship models as the optimal relationship model.
After the optimal relation model is obtained, optimal configuration information of the container resources is obtained, which is equivalent to the specification of the container resources; and the pressure test condition in the optimal relation model reflects the pressure resistance condition of a single container resource, and the quantity of the required container resource is calculated by utilizing the pressure resistance condition and the information reflecting the whole pressure resistance condition in the system demand information. Thus, resource information including the optimal configuration information of the container resources and the number of the container resources is obtained.
For example, the maximum number of concurrencies that can be borne by a single container resource is 500, and the number of concurrencies per second required by the service is 1000, then the number of container resources required for conversion is 1000/500-2.
According to the method for determining the requirement of the container resource, provided by the embodiment, system requirement information input by a user is received, container resources with various configurations are deployed according to environment configuration information in the system requirement information, then a pressure test is carried out, and test result data are collected; and aiming at multiple tests, respectively establishing a relation model consisting of the configuration information of the container resources, the pressure test conditions and the test result data to obtain multiple relation models, selecting an optimal relation model according to the container performance indexes in the system demand information and the multiple relation models, and then converting to obtain the optimal configuration information of the container resources and the most appropriate container quantity. Therefore, according to the scheme of the embodiment, through simulating service calling and performing pressure testing on various configured container resources, and then performing resource screening and conversion as required, resource information highly matched with actual requirements of any system can be determined, and compared with the existing technical scheme of evaluating human brain or introducing resource modes of the existing system, the accuracy, coverage rate and effectiveness of resource calculation are greatly improved.
Fig. 2 is a flowchart illustrating a method for determining the requirement of a container resource according to another embodiment of the present invention. As shown in fig. 2, the method comprises the steps of:
step S210: receiving system requirement information input by a user; wherein the system requirement information comprises environment configuration information and container performance index information.
The user inputs system requirement information on a foreground interface of the user operation terminal, wherein the system requirement information comprises but is not limited to at least one of the following information: system name, importance level, middleware version, traffic, service packet, code package, and environment configuration. The system requirement information is tagged with user requirement information through streaming processing throughout the whole life cycle determined by resource requirements, and is stored in a corresponding database table according to the tagged Type, wherein the code packet is stored in an FTP (File Transfer Protocol) server.
Step S220: deploying a plurality of groups of container resources with CPU specifications and memory specifications according to the environment configuration information; and (4) operating and simulating service call by utilizing each group of container resource bearing systems with CPU specifications and memory specifications to perform pressure test, and acquiring test result data.
FIG. 3 is a diagram illustrating user-entered key environmental configuration information in one particular embodiment. As shown in fig. 3, the key environmental configuration information includes: the system information, the container specification and the version information are three types of information, wherein the container specification comprises a CPU specification and a memory specification. For example, the container specification is 1 CPU and 2G memory. It should be noted that the container specification is only an ideal specification estimated by a user, and one of the purposes of the embodiments of the present invention is to determine a container specification that actually satisfies the container performance index information.
In this embodiment, the configuration information of the container resource includes a CPU specification and a memory specification. And adjusting the container specification in the environment configuration information to obtain a plurality of groups of CPU specifications and memory specifications. For example, if the container specification in the environment configuration information is 1 CPU and 2G memory, the following configurations may be set as shown in table 1 below:
CPU specification (One) Memory specification (G)
Configuration 1 1 1.5
Configuration 2 1 2
Configuration 3 1 2.5
Configuration 4 2 1.5
Configuration 5 2 2
Configuration 6 2 2.5
As shown in table 1 above, by adjusting the number of CPUs and the size of the memory up and down, respectively, a plurality of configurations within a certain range from the container specification in the environment configuration information can be obtained.
After setting a plurality of configurations, namely a plurality of sets of CPU specifications and memory specifications, deploying container resources of the specifications, wherein one container resource of each specification is set. And then, aiming at each group of single container resources with the CPU specification and the memory specification, operating by using the container resource bearing system, carrying out simulation pressure test, and acquiring test result data. It should be noted that, in the embodiment of the present invention, a specific technical implementation of the analog pressure measurement is not limited, and a person skilled in the art may flexibly select a corresponding implementation manner according to an actual requirement. The following describes a specific process of analog pressure measurement in an alternative technical implementation:
fig. 4 shows a simplified flow diagram of a simulated pressure measurement process in an alternative embodiment. In this alternative embodiment, the system requirement information further includes a code packet and a service packet of the system. As shown in fig. 4, after deploying a plurality of sets of container resources with CPU specifications and memory specifications according to environment configuration information, a plurality of application-independent image files are generated according to the plurality of sets of CPU specifications and memory specifications for test comparison; then, in the process of simulating pressure measurement, fusing the mirror image file, a pressure testing tool (namely a graph pressure testing tool) and a code packet to generate a container mirror image for deployment and operation of the container, wherein the testing tool is configured through the Dockerfile file, test data is collected, and if an application system or a configuration file is adjusted, the container mirror image can be dynamically deployed; operating a container resource based on the container image, wherein the container resource comprises an application program and can provide application service; and generating a test case according to the service message for carrying out pressure test on the container resource, acquiring test result data through a pressure test tool, carrying out noise reduction processing on the test result data, acquiring a reference value of each test result, and storing the data for subsequent integration analysis. Meanwhile, the test cases are further labeled, such as system names, time slices, service types and other labels are marked, and then the test cases are interacted with the DB to persist the data and can be recycled.
And in the process of performing the pressure test, continuously adjusting the pressure test conditions for any group of container resources with the CPU specification and the memory specification to complete multiple tests, for example, continuously increasing the concurrency number to sequentially complete the tests until the concurrency number exceeds the bearing range of the currently configured container resource, and stopping the pressure test on the currently configured container resource.
Step S230: and constructing a plurality of relation models of the pressure test corresponding to the plurality of configurations, wherein each relation model comprises configuration information of the container resource, pressure test conditions and test result data.
A combination of a configuration and a stress test condition, and test result data corresponding to the combination, may form a relational model.
The relationship model is a state or content at a certain time or under a certain condition and is represented by a single result type and relationship, the relationship model is static and stable, and the relationship is dynamic and changes constantly with time or under a condition. And establishing a relation model through container configuration, pressure test conditions and test result data, and storing the relation model persistently, so that subsequent integration and analysis are facilitated.
FIG. 5 is a diagram illustrating data contained in a relational model in one particular embodiment. As shown in fig. 5, the relationship model is composed of three parts, i.e., a container configuration, a condition and a performance, wherein the container configuration includes a CPU specification and a memory specification, the condition refers to a pressure test condition, which includes a concurrency condition and/or a test time condition, and the performance refers to a test result, and the test result data includes a response duration and/or a response success rate.
Step S240: and calculating an optimal relation model according to the container performance index information and the multiple relation models.
Specifically, in order to ensure "necessity" and "necessity" of resource allocation, the calculation formula of the optimal relationship model is set as:
Figure BDA0002601219480000091
in the formula, M is an optimal relationship model, Yx represents container performance index information, Mx is information corresponding to the container performance index information in the pressure test condition and test result data, and Md represents configuration information of container resources. Wherein, the container performance index information refers to the limitation information of the concurrency number and the response result of the service call which can be carried by a single container, then Mx>The meaning of Yx includes: the concurrency condition in the pressure test condition is greater than or equal to the concurrency in the container performance index information, the response duration in the test result data is less than or equal to the response duration in the container performance index information, and the test resultThe response success rate in the effect data is higher than or equal to the response success rate in the container performance index. And, the higher the configuration information is, the more resources are required, otherwise, the less resources are required, correspondingly, min (md) represents that all the requirements Mx are satisfied>In the relationship model of Yx, the lowest configuration information, i.e., a set of CPUs and memories with the lowest configuration.
It should be noted here that, in practice, there may be a plurality of sets of relational models satisfying the above calculation formula of the optimal relational model, and the general case is as follows: in multiple pressure tests aiming at the same lower configured container resource, the concurrency condition, the response time length and the response success rate of at least two pressure tests all meet Mx > Yx. Aiming at the situation, one relation model with the highest concurrency number, the shortest response time and/or the highest response success rate is selected from a plurality of groups of relation models meeting the optimal relation model formula to serve as the optimal relation model, so that the uniqueness of the optimal relation model is ensured, and the subsequent calculation of the quantity of container resources is facilitated.
Step S250: calculating the concurrency number of the services per second according to the call quantity of the services per second, the average response time and the importance degree information of the system; and calculating the quantity of the required container resources according to the ratio of the concurrency number of the services per second to the concurrency number condition in the optimal relation model.
The system requirement information further includes a traffic call per second (QPS), an average response time, and importance information of the system, which are different from the container performance index information in the foregoing in terms of the target objects, and are requirements for the whole system, and the container performance index information is a requirement for a single container.
The optimal relationship model obtained in the foregoing is only related information of a single container, and when the requirement of the container resource is determined, the quantity of the container resource needs to be further determined. Specifically, a concurrency number calculation formula of the service per second is set as follows: PV is QPS k RTT F, where PV represents the number of concurrent services per second, QPS represents the amount of traffic calls per second, k represents the duty ratio of the peak time period of the traffic calls, k may be generally set to 80%, RTT represents the average response time, and F represents the redundancy reservation of future traffic development of the system, and F represents the increase of the traffic during the service life of the system, for example, the initial traffic is 1000, and the traffic will increase by 50% within 5 years of the system use, and F may be set to 150%.
Further, using the above formula, the resulting PV value, i.e., the number of concurrencies per second of traffic, is calculated, which reflects the number of concurrencies required by the system. And the concurrency condition in the test condition of the optimal relationship model refers to the maximum concurrency which can be borne by a single container, and the number of the required container resources can be obtained by calculating the ratio of the PV to the concurrency number in the optimal relationship model.
According to the method for determining the requirement of the container resource, the pressure test is carried out through the automatic simulation of the actual service, the high matching with the actual requirement is realized, the performance judgment of the application container is more accurate, the whole process is highly automatic, the resource calculation efficiency is obviously improved, the dependence on human experience is greatly reduced, the energy input of professionals is reduced, and a large amount of manpower is saved; and the method can be generally applied to various system frameworks, is not limited to a special system framework any more, and enables the application range of the proposal to be wider.
Fig. 6 is a schematic structural diagram illustrating a demand determination apparatus for container resources according to an embodiment of the present invention. As shown in fig. 6, the apparatus includes:
the client module 610 is adapted to receive system requirement information input by a user; the system requirement information comprises environment configuration information and container performance index information;
the pressure testing module 620 is suitable for deploying container resources with various configurations according to the environment configuration information; utilizing various configured container resource bearing systems to operate and simulate service calling for pressure testing, and acquiring test result data;
the resource calculation module 630 is adapted to construct a plurality of relationship models of the pressure test corresponding to a plurality of configurations, where each relationship model includes configuration information of the container resource, a pressure test condition, and test result data; and calculating an optimal relation model according to the container performance index information and the multiple relation models, and converting the optimal relation model into resource information.
In an optional manner, the pressure testing module further comprises: the application deployment unit is suitable for deploying a plurality of groups of container resources with CPU specifications and memory specifications according to the environment configuration information;
the pressure testing unit is suitable for running by utilizing each group of container resource bearing systems with CPU specifications and memory specifications and simulating service calling to perform pressure testing;
and the result acquisition unit is suitable for stimulating the test result data.
In an optional manner, the system requirement information further includes: code packets and service messages of the system;
the application deployment module is further adapted to: generating a plurality of mirror image files irrelevant to the application according to the plurality of groups of CPU specifications and memory specifications; fusing the mirror image file, the pressure testing tool and the code packet to generate a container mirror image; running a container resource based on the container image;
the pressure testing module is further adapted to: and generating a test case according to the service message for performing pressure test on the container resource.
In an alternative mode, the pressure test condition comprises a concurrency condition and/or a test time condition; and the test result data comprises response duration and/or response success rate.
In an optional manner, the resource calculation module further comprises: a relational model unit adapted to: calculating an optimal relation model, wherein a calculation formula of the optimal relation model is as follows:
Figure BDA0002601219480000111
in the formula, M is an optimal relationship model, Yx represents container performance index information, Mx is information corresponding to the container performance index information in the pressure test condition and test result data, and Md represents configuration information of container resources.
In an optional manner, the system requirement information further includes a service call amount per second, an average response time, and importance information of the system;
the resource calculation module further comprises: the resource conversion unit is suitable for calculating the concurrency number of the services per second according to the service call quantity per second, the average response time and the importance degree information of the system;
and calculating the quantity of the required container resources according to the ratio of the concurrency number of the services per second to the concurrency number condition in the optimal relation model.
In an optional manner, the resource scaling unit is further adapted to: calculating the concurrency number of the services per second, wherein the concurrency number calculation formula of the services per second is as follows: PV is QPS k/RTT F,
where PV denotes the number of concurrencies per second of traffic, QPS denotes the amount of traffic calls per second, k denotes the duty cycle of the peak time period of traffic calls, RTT denotes the average response time, and F denotes the future traffic development redundancy reservation of the system.
An embodiment of the present invention provides a non-volatile computer storage medium, where at least one executable instruction is stored in the computer storage medium, and the computer executable instruction may execute the method for determining the requirement of the container resource in any of the above method embodiments.
Fig. 7 is a schematic structural diagram of a server according to an embodiment of the present invention, and the specific embodiment of the present invention does not limit the specific implementation of the server.
As shown in fig. 7, the server may include: a processor (processor)702, a Communications Interface 704, a memory 706, and a communication bus 708.
Wherein: the processor 702, communication interface 704, and memory 706 communicate with each other via a communication bus 708. A communication interface 704 for communicating with network elements of other devices, such as clients or other servers. The processor 702 is configured to execute the program 710, and may specifically execute relevant steps in the above-described method for determining a requirement of a container resource of a server.
In particular, the program 710 may include program code that includes computer operating instructions.
The processor 702 may be a central processing unit CPU, or an Application Specific Integrated Circuit (ASIC), or one or more Integrated circuits configured to implement an embodiment of the present invention. The server comprises one or more processors, which can be the same type of processor, such as one or more CPUs; or may be different types of processors such as one or more CPUs and one or more ASICs.
The memory 706 stores a program 710. The memory 706 may comprise high-speed RAM memory, and may also include non-volatile memory (non-volatile memory), such as at least one disk memory.
The program 710 may specifically be used to cause the processor 702 to perform the following operations:
receiving system requirement information input by a user; the system requirement information comprises environment configuration information and container performance index information;
deploying container resources of various configurations according to the environment configuration information; utilizing various configured container resource bearing systems to operate and simulate service calling for pressure testing, and acquiring test result data;
constructing a plurality of relation models of pressure tests corresponding to a plurality of configurations, wherein each relation model comprises configuration information of container resources, pressure test conditions and test result data;
and calculating an optimal relation model according to the container performance index information and the multiple relation models, and converting the optimal relation model into resource information.
In an optional manner, the program 710 further causes the processor 702 to:
deploying a plurality of groups of container resources with CPU specifications and memory specifications according to the environment configuration information;
and (4) operating and simulating service call by utilizing each group of container resource bearing systems with CPU specifications and memory specifications to perform pressure test, and acquiring test result data.
In an optional manner, the system requirement information further includes: code packets and service messages of the system;
the program 710 further causes the processor 702 to:
generating a plurality of mirror image files irrelevant to the application according to the plurality of groups of CPU specifications and memory specifications;
fusing the mirror image file, the pressure testing tool and the code packet to generate a container mirror image; running a container resource based on the container image;
and generating a test case according to the service message for carrying out pressure test on the container resource and acquiring test result data.
In an alternative mode, the pressure test condition comprises a concurrency condition and/or a test time condition; and the test result data comprises response duration and/or response success rate.
In an optional manner, the program 710 further causes the processor 702 to:
the calculation formula of the optimal relationship model is as follows:
Figure BDA0002601219480000131
in the formula, M is an optimal relationship model, Yx represents container performance index information, Mx is information corresponding to the container performance index information in the pressure test condition and test result data, and Md represents configuration information of container resources.
In an optional manner, the system requirement information further includes a service call amount per second, an average response time, and importance information of the system;
the program 710 further causes the processor 702 to: calculating the concurrency number of the services per second according to the call quantity of the services per second, the average response time and the importance degree information of the system;
and calculating the quantity of the required container resources according to the ratio of the concurrency number of the services per second to the concurrency number condition in the optimal relation model.
In an optional manner, the program 710 further causes the processor 702 to:
the concurrency number calculation formula of each second of service is as follows: PV is QPS k/RTT F,
where PV denotes the number of concurrencies per second of traffic, QPS denotes the amount of traffic calls per second, k denotes the duty cycle of the peak time period of traffic calls, RTT denotes the average response time, and F denotes the future traffic development redundancy reservation of the system.
The algorithms or displays presented herein are not inherently related to any particular computer, virtual system, or other apparatus. Various general purpose systems may also be used with the teachings herein. The required structure for constructing such a system will be apparent from the description above. In addition, embodiments of the present invention are not directed to any particular programming language. It is appreciated that a variety of programming languages may be used to implement the teachings of embodiments of the present invention as described herein, and any descriptions of specific languages are provided above to disclose the best modes of embodiments of the invention.
In the description provided herein, numerous specific details are set forth. It is understood, however, that embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures and techniques have not been shown in detail in order not to obscure an understanding of this description.
Similarly, it should be appreciated that in the foregoing description of exemplary embodiments of the invention, various features of the embodiments of the invention are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various inventive aspects. However, the disclosed method should not be interpreted as reflecting an intention that: that is, the claimed embodiments of the invention require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the claims following the detailed description are hereby expressly incorporated into this detailed description, with each claim standing on its own as a separate embodiment of this invention.
Those skilled in the art will appreciate that the modules in the device in an embodiment may be adaptively changed and disposed in one or more devices different from the embodiment. The modules or units or components of the embodiments may be combined into one module or unit or component, and furthermore they may be divided into a plurality of sub-modules or sub-units or sub-components. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and all of the processes or elements of any method or apparatus so disclosed, may be combined in any combination, except combinations where at least some of such features and/or processes or elements are mutually exclusive. Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise.
Furthermore, those skilled in the art will appreciate that while some embodiments herein include some features included in other embodiments, rather than other features, combinations of features of different embodiments are meant to be within the scope of the invention and form different embodiments. For example, in the following claims, any of the claimed embodiments may be used in any combination.
The various component embodiments of the invention may be implemented in hardware, or in software modules running on one or more processors, or in a combination thereof. Those skilled in the art will appreciate that a microprocessor or Digital Signal Processor (DSP) may be used in practice to implement some or all of the functionality of some or all of the components according to embodiments of the present invention. Embodiments of the invention may also be implemented as apparatus or device programs (e.g., computer programs and computer program products) for performing a portion or all of the methods described herein. Such programs implementing embodiments of the present invention may be stored on computer-readable media or may be in the form of one or more signals. Such a signal may be downloaded from an internet website or provided on a carrier signal or in any other form.
It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word "comprising" does not exclude the presence of elements or steps not listed in a claim. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. Embodiments of the invention may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by one and the same item of hardware. The usage of the words first, second and third, etcetera do not indicate any ordering. These words may be interpreted as names. The steps in the above embodiments should not be construed as limiting the order of execution unless specified otherwise.

Claims (10)

1. A method for demand determination of container resources, comprising:
receiving system requirement information input by a user; the system requirement information comprises environment configuration information and container performance index information;
deploying container resources of various configurations according to the environment configuration information; utilizing various configured container resource bearing systems to operate and simulate service calling for pressure testing, and acquiring test result data;
constructing a plurality of relation models of pressure tests corresponding to a plurality of configurations, wherein each relation model comprises configuration information of container resources, pressure test conditions and test result data;
and calculating an optimal relation model according to the container performance index information and the multiple relation models, and converting the optimal relation model into resource information.
2. The method of claim 1, wherein said deploying container resources of a plurality of configurations in accordance with said environmental configuration information further comprises:
deploying a plurality of groups of container resources with CPU specifications and memory specifications according to the environment configuration information;
the operation and simulation of service invocation by using the container resource bearing systems with various configurations to perform the pressure test specifically comprises the following steps:
and (4) operating and simulating service call by utilizing each group of container resource bearing systems with CPU specifications and memory specifications to perform pressure test, and acquiring test result data.
3. The method of claim 2, wherein the system requirement information further comprises: code packets and service messages of the system;
after the deploying the plurality of sets of container resources of the CPU specification and the memory specification according to the environment configuration information, the method further includes:
generating a plurality of mirror image files irrelevant to the application according to the plurality of groups of CPU specifications and memory specifications;
the operating and simulating service call for pressure test by using the container resource bearing systems with various groups of CPU specifications and memory specifications further comprises the following steps:
fusing the mirror image file, the pressure testing tool and the code packet to generate a container mirror image; running a container resource based on the container image;
and generating a test case according to the service message for carrying out pressure test on the container resource and acquiring test result data.
4. The method of any one of claims 1-3, wherein the stress test conditions include concurrency conditions and/or test time conditions; and the test result data comprises response duration and/or response success rate.
5. The method of claim 4, wherein said computing an optimal relationship model from the container performance indicator information and a plurality of relationship models further comprises:
optimum relation model meterThe calculation formula is as follows:
Figure FDA0002601219470000021
in the formula, M is an optimal relationship model, Yx represents container performance index information, Mx is information corresponding to the container performance index information in the pressure test condition and test result data, and Md represents configuration information of container resources.
6. The method of claim 5, wherein the system demand information further includes traffic volume per second, average response time, and system importance information;
the method further comprises the following steps: calculating the concurrency number of the services per second according to the call quantity of the services per second, the average response time and the importance degree information of the system;
the converting the optimal relationship model into resource information further comprises: and calculating the quantity of the required container resources according to the ratio of the concurrency number of the services per second to the concurrency number condition in the optimal relation model.
7. The method of claim 6, wherein the calculating the concurrency number of traffic per second according to the traffic call per second, the average response time, and the system importance information further comprises:
the concurrency number calculation formula of each second of service is as follows: PV is QPS k/RTT F,
where PV denotes the number of concurrencies per second of traffic, QPS denotes the amount of traffic calls per second, k denotes the duty cycle of the peak time period of traffic calls, RTT denotes the average response time, and F denotes the future traffic development redundancy reservation of the system.
8. A demand determination apparatus for container resources, comprising:
the client module is suitable for receiving system requirement information input by a user; the system requirement information comprises environment configuration information and container performance index information;
the pressure testing module is suitable for deploying container resources with various configurations according to the environment configuration information; utilizing various configured container resource bearing systems to operate and simulate service calling for pressure testing, and acquiring test result data;
the resource calculation module is suitable for constructing a plurality of relation models of pressure tests corresponding to a plurality of configurations, wherein each relation model comprises configuration information of container resources, pressure test conditions and test result data; and calculating an optimal relation model according to the container performance index information and the multiple relation models, and converting the optimal relation model into resource information.
9. A server, comprising: the system comprises a processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface complete mutual communication through the communication bus;
the memory is used for storing at least one executable instruction, and the executable instruction causes the processor to execute the operation corresponding to the demand determination method of the container resource according to any one of claims 1-7.
10. A computer storage medium having stored therein at least one executable instruction for causing a processor to perform operations corresponding to the method for demand determination of container resources according to any of claims 1-7.
CN202010724633.2A 2020-07-24 2020-07-24 Method and device for determining demand of container resource, server and storage medium Pending CN113971115A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010724633.2A CN113971115A (en) 2020-07-24 2020-07-24 Method and device for determining demand of container resource, server and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010724633.2A CN113971115A (en) 2020-07-24 2020-07-24 Method and device for determining demand of container resource, server and storage medium

Publications (1)

Publication Number Publication Date
CN113971115A true CN113971115A (en) 2022-01-25

Family

ID=79585640

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010724633.2A Pending CN113971115A (en) 2020-07-24 2020-07-24 Method and device for determining demand of container resource, server and storage medium

Country Status (1)

Country Link
CN (1) CN113971115A (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116627893A (en) * 2023-07-18 2023-08-22 苏州浪潮智能科技有限公司 Acceleration engine configuration method, device, parallel number estimation system, device and medium

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116627893A (en) * 2023-07-18 2023-08-22 苏州浪潮智能科技有限公司 Acceleration engine configuration method, device, parallel number estimation system, device and medium
CN116627893B (en) * 2023-07-18 2023-11-03 苏州浪潮智能科技有限公司 Acceleration engine configuration method, device, parallel number estimation system, device and medium

Similar Documents

Publication Publication Date Title
CN111431758B (en) Cloud network equipment testing method and device, storage medium and computer equipment
CN110046174B (en) population migration analysis method and system based on big data
CN108600399A (en) Information-pushing method and Related product
CN112764920A (en) Edge application deployment method, device, equipment and storage medium
CN109240814A (en) A kind of deep learning intelligent dispatching method and system based on TensorFlow
CN114614989A (en) Feasibility verification method and device of network service based on digital twin technology
CN114666335B (en) Distributed system load balancing device based on data distribution service DDS
CN109002364A (en) Optimization method, electronic device and the readable storage medium storing program for executing of interprocess communication
CN113971115A (en) Method and device for determining demand of container resource, server and storage medium
CN112202584A (en) Alarm correlation method, device, computing equipment and computer storage medium
CN112822044B (en) Distributed cluster deployment method and device, electronic equipment and readable storage medium
CN113541986B (en) Fault prediction method and device for 5G slice and computing equipment
CN106961490A (en) A kind of resource monitoring method and system, a kind of home server
CN116700920A (en) Cloud primary hybrid deployment cluster resource scheduling method and device
CN113630786B (en) Network data traffic prediction method, device, computing equipment and storage medium
CN112218334A (en) Dynamic optimization method and device for core network load and computing equipment
CN115309520A (en) Task migration method and device, electronic equipment and storage medium
CN115334001A (en) Data resource scheduling method and device based on priority relation
CN112003900B (en) Method and system for realizing high service availability under high-load scene in distributed system
CN111092755B (en) Edge service migration simulation method based on resource occupation
CN114253710A (en) Processing method of computing request, intelligent terminal, cloud server, equipment and medium
CN109218371A (en) A kind of method and apparatus calling data
CN113949633A (en) 5G network slice disaster recovery pool resource management method and device based on machine learning
CN113822454A (en) Prediction method and device for slice complaint processing resources
EP4170974A1 (en) Slice service processing method and apparatus, network device, and readable storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination