FR3037417A1 - METHOD AND SYSTEM FOR DETERMINING TARGET SERVER CONFIGURATION FOR DEPLOYING SOFTWARE APPLICATION - Google Patents

Abstract

The method comprises: obtaining (E20) for at least one service offered by the application, via at least one unit test performed on a reference server configuration, an average execution time of a query invoking this service for each server; selecting (E60) an initial server configuration supporting a target load, taking into account the times obtained, the target load and an allowable load of the reference configuration, and using a digital model reflecting at least an application deployment constraint on the initial configuration; and - determining (E90) from the initial configuration of a target configuration via load-holding tests (E80) parameterized according to a maximum load of the initial configuration and the target load, and using a a request profile invoking said at least one service representative of a use of the deployed application, the determination comprising, according to the result of each test, a resource adjustment (s) of the initial configuration to obtain at the end tests a target configuration that checks for maximum response time and target load.

Description

BACKGROUND OF THE INVENTION The invention relates to the general field of software applications. It concerns more particularly the sizing of the resources allowing the execution of such applications. The invention thus applies in a preferred but nonlimiting manner when software applications are deployed in a cloud computing system also more commonly known as "cloud" in English. The management of the elasticity of the software applications deployed in the cloud is an important problem, especially in the "PaaS" (platform as a service) type systems. These systems, primarily intended for businesses, aim to provide technical services that facilitate the construction, implementation and administration of software applications to refocus the attention of users on their applications. The purpose of a PaaS system is to hide the complexity of instantiating and exploiting applications. For this, the PaaS system offers technical bricks, accessible through high-level interfaces via a telecommunications network, to support a large panel of services related to the administration of applications, including dynamic adaptation to Load variations, dependability and safety. The functional perimeter of these bricks generally corresponds to that filled by middleware (eg HTTP server, application server, database, script interpreters, various software frameworks, etc.), ie operations that can be shared over several applications. In this context, the purpose of managing the elasticity of software applications deployed in the cloud is to provide and adjust (ie adapt) the resources necessary for the proper functioning of these software applications, in particular in terms of volumetry, availability, response time and reliability, while satisfying the constraints specific to these software applications (eg cost, placement of virtual machines, right of use, etc.). In order to optimize a quality / cost ratio, the elasticity management must: allow to determine (ie size) the resources necessary for the deployment of a software application as well as the optimal configuration of these resources, in particular according to contractualized requirements (eg in the form of service level agreement or SLA for "Service Level Agreement" in English) and resources committed to other software applications currently being implemented; and being able to dynamically add or delete resources during the execution of the software application, in particular in order to absorb occasional (instantaneous) "bursts" of requests due to peaks in the use of the software application or sharing the runtime environment with other software applications, and thus comply with contractual requirements in the SLAs (eg in terms of software application 3037417 2 response time). To do this, the elasticity management must be able to quickly determine the new resource configuration and specify when the reconfiguration operation should occur. Resource sizing techniques are therefore at the heart of the management of elasticity. They generally require a good knowledge of the software application, especially in terms of resource consumption by the application deployment instances (eg servers), but also user request profiles (eg distribution by service, data rates, queries, inter-arrival times between requests, etc.). In the present state of the art, there is no known structured method for easily determining the resources required (as well as the configuration of these resources) for the deployment or execution of a software application. Indeed, today we only dimension and adjust experimentally with test tools and / or supervision the resources needed to run a software application from a pre-metrology study. This way of proceeding involves a very important investment in terms of cost and time: many configurations must be tested before finding an optimal configuration, requiring the installation of physical equipment and software, the execution of numerous tests etc. Such an approach is therefore not always feasible in practice due to time constraints imposed on the deployment of the software application for example or constraints imposed in terms of return on investment.

OBJECT AND SUMMARY OF THE INVENTION The invention makes it possible to remedy this disadvantage by proposing a method for determining a so-called target server configuration for a deployment of a software application capable of offering at least one service, this method comprising: a step of obtaining, for at least one service offered by the software application, by means of at least one unit test performed on a so-called reference server configuration capable of executing the software application, of a the average execution time of a request invoking this service for each server in the reference configuration; a step of selecting a so-called initial server configuration for the deployment of the software application able to support a target load determined for the software application, this selection step taking into account the average execution times obtained during said minus one unit test, the target load and a specified load determined for the reference configuration, and using a numerical model reflecting at least one deployment constraint of the software application imposed on the initial server configuration; and a step of determining, from the initial configuration, a target server configuration for use in the deployment of the software application, said determining step comprising performing a plurality of holding tests. load 3037417 3 based on a theoretical maximum load estimated for the initial configuration and the target load, and using at least one request profile invoking said at least one service offered by the software application, this profile being representative of use of the software application during its deployment, said determining step further comprising, depending on the result of each load-holding test, adjusting at least one resource from the initial configuration so that the configuration target obtained after said plurality of load-bearing tests is able to verify a maximum response time set for the software application and to support said target load. Correlatively, the invention also aims at a system for determining a target configuration for a deployment of a software application, the system comprising: a first test tool allowing the execution of at least one unit test on the application software when it is executed on a so-called reference server configuration; a obtaining module, configured to control the execution of at least one unit test by the first test tool on said reference configuration and to obtain, for at least one service offered by the software application, a time average execution of a request invoking this service for each server in the reference configuration; a selection module, configured to select an initial server configuration for the deployment of the software application capable of supporting a determined target load for the software application, said selection module being configured to take account of the execution times means obtained during said at least one unit test, the target load and a given load determined for the reference configuration, and to use a numerical model reflecting at least one deployment constraint of the software application imposed on the configuration of the initial servers; a second test tool for performing load-holding tests on said software application when it is executed on the initial server configuration selected by the selection module; and a determination module configured to determine from the initial configuration a target server configuration to be used for the deployment of the software application, said determination module being configured to control the execution of a plurality of tests of the second test tool, said load-carrying tests being parameterized by the determination module according to a theoretical maximum load estimated for the initial configuration and the target load, and using at least one profile of requests invoking said at least one service offered by the software application, this profile being representative of a use of the software application during its deployment, said determination module being further configured to adjust, depending on the result of each load-bearing test, at least one resource from the initial configuration so that the configuration c ible obtained at the end of said plurality of load-bearing tests is able to verify a fixed maximum response time for the software application and to support said target load. By server, here means any type of physical or virtual machine, able to execute all or part of an instance of the software application. The software application is intended to be deployed on a configuration (ie an arrangement) of servers formed of one or more servers connected to each other and verifying imposed deployment constraints for the production of the software application (ex. multi-site deployment, use of specific machines, etc.). The invention thus proposes a method of sizing the resources necessary for deploying a software application in a production environment that relies on the structured execution of two types of tests, namely unit tests without concurrent access to resources. then load-bearing tests, judiciously parameterized. These different tests are carried out on different server configurations, namely: for unit tests, on a so-called reference, predetermined and relatively simple configuration of servers, which makes it possible to obtain results in terms of resource consumption ; and - for load-holding tests, on a configuration of so-called initial production servers whose architecture reflects the constraints imposed by the deployment of the software application in a production environment, and selected through the exploitation of the results of the unit tests performed on the reference configuration combined with a numerical model for mapping the resources of the two server configurations. The invention thus makes it possible to simply and efficiently determine a target production configuration adapted in terms of resources to the deployment of the software application in a real execution environment and verifying the different contractual requirements imposed on it by the intermediate example of an SLA agreement as previously described. This target configuration is obtained by iteratively adjusting the resources of the initial configuration at the end of each load-holding test so as to verify these requirements. The resource adjustment of a server configuration includes, within the meaning of the invention, the maintenance, addition, and / or removal of resources for at least one server of the configuration, and / or the maintenance or updating parameters of this configuration (such as the number of servers considered in this configuration). This adjustment leads to an "optimal" production configuration, that is to say a minimum configuration of servers, to ensure compliance with the requirements set for the software application in terms of volumetry (ie target load), the end-to-end availability and response time of the software application to user requests. As previously mentioned, the configuration of reference servers used to perform the unit tests is generally chosen to be relatively small in complexity compared to the server configuration on which the software application is intended to be actually deployed. This reference server configuration can typically be limited to a single machine (i.e. a single server), for example the machine on which the application is developed. The unit tests carried out from this reference configuration aim to characterize, for each type of request identified as relevant to the services offered by the software application (eg subscription type requests, termination, multimedia object consultations, processing , etc.), the resources consumed by it on each server of the reference configuration to process this type of request when there is no concurrent access to these resources. In other words, this is to quantify the use at each server of the reference configuration of the processors (or central processing units or CPU 10 for "Central Processing Unit" in English), memory (ex. disk, RAM (Random Access Memory)) and / or network resources (eg network connectors) requested during the processing of requests. Such unit tests are known per se and are conventionally implemented during the development and debugging of software applications. During these tests, it is ensured that there is no concurrent access to the resources whose consumption is to be quantified in order to process the requests sent to the software application. For this purpose, the requests can be for example sent one by one to the software application executed by the reference configuration (a request being sent at the end of the processing of the previous one), or N requests (N integer) can be sent deterministically to the software application by ensuring that there is no concurrent access to the resources used for their processing. The invention proposes to take advantage of these simple unit tests to be carried out to collect various resource consumption metrics related to the intrinsic processing of each request by each server of the reference configuration, and more particularly for each representative service offered by the application. software, to obtain the average execution time of a request invoking this service by each server of the reference configuration. Other metrics can of course be obtained during these unit tests, such as for example the number of network connectors used simultaneously, the amount of RAM used on each server, the duration and volume of disk occupied, the time elapsing between the completion of the query on a server and the start of execution on the next server, etc. The metrics thus harvested serve as inputs, according to the invention, to numerical models reflecting various requirements imposed in terms of architecture in particular or types of machines to the production configuration (ie various constraints software application deployment) and are exploited to select an initial production configuration satisfying a target volume (load in terms of request rates) set for the software application. The 35 digital models considered for example model the constraints (requirements) deployment of the software application from at least one queue or a network of queues.

It should be noted that the selection of the initial production configuration is based on unit test results conducted in an ideal runtime environment where queries are not competing for access to resources. The unit tests therefore make it possible to determine only what are the needs of the software application in 5 CPU, memory and / or network resources to intrinsically process each request. The initial production configuration selected in accordance with the invention therefore only takes into account a volumetric to be respected and the intrinsic execution time of the queries resulting therefrom. However, these hypotheses are not representative of the actual conditions of use of the software application in which the queries of the users generally arrive in a non-deterministic manner, typically in bursts and with rates sometimes very different from the average throughput of the requests. Unit tests therefore do not provide information on the actual response time of the software application in a production environment, so that a resource adjustment of the initial production configuration selected at the end of the unit tests is proposed by the invention to take account of the requirements imposed on the software application in terms in particular of maximum end-to-end response time. These adjustments are framed by load control tests duly parameterized and which allow to size the resources necessary for the production of the software application. These load-bearing tests indeed take into account not only the constraints in terms of volumetry of the software application, but also the profile of the 20 requests invoking the services offered by it, and in particular the nature of the interfering times. - arrivals of the requests (ie the arrival distribution of these requests at the level of the software application). Thus, a request profile invoking a service includes, for example, for at least a specified period of time of a software application activity cycle or a software application activity cycle: average of the requests invoking this service over the said period of time; a proportion of requests invoking this service among the requests invoking services offered by the software application; and a distribution of inter-arrival times between two requests invoking this service over said period of time.

In other words, the load-bearing tests take into account a realistic request profile representative of the use of the software application in a real execution environment (ie similar or at least close to the one at which one expected when the software application goes into production). It should be noted that the initial production configuration selected by the invention is not necessarily strictly in accordance with the server configuration that will be deployed later in production and tested in a real execution environment. It may in particular be of smaller complexity, but it is selected preferentially so as to be representative of the various functionalities and problems expected during the production of the software application. Thus, the initial server configuration is preferably chosen so as to be representative of the software, technical and functional complexity of the production environment of the software application (eg the presence of a master node and several secondary nodes that communicate between them, modeling of inter-site communication, taking into account security problems, etc.). In this way, it is ensured that the sizing of the resources achieved by the invention is relevant and exploitable to facilitate the deployment of the application in production and limit large-scale tests. Several target server configurations can be identified from the invention. The selection of one of these configurations can then be made from experimental tests carried out in the production environment. However the number of server configurations to be tested is considerably reduced compared to the state of the art. The invention thus differs from the state of the art in that it offers a solution which makes it possible, before the software application is put into production, to preselect and size, by means of numerical models, a or several appropriate server configurations that serve as starting points for the actual deployment of the application. Thus, contrary to the state of the art, the selection of the optimal configuration is not based solely on experimental tests carried out in production in a real execution environment and which may prove, as mentioned above, to be hazardous, expensive and 20 time-consuming. On the contrary, the invention offers the possibility of pre-provisioning the resources required to execute a software application, which makes it possible to perform such experimental tests only on a small number of configurations in order to select an optimal configuration. This gives the invention a substantial gain in complexity and time.

The invention therefore makes it possible, in comparison with existing solutions based essentially on experimental observations, to ensure the control and efficiency of the elasticity management, and to reduce the investment costs for software applications and applications. PaaS type systems. It should also be noted that, advantageously, the implementation of the invention does not require detailed knowledge of the software components constituting the software application nor of the sequence of execution of these components. The software application can advantageously be considered as a "black box" offering one or more services in response to user requests verifying a certain profile, and distributed or instantiated on one or more servers. The resource consumption metrics from the unit tests and then used to select an initial server configuration on which load tests are performed are all-component metrics measured on each server of the reference configuration.

In a particular embodiment of the invention, the determination method further comprises a step of estimating a theoretical maximum load for the reference configuration and the allowable load determined for the reference configuration results from the product of FIG. a parameter is between 0 and 1 by the theoretical maximum load estimated for the reference configuration. For example, the theoretical maximum load for the reference configuration is estimated by applying a stability condition of the software application to at least one average execution time of a request of the derived software application for said at least one server of the reference configuration from the average execution times obtained for this server for the services offered by the software application. Such a stability condition is verified in particular if for each server of the server configuration considered for executing the software application, the rate (flow) of arrival of the requests is strictly lower than the utilization rate of this server. The response time of the server can be used to evaluate its utilization rate. This stability condition makes it possible to easily evaluate a theoretical maximum load for the software application in the vicinity of which the software application is no longer able to process the requests. This theoretical maximum load is used to size the initial server configuration. Furthermore, the inventors have observed that upstream of this maximum theoretical load, the average response time of a server as a function of the load of the software application generally follows a first linear slow-slope regime followed by a brutal rise defining a second linear regime at the approach of server saturation. The parameter between 0 and 1 used to define the allowable load of the initial configuration is preferably chosen so that the load considered is in a transition zone just before the second linear regime and in which the response time of The end-to-end of the software application remains below a maximum response time set for the software application (typically in the SLA agreement). In this "optimal" zone, the response time versus the load is contained and remains below the maximum response time allowed for the software application. Note that the value of the parameter a may depend on the distribution of the inter-arrival times of the requests, as detailed later. However, a value of 0.8 or 0.85 (or around these two values) is generally well enough to implement the invention. In a particular embodiment, during the determination step, the adjustment of at least one resource of the initial configuration after a load-holding test is performed according to a difference between a response time of the software application 35 evaluated during the load withstand test and the maximum response time set for the software application. This way of adjusting the resources by taking into account the maximum response time set for the software application and the end-to-end response time with the server configuration being tested allows for quick convergence to appropriate sizing. Resource. In one embodiment, the determining step comprises at least: a first load bearing test performed with a first load less than a minimum value between one half of the theoretical maximum load estimated for the initial configuration and the product of the target load by a predetermined real number less than or equal to 1; a second load holding test performed with a second load lower than the first load; and a third charge hold test performed with a third charge equal to the target charge.

This protocol makes it possible to limit the load-bearing tests performed on the initial server configuration and to quickly reach a target server configuration derived from the initial configuration. By configuration derived from the initial configuration is meant in the sense of the invention that the configuration is the same as the initial configuration if it is considered correctly sized or it is obtained after adjusting the resources of the initial configuration . In this embodiment, the determination step may furthermore comprise an estimate at the end of the second test, of a response time of the software application with the target load from a response time evaluated at the result of the first test performed with the first load on a tested configuration derived from the initial server configuration and a response time of the evaluated software application at the end of the second test performed with the second load on said tested configuration, the resource adjustment being performed after the second test based on a difference between the estimated response time for the target load and the maximum response time set for the software application. Typically, at the end of the second test: the tested server configuration may be considered undersized if the estimated response time for the target load is greater than the maximum response time; and / or the tested server configuration may be considered oversized if the estimated response time for the target load is less than the product of a predetermined real number of between 0 and 1 and the maximum response time, for example 0.9; and / or the tested server configuration may be considered correctly sized otherwise. The resource adjustment is then carried out accordingly and the one or more previous load-holding tests are repeated on the adjusted configuration to validate this adjustment and / or to make a new adjustment, until the suitable target configuration is determined. to be deployed and that meets the requirements set for the release of the software application in terms of load and end-to-end response time. Typically, the target configuration corresponds to a tested server configuration for which, after the third test, a response time of the evaluated software application for the target load on that tested server configuration is less than the response time. maximum. In a particular embodiment of the invention, the determination method further comprises a step of validating the target configuration by means of an endurance test performed during a predetermined execution time of the software application. It is this endurance test to test the software application and target server configuration determined unit tests and load-bearing tests over a sufficiently long period to take into account, for the unfinancing of resources, rare events whose probability of occurrence is relatively low. The result of this endurance test makes it possible to readjust, if necessary, the resources of the target configuration with a view to the deployment of the software application. Indeed, the metrics and numerical models used in accordance with the invention to determine the target configuration are based on certain abstraction assumptions on the behavior of the software application, including independence of certain components or distribution of requests. The endurance test 15 makes it possible to refine these models (and if necessary to adjust the size of the resources), and to a certain extent, to reveal the differences between the reality and the numerical models used, to evaluate them. and to judge their relevance. In a particular embodiment, the software application is characterized by an activity cycle comprising a plurality of intervals, each interval being associated with a mean arrival rate of requests representing this interval, and wherein said steps for obtaining, selecting and determining are implemented for at least one interval of said plurality of intervals. This embodiment makes it possible to adapt to the software applications for which there is a dynamic distribution of the requests, in other words for which the rate of the arrivals of service requests varies significantly over time intervals and this in a repetitive manner over the business cycle. In another aspect, the invention is also directed to a resiliency management method of a server configuration capable of executing a software application, which method comprises: a step of determining a target server configuration for the deployment of servers; the software application comprising the execution of a determination method according to the invention; and a step of executing the software application on said server target configuration comprising: monitoring at least one monitoring metric of that target configuration; And o according to said at least one metric, a resource adjustment of the target configuration, which adjustment comprises maintaining and / or adding and / or dynamically removing resources to the target configuration.

The invention also relates to a resiliency management system of a server configuration capable of executing a software application comprising: a system according to the invention for determining a target configuration of servers for the deployment of the application software comprising performing a determination method; A module for triggering an execution of the software application on the target configuration of servers; a module for monitoring at least one supervision metric of this target configuration during the execution of the software application; and an adjustment module configured to adjust the resources allocated to the target configuration according to said at least one metric, said adjustment module being able to maintain the resources allocated or to dynamically add and / or remove resources to the target configuration. The method and the elasticity management system benefit from the same advantages mentioned above as the method and the determination device according to the invention.

In a particular embodiment, the various steps of the determination method and / or the elasticity management method are determined by computer program instructions. Consequently, the invention also relates to a computer program on one or more information medium (s), this program being able to be implemented in a determination system or more generally in a computer, this program comprising instructions adapted to the implementation of the steps of a sizing process as described above. The invention also relates to a computer program on one or more information medium (s), this program being capable of being implemented in an elasticity management system or more generally in a computer, this program comprising instructions adapted to the implementation of the steps of a method of elasticity management as described above. This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any another desirable form. The invention also relates to a computer-readable information medium, comprising instructions of a computer program as mentioned above. The information carrier may be any entity or device capable of storing the program. For example, the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording means, for example a floppy disk or a disk. Hard disk. On the other hand, the information medium may be a transmissible medium such as an electrical or optical signal, which may be routed via an electrical or optical cable, by radio or by other means. The program according to the invention can be downloaded in particular on an Internet type network. Alternatively, the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question. It can also be envisaged, in other embodiments, that the determination method, the elasticity management method, the determination system and the elasticity management system according to the invention present in combination all or some of the aforementioned features.

BRIEF DESCRIPTION OF THE DRAWINGS Other features and advantages of the present invention will be apparent from the description given below, with reference to the accompanying drawings which illustrate an embodiment having no limiting character. In the figures: FIG. 1 schematically represents a determination system according to the invention, in a particular embodiment; FIG. 2 represents a test tool for carrying out load-holding tests on a configuration of reference servers on which a software application is deployed and which can be used as a component of the determination system of FIG. 1; FIGS. 3A and 3B illustrate, for two distinct services of a software application, a cycle of activity of this software application and the distribution of the number of arrival of requests on this activity cycle; FIG. 4 represents, in the form of a flow chart, the main steps of a determination method according to the invention in a particular embodiment in which it is implemented by the determination system of FIG. 1; FIGS. 5A to 5D illustrate the evolution of the response time of a server as a function of the load of the software application, and for different request profiles; FIGS. 6A to 6D illustrate several models of queuing systems that can be used to determine the initial configuration according to the invention; FIG. 7 details, in the form of a flow chart, the main steps implemented by the determination system of FIG. 1 in a particular embodiment of the invention for determining the configuration of target servers from the initial configuration; FIGS. 8A to 8D illustrate different cases leading to an adjustment of the resources of the initial configuration in accordance with the invention; FIG. 9 represents, in the form of a flow chart, the main steps of a method of managing the elasticity according to the invention, in a particular embodiment; and FIG. 10 illustrates the processing implemented in a particular embodiment of the invention when the software application has a periodic activity cycle.

DETAILED DESCRIPTION OF THE INVENTION FIG. 1 represents, in its environment, a system 1 for determining a configuration of machines for the deployment of a software application APP, according to the invention, in a particular embodiment. . The system 1 proposes, through the configuration thus determined (referred to as the target configuration in the following description), a dimension of the resources needed to put the APP software application into production, that is to say its deployment in a real execution environment. No limitation is attached to the nature of the APP software application. It may be an application allowing access to or generation of multimedia content, referencing 10 products, access to remote equipment, etc. This APP software application is able to offer one or more services UC1, UC2, ..., UCN (N integer greater than or equal to 1) to users, upon receipt of requests invoking these services issued by them via terminals (ex. via a mobile terminal, a computer, etc.).

In the example envisaged here, the APP software application is intended to be deployed (ie production) in a cloud or cloud computing system (not shown), on a target configuration of virtual machines (servers) hosted by the cloud. In such a context, the management of the elasticity of resources made available by the cloud for the execution of the software applications that it hosts is very important: the cloud indeed seeks to optimize the sharing of resources common to software applications. It hosts to reduce the cost of their deployment, while ensuring the quality of services offered by these applications to their users. The shared resources can be of different natures: they can be in particular resources of the type processors or CPU of virtual and / or physical machines (servers), of memory resources (eg RAM, disk, etc.), or of 25 network resources (eg network connectors, etc.). The purpose of cloud resilience management is therefore to provide the various software applications with the aforementioned resources required for their execution and to guarantee their proper operation according to an agreed SLA. Each SLA defines constraints specific to the software application to which it refers, in particular in terms of volumetry, availability, response time, reliability but also cost, machine placement (virtual in the context of the cloud). on which are deployed the application, usage rights and subscriptions, etc. In other words, each SLA associated with a software application defines a certain number of requirements that must be respected by the cloud. The role of elasticity management is to determine the resources required to deploy the APP software application in the cloud in order to meet the requirements set by this SLA, while taking into account resources committed for other applications. Software applications hosted by the cloud and running.

In the example envisaged here, the management of the elasticity of the cloud hosting the APP software application is based on the determination system 1. More particularly, it allows an efficient management of the elasticity of the cloud by providing the possibility of pre-provisioning the resources necessary to execute the APP application before it is put into production by determining a configuration adapted to the deployment of the APP application in a real execution environment (also designated by "target" configuration). For this purpose, according to the invention, the determination system 1 is based on different test environments of the APP software application in which the application is deployed on different server configurations, and on different modules (software here) implementing programmed algorithms or calculation models exploiting the results obtained in these test environments. Specifically, in the embodiment described herein, the determination system 1 comprises: an ENV1 test software tool (or environment), constructed to perform unit tests on the APP software application when it is deployed on a first CONFIG1 configuration of so-called reference servers, consisting of a number Ni of servers connected to each other (Ni denoting an integer greater than or equal to 1); an ENV2 test software tool (environment), built to carry out load-bearing tests of the APP software application when it is deployed on a second so-called initial CONFIG2 server configuration, consisting of a number N2 of servers interconnected (N2 designating an integer greater than or equal to 1), and taking into account the deployment constraints of the APP software application when it goes into production; a module 2 for collecting various metrics during unit tests carried out in the ENVI test environment, able to evaluate from these metrics a consumption of the resources by the servers of the configuration CONFIG1 for the processing of requests invoking services offered by the APP software application. More specifically, the module 2 is able to obtain here, from the harvested metrics, an average execution time of a request invoking a service offered by the APP software application for each server of the reference configuration CONFIG1 and for each service offered by the software application 30 APP. It is also configured to estimate from the average execution times obtained, a theoretical maximum load kmaxi that can be supported by the reference configuration CONFIG1; a module 3 for selecting the initial configuration of servers CONFIG2 on which the load-holding tests are carried out via the test environment ENV2 and which serves as a starting point for sizing the resources necessary for the production of the device. APP software application. This configuration CONFIG2 is selected by the module 3 so as to support a determined target load ktarg. To determine the configuration CONFIG2, the module 3 is configured to take into account the average execution times and the theoretical maximum load krnax1 determined by the module 2, and to use a numerical model reflecting the deployment constraints of the module. software application in a real execution environment (eg types of machines used, multi-site deployment, required network connections, etc.). The module 3 is also configured to determine a theoretical maximum load kmax2 for the initial configuration CONFIG2 thus selected; and a module 4 for adjusting the resources and the parameters of the servers of the configuration CONFIG2, configured to determine from the initial configuration CONFIG2 a configuration of target servers designated by CONFIG_TARG for the production of the software application APP. This target configuration is determined by the module 4 by performing several load-holding tests on the initial configuration CONFIG2 by means of the test tool ENV2: the module 4 readjusts if necessary at the end of each of the tests, depending results obtained (in terms of average response time, in particular of the software application on the tested configuration), the resources and the parameters of the servers from the initial configuration CONFIG2 until a configuration is determined which makes it possible to guarantee a response time maximum TRmax set for the APP software application and which supports the ktarg target load. In the embodiment described here, for the sake of simplicity, the reference configuration CONFIG1 consists of a single server (i.e. N1 = 1), for example, the server S11 on which the application APP has been deployed. The generalization of the invention to a more complex reference configuration comprising a plurality of servers interconnected and on which are deployed different deployment units of the APP software application is mentioned later. The ENVi test tool is a test software environment similar to those conventionally built for debugging software applications and known to those skilled in the art. It is therefore not described in detail here. This ENVi environment allows the module 2 to collect various metrics, for each type of request identified as relevant for the services offered by the APP software application, each type of request considered being associated with a single service offered by the application. Thus, in the example envisaged here, the module 2 collects, from the unit tests 30 conducted in the test environment ENVi, a metric representative of the average CPU consumption by the software application APP on the server S11 of the configuration of FIG. reference CONFIG1 for the processing of a request of each type of retained queries, in other words for each service. This metric is defined here as the average execution time of a request for the service envisaged by the server of the reference configuration CONFIG1 (in other words the average processing time of such a request by the server or the time of average server response to such a request). The execution time of a request by a server is defined as the sum of the execution times of the processes of the APP software application (or even of the tasks or threads, more commonly referred to as "threads" in English). associated with the request after / before input / output. As a variant, the module 2 can collect a metric representative of an average CPU utilization rate on the server in question, the CPU utilization rate being defined as the percentage of time during which the processor (s) of the server is (are) active relative to the duration of observation during the processing of the request. This metric can also be evaluated from the average time of execution of a request by the server considered, as detailed later. In the embodiment described here, it is limited to metrics relating to the use of the processor (s) of the servers and the sizing of these processors to determine the target configuration CONFIG_TARG. This resource is indeed the most critical and sensitive when considering a dynamic management of resources in a cloud-type system compared for example to memory. However, this assumption is not limiting and the sizing of other resources can be envisaged thanks to the invention, such as in particular the sizing of memory resources (eg disk, RAM) and / or networks. For this purpose, other metrics can be obtained during unit tests performed in the ENVi test tool such as: a metric representative of the RAM consumption, defined from the volume of RAM used for the processing of the request ; 20 - representative metrics of a disk consumption, defined from the duration and the disk volume occupied during the processing of the request; a metric representative of a network consumption defined as the time elapsing between the completion of the request on a server and the start of execution of the request on the next server (which could be the same server); 25 - etc. The unit tests performed with the ENVi test tool are based on scenarios (ie use cases of the application) of issuing each request after the receipt and processing of the previous request so that there is no concurrent access to resources (CPU here) whose consumption is to be quantified. Each scenario follows from the sequential or parallel running of the functions making up the software application (also referred to as flow or execution graph or "workflow" in English). As a variant, these scenarios may consist in transmitting an integer K of requests in a deterministic or periodic manner if the processing time of a request is not significant, and without concurrent access to the CPU resources.

The queries considered in the scenarios implemented by the test tool ENVi correspond to requests considered as relevant to the services offered by the software application APP. The description of the services offered by the APP software application and the types of requests invoking these services is obtained for example from the administrator and / or the developer of the APP software application, as indicated in more detail later. The unit tests carried out in the ENVi test environment therefore make it possible to quantify a resource consumption at each server of the reference configuration considered for the processing of the requests but without concurrent access to these resources: they therefore do not provide any information. information strictly speaking in terms of server response time in a real execution environment. This response time information, the knowledge of which is used here for sizing the resources of the APP software application production configuration to achieve a given Xtarg target load (i.e., a volumetry imposed on the APP software application), are obtained in a second time thanks to the ENV2 test tool which makes it possible to carry out load tests on another server configuration (ie the initial configuration CONFIG2) built by the module 3 from the Unit 2 test results obtained by the module 2. In the embodiment described here, the initial configuration of servers CONFIG2 is chosen by the module 3 so as to be representative of the various constraints and functionalities expected when the production is started. software application, and in particular the software, technical and functional complexity of the real execution environment of the software application the (also called production environment). Thus, in particular, if a multi-site deployment of the software application is envisaged, the initial CONFIG2 server configuration must comprise a plurality of nodes embodying the "multi-site" component, a central node orchestrating the data conveyed by the application. plurality of nodes, and model the communications between the different nodes on which the software application is based. The initial server configuration may, however, include a reduced number of servers N2 compared to the number of sites on which it is planned to actually deploy the application in order to limit the cost, complexity and time of the tests to be performed. Similarly, if during the production of the software application is considered a firewall type functionality, this feature should be reflected in the initial configuration of servers. The type of machines used (eg mono or multiprocessor, maximum capacity of machines, etc.) can also be a constraint imposed by the production environment and must be reflected in the initial configuration.

These various constraints imposed by the production environment are materialized according to the invention by a numerical model MOD, which relies here on the formalism of queues or queuing networks. Various examples of numerical models are illustrated later. The module 3 then selects the initial configuration CONFIG2 using this numerical model MOD and taking into account, on the one hand, the results of the unit tests carried out on the reference configuration CONFIG1 (and notably the average execution times obtained for each server of the reference configuration for each type of request considered (ie for each service), and the theoretical maximum load) which serve as a reference for sizing the resources of the initial configuration CONFIG2, and on the other hand, the load Xtarg target set for the APP software application (that is, the volume imposed on the APP software application). The initial configuration CONFIG2 selected by the module 3 is therefore a reduced sample of the server configuration on which the software application APP is to be put into production. This initial configuration CONFIG2 is used according to the invention as a starting point by the module 4 of the determination system 1 for sizing the resources required to execute the APP software application in a production environment.

More specifically, the module 4 is configured to perform a resource adjustment of the initial configuration CONFIG2 based on load-holding test results made using the test tool ENV2 to determine a configuration of CONFIG_TARG "target" servers to deploy the APP software application in a production environment. These tests make it possible to evaluate the processing capacity (eg utilization rate of the 15 CPUs or memory, response time, etc.) of the servers of the configuration CONFIG2 on which the software application APP is deployed, for different request rate values (ie different software application loads) with simulated user request flows representative of actual use of the application. For this purpose, the test tool ENV2 takes into account the deployment instances of the software application APP on the servers of the configuration CONFIG2, as well as the topology connecting the instances, of the perimeter of the software application APP by relative to its environment (ie applications or third-party software products, terminals, etc.), communication protocols implemented, etc. It also takes into account the software and hardware characteristics of the configuration CONFIG2, including the setting of physical machines and virtual machines (servers), storage spaces, network aspects, and parameterization of intermediate products (or "middleware" in English) such as application servers, databases, buses and communication protocols, etc. FIG. 2 schematically illustrates an example of such an ENV2ex test environment developed for testing a software application deployed on a server configuration 30 comprising a presentation server 6, an application server 7 and a data server 8. An instance of the software application is installed on the application server 7. In the example illustrated in FIG. 2, HTTP requests (HyperText Transfer Protocol) are sent by a charge injection device 9 to the software application APP for treatment. The servers 6, 7 and 8 are connected to a storage area 10 via the NFS protocol (Network File System). The APP software application interacts with third-party devices, such as for example a server of a shared exchange zone 11 and a rebound server 13, and various external systems 12 and 14 modeled using partner simulators.

In general, in order to carry out load-bearing tests of the APP software application, the test tool ENV2 comprises in particular: modules or devices for injecting charge, able to generate and supply the software application APP different load levels generated by virtual users (each load level corresponding to a number of different virtual users), and measure average or median response times to requests issued by these virtual users. These load injection modules are here CLIF modules based on a fractal component model and described in particular in the document by B. Dillenseger entitled "CLIF, a framework based on Fractal for flexible, distributed load testing", Annals of 10 Telecommunications, Vol. 64, No. 1-2, February 2009; and probes for observing different metrics of resource consumption (CPU, memory, networks, etc.) by the software application on the servers of the tested configuration. The test tool ENV2 is configured to inject, via its charge injection modules, automatically, over a fixed duration and according to a predetermined injection policy described in more detail later, different charge levels (ie different increasing number of requests per unit of time) to the server configuration tested and supporting the APP software application. The ENV2 test tool is programmed for this purpose to observe, after the injection of each load level, the behavior of the tested server configuration, and decide according to this behavior of the next level of charge to be injected. The process is reiterated until a predetermined criterion is reached. Those skilled in the art are invited to refer to the document by N. Salmi et al. "Model-based performance anticipation in multi-tiered autonomic systems: methodology and experiments", International Journal on Advances in Networks and Services, Vol 3 no 3 8 (4, 2010 (http://www.iariajournals.org/networks_and_services/ tocv3n34.html), section III, for more details on the automation of the charge injection process implemented by the ENV2 test tool, but it should be noted that, like the operating mode As described in the document by N. Salmi et al., the test tool ENV2 uses, in accordance with the invention, load injection scenarios based on profiles of user requests representative of the actual use or at least expected from the APP software application in the production environment (or as close as possible) Such profiles can be obtained for example from the developer and / or the administrator of the APP software application. include information queries relating to the frequency of arrival of requests, and more particularly: 35 to the distribution of the different types of requests (i.e. proportion of each type of request); the average arrival rates of the different types of requests associated with the services offered by the APP software application; and - the inter-arrival duration (time) distributions between these requests (eg deterministic or burst type distributions such as for example a random or exponential distribution). Information about minimum and maximum flow rates can also be contained in these profiles. Thus, the queries injected by the ENV2 test tool are no longer systematically spaced deterministically (eg periodically) or sequentially as for the unit tests performed by the ENVI test tool, but "lumps" of queries can occur and lead to concurrent access to shared resources, which can cause a momentary collapse of the APP software application (ie the software application is saturated and unresponsive). In particular, if a bottleneck is formed on a server (corresponding to a peak request rate much higher than the average rate) and persists, the risk of collapse of the software application can become significant and the response time of it to degrade quickly. The behavior observed in terms of response time and consumption of resources of the software application with the aid of this test tool ENV2 can therefore be very different from those which can be observed during unit tests carried out at the same time. help of the ENVI test tool. It is noted that the APP software application can experience reproducible variations of use over a time window, commonly called "activity cycle". In this case, a detailed knowledge of the flow rate and timing information of the inter-arrival times of the requests over different time periods identified on the activity cycle for each service offered by the software application can be envisaged. The division into periods of time is preferably carried out so as to ensure that over a given period of time, the average throughput of the requests is representative of the actual values of observed flows. This division is then taken into account at the level of the ENV2 test tool. By way of example, FIGS. 3A and 3B illustrate, for two distinct services of a software application, the distribution of the number of arrival of requests over a 24h activity cycle. In FIG. 3A, two to five periods of time can be distinguished in which the average rates are fairly representative with respect to the actual values of observed flows (and very different from the overall average flow rate over the 24h activity cycle). For example, a division into two periods of time may consist of a first period of approximately 00h to 8h and a second period of 8h to 00h. In FIG. 3B, a division into 4 periods of time can be envisaged as consisting of a first period between 0 and 5:30, a second period between 5:30 and 10:00, a third period between 10:00 and 12:30 and a fourth period between 12:30 and 24:00. . The probes of the ENV2 test tool are configured to collect various metrics, and in particular here: 3037417 21 the end-to-end response time of the user requests as a function of average arrival rates and the distribution of the inter-arrivals of user requests from the APP software application; and for each server of the CONFIG2 configuration, the utilization rate of the processor or processors 5 of this server, or the execution time of the request by the server. Alternatively, other metrics can be collected in this test environment and in particular for each server, the distribution of the number of network connectors used, the distribution of the RAM volume used, the occupancy rate of RAM and / or pool input / output "threads" from each server, etc.

As previously mentioned, the module 4 of the determination system 1 is configured to adjust the resources and parameters of the servers of the initial configuration CONFIG2 according to results of load-bearing tests carried out using the ENV2 test tool. This adjustment, which is done by relying here on several load-bearing tests suitably parameterized in terms of the load injected to limit the complexity of the implementation of these tests, enables the module 4 to determine a configuration of "target" servers ( configuration CONFIG_TARG) for the deployment of the APP software application in a production environment that checks the maximum response time TRnnax fixed for the software application and supports the target load ktarg. In the embodiment described here, the test environment ENV2 also makes it possible to carry out endurance or availability tests on the configuration of CONFIG_TARG servers after its determination by the module 4. These tests are intended to validate the dimensioning and the parameterization of resources made from unit tests and load-bearing tests, the latter being supposed to correspond to a real deployment but on a reduced scale. It is a question, thanks to the tests of endurance, to test the software application and the configuration of target servers CONFIG_TARG on a sufficiently long duration (typically several days) in order to take into account rare events or whose probability of appearance is weak. The test scenarios considered for these endurance tests consist in distributing the user requests according to the different types of services invoked, and in issuing these requests 30 according to a certain load estimated from the load-bearing tests for the target configuration CONFIG_TARG and according to inter-arrival distributions of predefined queries: deterministic, random, burst, etc. The metrics collected after these tests are similar to those collected after load-bearing tests (end-to-end response time of the application, resource utilization rate (CPU, RAM, pool threads, etc.) of each server, etc.). In the embodiment described here, the ENVI test tools. and ENV2 and modules 2 to 4 of the determination system 1 are software modules defined using computer program instructions stored in memory of one or more physical machines. Each of these machines here has the hardware architecture of a computer and includes in particular a processor, a read-only memory, a random access memory, a non-volatile memory and a communication module including other machines or computers. The ROM of each machine constitutes a recording medium according to the invention, readable by the processor of the machine and on which is recorded a computer program according to the invention comprising instructions for the execution of one or more steps of the sizing process according to the invention. We will now describe, with reference to FIG. 4, the main steps of a determination method according to the invention, as it is implemented in a particular embodiment by the determination system 1 illustrated in FIG. FIG. 1. It is assumed as a preliminary to the implementation of this method that a certain amount of information relating to the APP software application and to its deployment in a production environment is provided to the determination system 1, for example by the administrator or developer of the software application. This information is stored, for example, in a non-volatile memory of the determination system 1. Thus, in particular, the service level agreement (SLA) defined for the software application APP is provided to the determination system 1. As mentioned above, this SLA defines the requirements in terms of the quality of the user services UC1,..., UCN offered by the software application APP, and in particular, in terms of volumetry (eg target load ktarg), of availability. and maximum expected response time TRmax end-to-end. It is assumed here that the services UC1,..., UCN are services considered as representative in terms of resource consumption, that is to say the consumption of resources for the provision of these services by the software application APP. is considered significant by the administrator or developer of the software application. The services UC1, .., UCN depend, of course, on the software application in question. The determination system 1 also has, as previously mentioned, profiles of the user requests representative of the actual or at least expected use of the APP software application in a production environment (or as close as possible). Via these profiles, the determination system 1 knows for each of the services UC1, UCN, a percentage (i.e. proportion) of user requests invoking this service among the requests addressed to the APP software application. We denote p_i, the percentage of user requests intended for the APP software application and associated with the UCi service with p_i = 1. These user requests may be of a different type (type) depending on the service they invoke. They trigger the execution sequences of the software application and result in consumption of software and hardware resources. By associating each request with a service, the invention makes it possible to establish a resource consumption model of the software application taking into account the user requirements for each of these services. As an illustration, one can have for example the following types of requests: for the UC1 service: commands / subscriptions; for the UC2 service: cancellations; for the UC3 service: consultations placing orders; for UC4 service: delayed processing at night; etc. If we denote by k the average throughput of the requests associated with the main services of the software application, the determination system 1 deduces from the knowledge of k and the distribution of the requests by service, the average throughput d of the queries associated with the service. service UCi, i = 1, N, using the relation: Xi = p_i x The information on the distribution of the requests on the N services UC1, ..., UCN, and on the average flow rates Xi are given by the profiles of the requests APP software users stored at the determination system 1.

Each request profile associated with a service also includes, as mentioned previously, information representative of the distribution of the inter-arrival times of the requests invoking this service. Such information particularly specifies whether the inter-arrival times of the requests for a given service follow a deterministic or burst-like distribution, such as for example a random or exponential distribution, by specifying the parameters of such a distribution. so that it corresponds to the average time associated with the service in question (eg "on" duration during which the application receives requests and "off" duration, etc.). These query profiles are used in the test cases implemented by the ENVI test tools. and ENV2. The determination system 1 also has information on the deployment constraints imposed during the production of the APP software application. These constraints include in particular the type of deployment architecture envisaged (presented for example in the form of a graph of nodes associated with the deployment units of the APP application). They may also relate to characteristics of the servers (eg types of machines envisaged), for example the capacity and the possibility of extending CPU or RAM of a server, on the use of single or multi-processor servers or another cluster of servers, the configuration type of the deployment units of the APP application, etc. This information may be provided in particular in the SLA. Other constraints and / or information may be provided to the determination system 1 such as, for example, server placement constraints, etc.

However, for the sake of simplification here, we will not consider such additional constraints.

According to the invention, the determination system 1 makes it possible to size the resources necessary for the execution of the APP software application on a server configuration, for deployment in a real execution environment, the configuration duly sized servers being able to check the maximum overall response time TRmax and support the Xtarg target load. For this purpose, the determination system 1 relies on unit tests performed on a "minimal" reference server configuration (namely the configuration CONFIG1) to obtain an estimate of the resource consumption of the software application APP. This resource consumption is characterized here: firstly, by the average execution times of a request from the software application on each of the servers S11,..., S1N1 of the configuration CONFIG1 on which are deployed the deployment units of APP software application. These average execution times are designated in the following description by E (S1j), j = 1, ..., N1; and on the other hand, by the maximum load kmax1 that can be supported by the software application APP1 in the CONFIG1 server configuration (ie the maximum bit rate of the APP software application in the configuration of CONFIG1 servers). The choice of configuration CONFIG1 has already been detailed previously. The determination system 1 therefore has, prior to the execution of the unit tests, a description of the CONFIG1 server configuration and the characteristics of the servers involved in this configuration (step E10). As mentioned above, by way of illustration, a minimum configuration CONFIG1 consisting of a single single-processor server designated S11 (N1 = 1) is chosen here. However, this assumption is in no way limiting, the reference configuration CONFIG1 may include several servers connected to each other. According to the invention, the determination system 1 via its test tool ENVI 25 performs unit tests on the configuration of CONFIG1 servers from scenarios defined for each type of request identified as relevant for the services UC1, ..., UCN offered by the APP software application (step E20). As mentioned above, at the end of these unit tests, the module 2 of the determination system 1 harvest metrics quantifying the resource consumption by the software application on the server S11 during the processing of the 30 requests of the App. In the test scenarios implemented, the requests are sent to the software application in a deterministic manner so as not to have competing access to the resources (eg CPUs here) whose consumption is sought to be evaluated using metrics harvested. In the example envisaged here, the metrics obtained by the module 2 during the unit tests correspond for each type of request associated with a service UCi offered by the software application, to the CPU consumption denoted E (UC1, S11) by the software application on the server S11 to execute a request of this type. Each metric E (UCi, S11) is more precisely here a measure of the average execution time of a request associated with the service UCi on the server S11 (or in a similar way, a measurement of the average utilization rate of the CPU of the S11 server to process this request). The module 2 then evaluates (step E30), from the metrics E (UCi, S11), i = 1, ..., N, harvested for each type of request (in other words for each service), an execution time Means E (S11) of a request by the software application APP on the server S11 (ie all services combined) according to the relation: E (S11) = p_i x E (UCi, S11) Then the module 2 evaluates from the average execution time E (S11), the utilization rate ju (S11) of the server S11. For a single-processor server S11 executing a single instance of the APP application, the module 2 uses for this purpose the following relation: ii (S11) = E (S11) We note that when the configuration CONFIG1 comprises several distinct servers S1j, j = 1, ..., N1 with N1> 1 (in other words, the APP software application is composed of several deployment units distributed on different servers), an average execution time E (S1j) of a query by l APP software application is evaluated by the module 2 for each server S1j, j = 1, ..., N1 CONFIG1 configuration from metrics collected during unit tests 15 conducted in the ENVI test environment. Similarly, an average utilization rate (or service rate) it (S1j) is derived for each server S1j, j = 1, ..., N1 from this average execution time similarly to that described previously. From these utilization rates of the (or servers) of the CONFIG1 configuration, the module 2 estimates here the theoretical maximum load kmax1 for the reference configuration CONFIG1 (step E40). For this purpose, the invention is based on a so-called stability condition of the software application according to which, in order for the software application APP to be stable, it is necessary that the arrival rate k of the requests on a server (which defines here the load of the software application) is strictly lower than the utilization rate of this server. In other words, in the example of the single server S11 of the configuration CONFIG1: 1 (1) i (s11) ii) <1 <,> <E (S11) This hypothesis of stability of the software application APP and the relation ( 1) which results from it make it possible to estimate an upper bound max maxl of the theoretical maximum load of the software application in the reference configuration CONFIG1 from the utilization rates of the servers of the configuration CONFIG1.

In the embodiment described here, for the sake of simplification, the module 2 uses the maximum theoretical load as the upper bound Xmax1: (2) 1? Maxi_ = 1 E (S11) 3037417 26 However, this hypothesis is not and in another embodiment, the module 2 can take as the upper bound kmax1 of the theoretical maximum load a value 1 E with E strictly positive real number. E (S11) In general, if the configuration CONFIG1 comprises Ni servers S11,..., SNI, 5 by applying the stability assumption of the software application APP, we obtain: p (S1j) <1 'for all j = 1, ..., Ni (3) where 2 (S1j) represents the arrival rate (load) of requests of the software application APP on the server SIj, and such]) represents the utilization rate of the server S1j, j = 1, ..., Ni. These rates 2 (51j) and, u (S1j) can be obtained by the module 2 by using the following equations: f 2 (51j) = Eli '= 1.6i; xm ii (S1j) = E (S11j) (4) E (S1j) = Elil = ip_i x Ei (S1j) with p ,, = 1 if a request from the UCi service causes the execution of a program on the S1j server , Otherwise 13ii = 0, and E1 (S1j) designates the average execution time of a request of the service UCi on the server S1j. The inequality (3) and the relations (4) then allow the module 2 to estimate the upper bound Xrnax1 of the theoretical maximum load from the following inequality: 1 <(5) max t (E7 = ifiti x p_i ) As mentioned above for the configuration comprising a single server, for the sake of simplification, the module 2 uses here as upper bound: maxi = 1N (6) max t (Eii \ r = i / 3i1xp_i) xE (S1M1 or alternatively: 1 Xmaxl = Ni max [OE1I3J x p_i) x E (S1j) li = 1 with E strictly positive real number. The upper limit kmax1 thus determined by means of the equality (2) or (6) is used subsequently by the module 2, and more generally by the determination system 1, as an estimate of the theoretical maximum load of the software application in the CONFIG1 reference configuration. It is noted that the inequality (5) above highlights the influence of the power and the number of servers in the configuration of servers CONFIG1 on the maximum allowable load 30 by the software application. Thus, in view of this inequality, to use the servers S1j, j = 1,..., N1 of the configuration CONFIG1 as equitably as possible, to ensure that the loads of these servers S1j which are equal to (e1_, x p_i) x E (S1j), j = 1, ..., N1 are the closest possible 1 1 (51j) 3037417 27 possible from each other. In this way, it is possible to optimize the cost of the servers in the deployment of the APP software application including on the configuration of reference servers CONFIG1. The theoretical maximum load? Max1 estimated by the module 2 gives an upper bound for the request rate values that can be supported by the software application APP in the configuration of reference servers CONFIG1. In the embodiment described here, the module 2 then determines, from this upper bound, a value of flow (ie a load) X that is admissible for the configuration CONFIG1 (step E50) according to: X = axXrnax1 (6) 10 with a real number such that 0 <a <1. FIGS. 5A to 5D illustrate the impact of the choice of the parameter a on the performances of the software application APP. FIG. 5A schematically represents the general appearance of the average response time (expressed in milliseconds) of a software application APP deployed on a number NS of 15 servers, NSk 1, as a function of the average bit rate of requests injected (expressed in number of queries per second). Such a figure can be obtained by carrying out load-bearing tests, for example using the ENV2 test environment. In this figure, one can identify three main areas, denoted respectively Z1, ZOpt and Z2, and such that: when the load values are in the zone Z1, the mean response times of the APP software application follow a first linear scheme in which all the servers of the considered configuration behave normally and have the possibility of processing more requests. In other words, the zone Z1 materializes an area where the servers of the considered configuration are underutilized (zone of underutilization of the resources); When the load values are in the zone Z2, the average response times of the software application APP follow a second linear regime in which they degrade more rapidly than the increase in the corresponding load. In this so-called congestion zone, saturation of the servers and the software application may occur, in other words, at least some of the servers of the tested configuration are overloaded; When the load values are in the zone ZOpt, the average response times of the software application APP are in the vicinity of the change of speeds. They must of course be limited by the value TRmax of the maximum response time deemed acceptable for the software application. In this zone, the maximum capacity of some servers in the server configuration can be reached.

It should be noted that the end of the first linear regime (and therefore the zone Z1) is much easier to characterize than the load value marking the beginning of the overload of the servers of the software application (beginning of zone Z2). because this value is particularly unstable. The inventors have found by experience that the "limit" load materializing the end of the optimal zone ZOpt can be considered as also materializing the beginning of zone Z2, because beyond this limit load, the saturation of servers and software application becomes imminent. This limit load can be considered as the load value corresponding to the maximum response time TRmax deemed acceptable for the software application APP. It can also be considered that the end of the zone Z2 corresponds to the theoretical maximum load knnax1 given by the upper bounds of the inequalities (2) and (5). It is assumed here that the parameter a is chosen so that the load X is in the zone ZOpt. This makes it possible to optimize the use of the servers on which the software application is deployed while respecting the maximum response time required.

As illustrated in FIGS. 5B-5D, it will be noted that the distribution of the inter-arrival times of the requests has an influence on the position of the point of intersection of the linear regimes of the zones Z1 and Z2. FIGS. 5B-5D respectively represent the results of three series of load-bearing tests performed on a software application deployed on a server configuration, these results illustrating the average response times obtained as a function of the average request rates sent to the server. software application and by varying the inter-arrivals of requests according to a deterministic distribution (see FIG. 5B), an exponential distribution (FIG. 5C) or a burst distribution (FIG. 5D). It can be seen from these figures that the less regular the request traffic (in other words, the further away it is from a deterministic distribution), the earlier the regime change appears in terms of load. In this example, it can be observed that the parameter a can be chosen equal to approximately 0.95 for deterministic inter-arrivals, 0.80 for exponential inter-arrivals and 0.50 or 0.60 for burst inter-arrivals. In view of these findings, it is assumed here that the module 2 selects a value of the parameter a between 0.80 and 0.95. It thus obtains the value of admissible load X from equation (6) (step E50).

In a variant, the module 2 selects a value of the parameter a taking into account the inter-arrival distributions of the requests specified in the request profiles associated with the different services UC1,..., UCN, for example based on the values above (0.95 for deterministic inter-arrivals, 0.80 for exponential inter-arrivals). The different elements estimated by the module 2 from the configuration of reference CONFIG1 and the unit tests (ie maximum load, allowable load, etc.) are then used in accordance with the invention of reference data for any sizing of servers in a future production environment of the APP software application in which requirements in terms of server characteristics and volumetry are predefined by the SLA. The sizing of the servers of this production environment of the software application APP 35 is done in two stages by the determination system 1: (1) selection by the module 3 of an initial server configuration (namely the configuration CONFIG2) for the deployment of the software application comprising determining the number of servers of this configuration and their parameters according to the volume required in the SLA (ie the target load ktarg) (step E60), and the estimation the theoretical maximum load for this configuration CONFIG2 (step E70); and (2) adjustment by the module 4 of the number and parameters of the CONFIG2 configuration servers to satisfy the end-to-end maximum TRmax response time required in the SLA (step E80), and obtaining the target server configuration CONFIG TARG (step E90). We will now detail further the E60-E90 steps implemented by the modules 3 and 4 leading to obtaining the CONFIG_TARG target server configuration. In order to select the initial configuration CONFIG2 (step E60), the module 3 takes into account the target load (volume) ktarg and the characteristics of the servers imposed by the deployment constraints of the software application APP. More specifically, it is based on the maximum load? Max and the admissible load k evaluated by the module 2 from the results of the unit tests conducted on the configuration of servers CONFIG1 and on correspondence rules established between the parameters of the servers. the configuration CONFIG1 and the 15 parameters of the servers of the CONFIG2 configuration, for the choice of the number and parameters of the servers to be considered in the CONFIG2 configuration. These matching rules are established here based on the theory of queues (or queuing networks). They allow the module 3 to determine the power and the number of servers or server clusters S2j, j = 1,..., N2 to be considered in the initial configuration CONFIG2 taking into account their characteristics (single-processor, multiprocessor, etc.). ). In a known manner, according to the queuing theory, each queuing system is a formalism composed of a queue and a server, and is mainly characterized by: a random process of arrivals of queues; queries, defined by a request arrival rate and a distribution of the inter-arrival times of the requests; a service process defined by a statistical distribution of service time; a policy for scheduling server requests (eg FIFO (First In First Out), PS, RR, etc.); - a number of servers; and 30 - a capacity (size) of the queue. In the embodiment described here, this queue modeling is adopted by making the following assumptions for the APP software application: a processor (CPU) of the server is modeled by a server of a queue; the execution time of a request corresponds to the service time; The storage / memory of the server is modeled by the queue; and - the arrivals of the requests are modeled by the process of arrivals.

These assumptions allow simple modeling of a software application running on one or more single-processor, multi-threaded or multiprocessor servers. Thus, by way of illustration: FIG. 6A shows a queue system modeling of a software application running on a single processor server; FIG. 6B illustrates a queue system modeling of a software application running on a multiprocessor server comprising m identical processors; and Figure 6C shows a queue system modeling of a software application running on a cluster of n identical multiprocessor servers.

Other configurations may of course be envisaged. In particular, the deployment units of the software application can be distributed and deployed on servers or server clusters interconnected via a telecommunications network (NW), and then modeled by a network of queues, an example of which is shown in Figure 6D. The module 3 therefore associates a system or queue network model with the CONFIG2 configuration, depending on the constraints imposed for the deployment. It should be noted that this association can be performed upstream of the determination method according to the invention, for example since the deployment constraints of the APP software application are known. Then, from this model, the module 3 establishes a relationship (i.e., a matching rule) between the average execution times of the servers or cluster (s) of the configuration CONFIG2 servers with those the server or servers in CONFIG1 configuration. For the exemplary models envisaged in FIGS. 6A to 6C and for a reference configuration CONFIG1 comprising a single server S11, the module 3 establishes, for example, the following relationships (digital model MOD within the meaning of the invention) taking into account the target load 25 ktarg and the admissible load k estimated by the module 2 for the reference configuration CONFIG1: - For a software application running on a CONFIG2 configuration consisting of a single single-processor server S21 (see modeled in FIG. ), the server S21 must be chosen such that (step E60): x, E (S21) = Xtarg XE (S11) where E (S21) designates the average execution time of a request of the software application APP on the server S21. This means, for example, that if the target load ktarg = 2 x X, the server S21 of the initial configuration CONFIG2 must be twice as powerful in terms of CPU as the server S11 of the reference configuration CONFIG1. Thus, the same request may be executed by the server S21 in half the time, resulting in a utilization rate twice as high in terms of CPU.

From this relation and making a hypothesis of stability of the APP software application as mentioned previously, the module 3 estimates a theoretical maximum load Xmax2 for the configuration CONFIG2 which is such that (step E70): Itarg < Xmax2 5 with 1 2max2 = E (S21) For a software application running on a CONFIG2 configuration consisting of a multiprocessor S21 server having m identical processors (see modeled in FIG. 6B), the server S21 must be chosen such that (step E60): E (S21) = E (Sproc) <xx E (S11) ktarg where E (S21) designates the average execution time of a request of the software application APP on the server S21 and E (5 ,, ',) denotes the execution time of the request by a processor. As in the example above, the module 3 then estimates a theoretical maximum load Xmax2 for the configuration CONFIG2 which is in this case such that (step E70): ktarg <2, max2 with 1 m E (S21). E (Sproc) Imax2 - = For a software application running on a CONFIG2 configuration consisting of a cluster of n identical multiprocessor S21 servers having m identical processors (see modeled in Figure 6C), the server cluster S21 must be chosen such that (step E60): E (cluster) = E (Sproc) <XE (S11) nm - Xtarg where E (cluster) designates the average execution time of a request of the software application APP on the server cluster S21 and E (S0) denotes the execution time of the request by a processor of a server S21, that is: 25 x E (Sp ') XE (S11) x nm Xtarg As in both examples above, the module 3 then estimates a theoretical maximum load Xmax2 for the configuration CONFIG2 which is in this case such that (step E70): Xtarg <kmax2 30 with 1 nm Xmax2 = = E (cluster) E (Sproc) Others more complex models can of course be considered to model the configuration of CONFIG2 servers according to the constraints of deployment These are based on the relationships between the target load ktarg, the execution times of the servers CONFIG1 and the execution times of the servers of the configuration CONFIG2. Thus, for example, we consider a software application APP offering a single service intended to run on a configuration CONFIG2 consisting of several distributed servers S21, S22 and a server cluster comprising n identical servers S23, the server S21 being a multiprocessor server comprising m identical Sproc processors. In this case, the module 3 can determine the power and the number of servers and / or processors of the CONFIG2 configuration from unit test results performed on a reference configuration CONFIG1 implementing three APP software deployment units on 10 three servers S11, S12 and S13 and depending on the Itarg target load. More precisely, the module 3 selects in this case the power and the number of servers for the initial configuration CONFIG2 such that (step E60): E (S21) = E (SProc) _ XXE (S11) Xtarg X. E (S22) ) = x E (S12) 2aarg E (cluster 523) = E (S23) = 2 ^, x E (S13) n Itarg The same notations previously introduced are used. As in the three examples above, the module 3 then estimates a theoretical maximum load for the configuration CONFIG2 which is in this case such that (step E70): Xtarg <2max2 with 20 Xmax2 1 = min IE (smproc) 'E ( S22) 'E (Sn23)} According to yet another example, consider an APP software application offering a plurality of services UC1, ..., UCN, each service corresponding to a percentage of requests p_i, i = 1, ... , N, the software application being intended to run on a configuration CONFIG2 comprising servers or distributed server clusters S21, S22 and S23, each of these servers respectively comprising ml, m2 and m3 identical processors denoted Sproc211 5proc22 and Sproc23 CONFIG1 configuration comprises three servers S11, S12 and S13 implementing three deployment units of the APP software application The module 3 then chooses in this case the power and the number of servers for the initial configuration CONFIG2 such that (step E60 ): E (S - ,, roc21 4 E (S22) = E (Spmr ol c22) Ir ppiti. xX, A, txairgi XE (S11) X E. (S12) E (S21) = 'E 23) (smr2oc i = 1 Atargi N 21, i E (S23) =' 5_ 1 p_ix, x E (S13). m3 i = i Enlarged The same ratings as previously introduced are used, the permissible and target loads being in this example determined by the unit tests on the servers for all the services of the APP software application. above, the module 3 then estimates a theoretical maximum load 5 Xmax2 for the configuration CONFIG2 which is in this case such that (step E70): ktarg <Xmax2 with ml m2 m3 1 2.max2 = min mproc21) 'E (sproc22) "sproc23)).

Of course, these models are given for illustrative purposes only and are by no means exhaustive. The theoretical maximum load value Xmax2 thus obtained in step E70 by the estimation module 3 for the initial configuration CONFIG2 selected in step E60, and which in particular increases the target load Xtarg, is then used by the evaluation system. determination 1, 15 and more particularly by the module 4, to limit the load-bearing tests performed on the CONFIG2 initial server configuration using the test tool ENV2. More specifically, as mentioned above, the determination system 1 then carries out, through its test tool ENV2 and its module 4, load-bearing tests on the initial configuration of servers CONFIG2 (step E80). These tests are intended to evaluate the processing capacity (eg CPU utilization rate, response time, etc.) of the APP software application servers in the configuration of CONFIG2 servers with simulated user request flows. representative of actual use of the software application. In other words, the test environment ENV2 takes into account in these tests not only the request request rate (and in particular the target load Xtarg imposed by the SLA service level agreement), but also the variation of the requests. times that separate two consecutive query arrivals also called inter-arrival times of queries. Indeed, the CONFIG2 configuration selected by the module 3 is constructed from digital sizing models based solely on the average throughput of the requests sent to the APP software application and on unit test metrics for which the resources are accessed. servers without competition. However, the variation in the times of inter-arrival of the requests has a significant impact on the end-to-end response time of the software application as mentioned above, and 3037417 34 can be a source of congestion or even of stopping of servers. the software application in particular if clumps of requests are formed and persist in time during the execution of the software application. According to the invention, the initial CONFIG2 configuration therefore advantageously serves as a starting point for performing load-holding tests in the ENV2 environment by relying on requests injections close to the behavior of the users of the APP software application. in a production environment. It is the results of these tests that enable module 4, during step E80, to adjust and / or readjust the number and / or the parameters of the servers, the objective being to obtain a configuration 10 of target servers CONFIG_TARG for production (step E90). In other words, during these load-holding tests, unlike the unit tests previously performed on the CONFIG1 server configuration, the inter-arrival times of the requests are no longer deterministic but they are close to the distributions actually encountered during the use. of the software application in a real execution environment. These 15 distributions were previously defined by the administrator of the software application and are stored as mentioned previously in the memory of the determination system 1, in profiles of user requests defined for each service UC1, ..., UCN. Thus, considering such realistic distributions, clumps of queries may occur and result in concurrent access to shared resources of the CONFIG2 configuration, which may cause a momentary collapse of the software application or severely degrade its response time. . The behaviors in terms of resource consumption of the APP software application on the servers of the CONFIG2 configuration can therefore be very different from those previously estimated by the module 3. In particular, the configuration CONFIG2 as selected by the module 3 for 25 support the 2darg target load was selected without taking into account variations in the inter-arrival times of requests from the APP software application. There is therefore no guarantee that this target load is outside the congestion zone Z2 described above with reference to FIG. 5A. The module 4 adjusts and / or readjusts the configuration of CONFIG2 servers as a result of load hold tests, that is, scales the resources of the CONFIG2 configuration to ensure that the target load ktarg is for the configuration adjusted, in the zone Zopt, ie outside the zone of congestion Z2. The upper limit in terms of the charges of this zone Zopt corresponds to the charge leading to the maximum response time TRmax fixed by the SLA agreement. In the embodiment described here, to make these adjustments during step E80, the module 4 of the determination system 1 implements a charge injection policy to minimize the number of tests performed in the system. ENV2 environment. More specifically, the load withstand tests are performed by injecting the input of the software application and CONFIG2 configuration loads according to an algorithm detailed below. These charges are lower in any case than the maximum theoretical load 2anax2 determined by the module 3, this load 2max2 being strictly greater than the target load Xtarg. These charge injections are performed using the charge injection modules of the ENV2 test tool. The inter-arrival times of injected requests follow a distribution close to a real use of the software application and as specified in the user request profiles. It should be noted that, advantageously, the invention does not require knowledge of the load distributions to be individually injected to each server of the CONFIG2 configuration. The invention is content with a global knowledge of the query profiles for the end-to-end software application.

For each load value injected during these load-holding tests, the module 4 obtains the following metrics here: end-to-end response time of the software application APP; and resource consumption (eg CPU, RAM, pool, etc.) for each server S2j, j = 1,, N2 of the tested server configuration (CONFIG2 or CONFIG2 adjusted).

FIG. 7 illustrates in more detail, in the form of a flowchart, the algorithm implemented by the module 4 for optimally performing during step E80 the load-bearing tests and the adjustment of the resources of FIG. the CONFIG2 configuration. In accordance with this algorithm, the module 4 first chooses a request (load) rate .1.test1 such that (step E801): (Xmax2 ittest1 = min2, K1 × Xtarg) 20 where K1 designates a predetermined real constant less than or equal to 1. For example K1 = 0.8. Then the module 4 performs a first load-holding test on the initial configuration CONFIG2 from step E60 by injecting via the test environment ENV2 a load equal to At1 (step E802). The module 4 then compares the end-to-end response time TR (Δtest1) of the software application APP obtained for this load Δtestl with respect to the expected maximum response time TRmax (test step E803). If TR (Mest1) is greater than TRmax (yes answer to the test step E803), then this means that one or more servers of the configuration CONFIG2 are undersized and that it is necessary to proceed to an adjustment of the number of servers and / or their parameters and / or resources (step E804). This adjustment is made by module 4 taking into account the individual consumption of each server of the tested configuration to reinforce the resources of those who are most loaded. The value of exceeding the response time TR (Δtest1) with respect to the maximum response time TRmax defines the ratio of this adjustment. By way of example, FIG. 8A illustrates a 25% overshoot of the maximum response time TRmax, i.e. (TR (11test1)) - TRmax) / TRmax) = 25%. In this case, the module 4 applies an increase in the resources of the configuration CONFIG2 of the same order, either by adjusting the number of servers of the configuration, or by adjusting their parameters (eg processor power, number of processors, etc. .). When the resizing of the CONFIG2 configuration is completed, the previous steps are reiterated on the adjusted configuration (still denoted CONFIG2 for the sake of simplification), ie, the module 4 resumes the step E802 and applies it to the adjusted configuration. If TR (Mestl) is less than or equal to TRmax (answer no to the test step E803), then the module 4 selects a new load value denoted bytest2 such that ittest2 <ittestl (step E805). For example, the module 4 here chooses a load ittest2 = K2 x Atestl with K2 constant real predetermined 10 less than 1. K2 is for example taken here equal to 0.25. In a variant, the module 4 chooses a charge Δtest2 determined as a function of the target load 2targ, for example equal to 10% of the target load ittarg. Then, the module 4 performs a second load-holding test on the configuration CONFIG2, via the test environment ENV2, by injecting the load ittest2 to the software application APP 15 (step E806). At the end of this test, it obtains the end-to-end response time TR (.1, test2) of the software application APP. The module 4 then determines, from the loads 2test1 and Mest2 and the response times of the software application APP TR (Atestl) and TR (2test2) obtained for these loads, an estimate of the response time of the software application for the server configuration tested for a load equal to the target load Âtarg (step E807). This estimate is denoted D (2targ). In the embodiment described here, this estimation is obtained by the module 4 by considering the line D passing through the points A1 and A2 of respective coordinates A1 = (.test1, TR (Atest1)) and A2 = (.test2, TR (ittest2)), and the point A of the line D of abscissa iltarg. The module 4 takes as an estimate D (.1targ) the ordinate of the point A. FIG. 8B illustrates this straight line on an example as well as the estimate D (2targ) obtained from this line. It should be noted that the constants K1 and K2 are chosen preferentially so as to obtain two points Al and A2 sufficiently distant to allow the construction of the line D. The values considered in the example described here, namely K1 = 0.8 and K2 = 0.25 advantageously make it possible to obtain such a plot, however other values may be envisaged alternatively. Then, the module 4 compares the value D (.1targ) with the maximum response time TRmax specified in the SLA (test step E808). If D (Âtarg) is greater than TRmax (yes answer to the test step E808), then this means that one or more servers in the configuration CONFIG2 are undersized and that it is necessary to adjust the number servers and / or their parameters and / or resources (step E809). This adjustment is performed by the module 4, as in step E804, taking into account the individual consumption of each server of the tested configuration to reinforce the resources of those who are most loaded. The value of exceeding the response time D (Âtarg) with respect to the maximum response time TRmax defines the ratio of this adjustment. By way of example, FIG. 8B illustrates a case of D (.1targ) exceeding the maximum response time TRmax. In this case, the module 4 applies an increase of the resources 5 of the configuration CONFIG2 of the same order as (D (.1targ) - TRmax) / TRmax, either by adjusting the number of servers of the configuration, or by adjusting their parameters ( eg processor power, number of processors, etc.). When the resizing of the CONFIG2 configuration is complete, the previous steps are repeated on the adjusted configuration (still denoted CONFIG2 for the sake of simplification), that is, the module 4 resumes the step E802 and applies it to the adjusted configuration. If instead D (2targ) is less than or equal to TRmax (answer no to the test step E808), then the module 4 examines whether D (/ ttarg) is substantially lower than TRmax (test step E810). In the embodiment described herein, by substantially less, is meant that D (Δtarg) is less than y = 90% of the value of TRmax. Of course, this value, taken as 90% or equivalent to 0.9, is parameterizable and is given for illustrative purposes only. FIG. 8C illustrates an example where D (.1targ) is substantially smaller than TRmax according to the aforementioned criterion. If such a situation arises (yes answer to the test step E810), this means that the CONFIG2 configuration tested (which corresponds to the configuration CONFIG2 possibly adjusted and / or readjusted) is overdinnned. The module 4 thus proceeds to a (re) adjustment of the resources of the configuration CONFIG2 based as in step E809 on the difference (D (Âtarg) - TRmax) / TRmax (step E811). Then when the resizing of the configuration CONFIG2 is completed, the previous 25 steps are repeated on the adjusted configuration (still denoted CONFIG2 for the sake of simplification), that is, the module 4 resumes the step E802 and applies it to the adjusted configuration . Otherwise (answer no to the test step E810), the module 4 selects a new load 2test3 equal this time to the target load ittarg (step E812) and carries out a new load test 30 on the configuration CONFIG2 by injecting , via the ENV2 test environment, the APP software application deployed on this configuration the charge Âtest3 (step E813). The module 4 then compares the end-to-end response time TR (Âtest3) of the software application APP obtained for this load Âtest3 with respect to the maximum expected response time TRmax (test step E814).

If TR (Δtest3) is greater than TRmax (yes answer to the test step E814) as shown for example in FIG. 8D, then this means that one or more servers of the configuration CONFIG2 are undersized and that The number of servers and / or their parameters and / or resources should be adjusted (step E815). This adjustment is performed by module 4 similarly to steps E804, E809, E811 taking into account the individual consumption of each server of the tested configuration to reinforce the resources of those who are most loaded. The value of exceeding the response time TR (Δtest3) with respect to the maximum response time TRmax defines the ratio of this adjustment, similar to what is done at the adjustment steps E804, E809 and E811. Then when the resizing of the configuration CONFIG2 is completed, the previous steps are repeated on the adjusted configuration (still denoted CONFIG2 for the sake of simplification), that is, the module 4 resumes the step E802 and applies it to the adjusted configuration.

If not (answer no to the test step E814), the configuration CONFIG2 is considered correctly sized for the deployment of the APP software application in a production environment (step E816). The configuration thus adjusted constitutes the target configuration CONFIG_TARG obtained by the determination system 1 and considered for the production of the software application (step E90).

The algorithm implemented by the module 4 during the step E80 and represented in FIG. 7 makes it possible to compromise the number of load-holding tests carried out and the adjustment of the CONFIG2 configuration. This algorithm advantageously makes it possible to validate as soon as possible the configuration of servers on which to deploy the software application APP while abstaining from carrying out too many load-holding tests because of a load increment between each test. too weak. This algorithm converges very quickly to a production configuration thanks to the information acquired from modules 2 and 3 and taking advantage of the measured response time differences with respect to the maximum response time TRmax to quantify each adjustment of the server configuration tested. In the embodiment described here, as a result of the (potentially iterative) tweaking of the CONFIG2 configuration servers by the module 4 resulting in the TARIG CONFIG target server configuration for the production of the application software, the determination system 1 validates the configuration obtained by performing an endurance test on it (step E100). These endurance tests are carried out using the ENV2 test tool over a sufficiently long predetermined execution time (eg several days) in order to take into account rare events whose probability of appearance is low. . User requests are divided according to UC1, ..., UCN services and issued with a certain allowable load and inter-arrival times following predefined distributions (eg deterministic, random, burst, etc.). The metrics observed during this test are similar to those observed during load balancing tests (end-to-end response time of user requests, average execution time on each server or utilization rate of the CPU, etc.). , and make it possible to validate the CONFIG TARG configuration and the sizing of its resources or to carry out, if necessary, further adjustments in a manner similar to what was done during step E80 (step E110).

At the end of step E110, the sizing system 1 therefore offers a configuration of servers CONFIG_TARG a priori dimensioned so as to verify the constraints imposed by the SLA agreement, that is to say, sized to support in a real production environment, the target load 2targ while respecting the maximum response time TRmax.

It should be noted that the pre-dimensioning technique proposed by the invention is based on taking into account realistic request profiles that are close to the actual use of the software application. However, it is sometimes difficult to have precise information on these distributions for software applications distributed in cloud-type environments. Indeed, the delays between two consecutive arrivals of requests at the entrance of a server are disrupted by network delays traversed in the cloud and other servers processing, and suffer random jigs. Accumulations of queries waiting to be processed at the input of a server can occur and significantly impact the response time. On the other hand, since any software system has a hardware limited capacity, system collapse can occur when the amount of processing momentarily exceeds the capacity of the server although the average rate is respected. Therefore, in such a context, the resulting target configuration CONFIG_TARG at the end of step E110 is preferentially considered as an initial deployment configuration making it possible to satisfy the requirements specified in the SLA, in an elasticity management method according to the invention.

FIG. 9 represents, in the form of a flowchart, in a particular embodiment, the main steps of an elasticity management method according to the invention which uses as the initial deployment configuration, the target configuration CONFIG_TARG determined by the determination system 1 (step F10). The initial target configuration CONFIG_TARG is then deployed in production and the APP software application is executed on the target configuration (step F20). This execution is accompanied by mechanisms for monitoring the execution of the software application using known control metrics per se (step F30), and mechanisms for maintaining, adding or removing resources according to the metrics of the software application. supervision and predetermined rules (step F40), so as to absorb momentary bursts during the execution of the application and guarantee SLA compliant response times. Such a mechanism is described, for example, in the document by L. Letondeur et al. entitled "Planning for automatic application elasticity management in the cloud", ComPAS'2014, April 23-25, 2014. This elasticity management process can thus be easily implemented by a management system of elasticity according to the invention (not shown in the figures) comprising: - the determination system 1, which determines a target configuration of servers for the deployment of the software application via the execution of the determination method according to the invention ; 3037417 a module for triggering an execution of the software application on the target configuration of servers; a module for monitoring at least one supervision metric of this target configuration during the execution of the software application; and an adjustment module such as that described in the precised document by L. Letondeur et al. and configured to adjust resources allocated to the target configuration based on said at least one metric, wherein said adjustment module is adapted to maintain allocated resources or dynamically add and / or remove resources from the target configuration.

In the embodiment and the examples described above, it was considered that the average arrival rate of the requests of the software application APP was representative of the actual rate values encountered during the execution of the software application. However, as already mentioned above and illustrated in FIGS. 3A and 3B, it may be that for certain software applications, the arrival rate of the service requests varies significantly over time and this, in a repetitive manner, thus defining cycles of time. activities of the software application. In such a context, the average rate of arrival of the requests of the software application on each activity cycle is rather insignificant compared to the actual flow values over the different periods making up the activity cycle. To manage such a situation, in a particular embodiment of the invention, the activity cycle of duration T of the software application APP is cut beforehand for each service UCi, i = 1,. a plurality Li of time intervals [Tjl_i, j = 1, ..., Li such that the corresponding average flow rates, denoted by (UCi, [Tjt_i), are sufficiently representative of the actual values of flow encountered over the time intervals [Tj] _i (i.e. typically such that the standard deviation of the average flow rates over each interval is small, for example less than a predefined threshold). Moreover, the time intervals [Tj] _i, j = 1, ..., Li are defined here for each service i = 1, ..., N such that: T = [11] ju [T2] uu The number of intervals Li considered for the division of a cycle of activity may vary from one service to another or be identical for all or part of the services UCi, i = 1, ..., N considered. To further illustrate the processing performed by the determination system 1 in this embodiment, reference is made hereinafter to FIG. 10, a simple example of a software application offering two main services UC1 and UC2 defined in one embodiment. SLA agreement and characterized, on an activity cycle of duration T, by the following request profile: for the UC1 service: the arrivals of the requests relating to the service UC1 are distributed over L1 = 3 time slots [T1] _1, [ T2] _1 and [T3] _1 such that T = [T1] _1 u [T2] _1 u [T3] _1 and with respective average flow rates on each of these intervals denoted k11 = X (UC1, [T1] _1) = X (UC1, [T2] _1) and M.3 = 2 (UC1, [T3] _1); - for the UC2 service: the arrivals of the requests relating to the service UC2 are distributed over L2 = 4 time slots [T1] _2, [T2] _2, [T3] _2 and [T4] _2 such that T = [T1 ] _2 u [T2] _2 u [T3] _2 u [T4] _2, and with respective average rates on these intervals denoted k21 = X (UC2, [T1] _2), X22 = X (UC2, [T2] _2 ), 2 \ 23 = X (UC2, [T3] _2) and X24 = k (UC2, [T4] _2). s Also considered in this example N1 = 4 servers S11, S12, S13 and S14 in the reference configuration CONFIG1, the three servers S11, S12, S13 being involved in the execution of the service UC1 and the two servers S11 and S14 being involved in the execution of the UC2 service. In view of these hypotheses, the activity cycle of the APP software application can be decomposed, according to a new division shared by the two services UC1 and UC2 derived from the division for each of the services, in L = 6 time intervals [T1 ], [T2], [T3], [T4], [T5] and [T6] as illustrated in FIG. 10, on which the flow rates [Ti], i = 1, ..., 6 of arrival of APP software application queries are representative and given by the following relations (7): nTl] = k11 +? 21 15 T. [T2] = X11-FX, 22k [T3] = k12-FX22 k [T4] = k12 + 2 ^ 23 X [T5] = 2 ^ 13-n24 k [T6] = k13 +? \ 24 For each time interval [Ti], i = 1, ..., 6, the distribution of the requests of the software application between the two services can be deduced as follows: Pi ([Tu) = 2'11 [1, i = 1 and 2 {112 Pi ([Tu]) = ,,. 1, i = 3 and 4 pi ([Tu]) =, [7,, 1, i = 5 and 6 2,, x2 [Tin P2 ([T1]) = P2 ([Ti]) X.22 i = 2 and 3 i = 4 and 5 X [Ti]? 24 X [T6] P2 ([Tu) = X23 1 [Ti] P2 ([T6]) = 25 Thus we can deduce, for each time interval [Tl], the rate of the arrival of requests of the App: X (UCi, [TI]) = pi ([T1]) xk [T1] for i = 1, ..., N and I = 1, ..., L The steps of the determination method as described above are then applied by the determination system to each of the six intervals [T1],..., [TL], with L = 6.

In other words, for each time interval [T1], I = 1, ..., L, the determination system 1 performs the following steps: unit tests via the test environment ENVi and determination by the module 2, for each server S1j, j = 1 ..., N1 = 4 of the reference configuration CONFIG1, the average arrival rate 5 of the requests 2L. (S1j) [71 of the software application APP and the execution time by means of a request E (S1j) [71] on the server Si] over the time interval [TI], all services combined. In the example envisaged here, one obtains in particular, from the relations (7) indicated above applied individually for each server of the configuration of reference CONFIG1, and according to the implication of each server of the configuration of reference In the execution of the services UC1 and UC2: for the server S11 involved in the execution of the two services UC1 and UC2: k (S11) [T1] = X11 + 2 ^ .21? \ (S11) [T2] =. 2 \., 11 + X22 k (S11) [T3] = 2L12 + 222 2 \, (S11) [T4]. = X.12 + X.23 k (S11) [T5] - = 113 + X23 X (S11) [T6] = X13 + X24 and E (S11) [TI] = p1 ([T1]) xE (UC1, S11) + p2 ([TI]) xE (UC2, S11), 1 = 1.2 , 3,4,5,6. For the servers S12 and S13 involved in the execution of the service UC1 only:? ^, (S12 / S13) [T1] = k11 (S12 / S13) k (S12 / S13) [T2] =? \, 11 (S12 / S13)?, (S12 / S13) [T3] = k12 (S12 / S13) X (S12 / S13) [T4] = k12 (S12 / S13) X (S12 / S13) [T5] = k13 (S12 / S13) k (S12 / S13) [T6] = 713 (S12 / S13) and E (S12 / S13) [TI] = p1 ([T1]) xE (UC1, S12 / S13), 1 = 1,2,3,4,5,6. The notation Sli / S1j signifying that the equalities apply to both the server Sui and the server S1j; and for the server S14 involved in the execution of the service UC2 only: X (S14) [T1] = k21 k (S14) [T2] = k22 3037417 43? \ (514) [T3] = k22 k (S14) [T4] = k23k (S14) [T5] = k23k (S14) [T6] =? \ 245 and E (S14) [T1] = p2 ([T1]) xE (UC2.514), 1 = 1,2,3,4,5,6. determination by the module 2, by applying the stability condition of the software application APP, of an estimate X1max [T1] of the theoretical maximum load such that: X1max [T1] = max f (riv = i f3if x piaT1D) x E (S1n [T /]) 4i_1 It should be noted that certain intervals may be merged with their neighboring intervals, especially when: the duration of the interval [TI] is less than a threshold, for example corresponding to the time of setting in place of a virtual server; and / or average flow rates and run times on two consecutive intervals have close values.

Following the estimations made by the module 2, and at this phase of revision of the intervals T1 if necessary, the steps E60 to E110 described above are implemented by the modules 3 and 4 individually for each of the time intervals (possibly revised It is noted that the invention has been described in a cloud-like context for sizing virtual machines to support a software application. However, the invention applies to other types of environment and the sizing of hardware and / or virtual machines. 1

Claims (15)

REVENDICATIONS1. A method of determining a so-called target server configuration for a deployment of a software application (APP) capable of offering at least one service, the method comprising: a obtaining step (E20), for at least one service offered by the software application, by means of at least one unit test performed on a configuration of so-called reference servers (CONFIG1) capable of executing the software application (APP), of an average execution time of an invoking request this service for each server (S1j) of the reference configuration; a selection step (E60) of an initial configuration of servers (CONFIG2) for the deployment of the software application capable of supporting a target load (Xtarg) determined for the software application, this selection step taking into account the times execution means obtained during said at least one unit test, the target load and a determined allowable load (k) for the reference configuration, and using a numerical model reflecting at least one deployment constraint of the software application imposed on the initial server configuration; and a step of determining (E90), from the initial configuration, a target server configuration (CONFIG_TARG) to be used for the deployment of the software application, said determining step comprising performing (E80) d a plurality of load-bearing tests parameterized according to a theoretical maximum load (kmax2) estimated for the initial configuration and the target load, and using at least one request profile invoking said at least one service offered by the software application, this profile being representative of a use of the software application during its deployment, said determining step further comprising, depending on the result of each load-holding test, an adjustment (E80) of at least a resource of the initial configuration so that the target configuration obtained at the end of said plurality of load-bearing tests is able to check a re-start time. maximum rate set for the software application and to support said target load. 2. The method of claim 1 further comprising a step of estimating (E40) a theoretical maximum load (krnax1) for the reference configuration and wherein the allowable load (k) determined for the reference configuration results from the product. of a parameter between 0 and 1 by the estimated theoretical maximum load for the reference configuration. The method of claim 2 wherein the theoretical maximum load (kmax1) for the reference pattern is estimated by applying a stability condition of the software application to at least one average execution time of a request for the software application derived for said at least one server of the reference configuration from the average execution time obtained for this server for the services offered by the software application. 5 4. Method according to any one of claims 1 to 3 wherein during the determination step, the adjustment (E804, E809, E811, E815) of at least one resource from the initial configuration to the end a load-holding test is performed as a function of a difference between a response time of the software application evaluated during the load withstand test and the maximum response time (TRmax) set for the software application. 10 5. Method according to any one of claims 1 to 4 wherein the determining step comprises at least: a first load withstand test (E802) made with a first load less than a minimum value between one half of the load theoretical maximum estimated for the initial configuration and the product of the target load by a predetermined real number less than or equal to 1; a second load holding test (E806) performed with a second load lower than the first load; and a third charge hold test (E813) performed with a third charge equal to the target charge. The method of claim 5 wherein the determining step further comprises an estimate (E807) at the end of the second test of a response time of the software application with the target load from a response time evaluated at the end of the first test performed with the first load on a tested configuration derived from the initial server configuration and a response time of the evaluated software application at the end of the second test performed with the second load on said tested configuration, the resource adjustment being performed after the second test based on a difference between the estimated response time for the target load and the maximum response time set for the software application . 30 7. The method of claim 6 wherein, after the second test: the server configuration tested is considered undersized if the estimated response time for the target load is greater than the maximum response time; and / or the tested server configuration is considered oversized if the estimated response time for the target load is less than the product of a predetermined real number of between 0 and 1 and the maximum response time; and / or the tested server configuration is considered correctly sized otherwise. 3037417 46 The process of claim 7 wherein y is 0.9. The method of any one of claims 5 to 8 wherein the target configuration corresponds to a tested server configuration for which at the conclusion of the third test, a response time of the evaluated software application for the target load. on this server configuration tested is less than the maximum response time. The method of any one of claims 1 to 9 further comprising a step of validating (E100) the target configuration by means of an endurance test performed during a predetermined execution time of the software application. . 11. The method as claimed in claim 1, in which the digital model models said at least one deployment constraint of the software application from at least one queue or a network of queues. 'waiting. 15 12. The method as claimed in claim 1, in which at least one request profile comprises, for at least one determined period of time of an activity cycle of the software application: an average rate of requests invoking this service over the said period of time; A proportion of requests invoking this service among the requests invoking services offered by the software application; and a distribution of inter-arrival times between two requests invoking this service over said period of time. 25 The method of claim 1 to 12 wherein said software application is characterized by an activity cycle comprising a plurality of intervals, each interval being associated with an average request arrival rate representative over that interval, and wherein said obtaining, selecting and determining steps are implemented for at least one interval of said plurality of intervals. 30 14. A resilient management method of a server configuration capable of executing a software application, said method comprising: a step of determining (F10) a server target configuration for the deployment of the software application comprising the performing a determination method according to any one of claims 1 to 13; and an execution step (F20) of the software application on said server target configuration comprising: monitoring (F30) at least one supervisory metric of said target configuration; and o according to said at least one metric, an adjustment (F40) of the resources of the target configuration, this adjustment comprising maintaining and / or adding and / or dynamically removing resources to the target configuration. 15. A system for determining (1) a target configuration for a deployment of a software application, the system comprising: a first test tool (ENVI.) Allowing the execution of at least one unit test on 10 the software application when it is executed on a so-called reference server configuration; a obtaining module (2), configured to control the execution of at least one unit test by the first test tool on said reference configuration and to obtain, for at least one service offered by the software application, a average execution time of a request invoking this service for each server (S1j) of the reference configuration; a selection module (3), configured to select an initial server configuration (CONFIG2) for the deployment of the software application adapted to support a target load determined for the software application, said selection module being configured to take account of average execution times obtained during said at least one unit test, the target load and a given load determined for the reference configuration, and to use a numerical model reflecting at least one deployment constraint of the software application imposed on the initial server configuration; a second test tool (ENV2) for performing load-holding tests on said software application when it is executed on the initial server configuration selected by the selection module; and a determination module (4) configured to determine from the initial configuration a target server configuration for use in the deployment of the software application, said determination module being configured to control the execution of a plurality of load holding tests by the second test tool, said load withstand tests being parameterized by the determination module according to a theoretical maximum load estimated for the initial configuration and the target load, and using at least a request profile invoking said at least one service offered by the software application, this profile being representative of a use of the software application during its deployment, said determination module being further configured to adjust, depending on the result of each load-holding test, at least one resource of the initial configuration so that the configuration a target obtained after said plurality of load-bearing tests is 3037417 48 able to verify a fixed maximum response time for the software application and to support said target load.