WO2007017296A1

WO2007017296A1 - Application system intelligent optimizer

Info

Publication number: WO2007017296A1
Application number: PCT/EP2006/061926
Authority: WO
Inventors: Francois Briant; Sebastien Llaurency; Pierre Dejean; Florence Dubois
Original assignee: International Business Machines Corporation; Compagnie Ibm France
Priority date: 2005-08-08
Filing date: 2006-04-28
Publication date: 2007-02-15
Also published as: EP1920330A1; CN101390056A

Abstract

According to the invention there is provided a management system which defines and applies a federated set of actions, resulting from the combination of input data gathered from the different components, including applications data, such as workload and response time, and infrastructures data, such as system CPU, memory and I/O. The data gathered results into a self-optimized application system, through actions taken at the following different levels, in a logical order from simplest to more complex. A first level of optimization concerns application such as job priorities and job reorganization. A second level of optimization concerns system, within a predefined and assigned set of resource. A third level of optimization concerns the global architecture, by extending the resource allocated to the applications from a shared pool and adding resource dynamically to the application system infrastructure, according to needs.

Description

APPLICATION SYSTEM INTELLIGENT OPTIMIZER

Field of the Invention

The present invention relates generally to on demand operating environment and dynamic workload balancing and more specifically to an application system intelligent optimizer.

Background of the Invention

An on demand operating environment unlocks the value within the Information Technology (IT) infrastructure to be applied to solving business problems. It is an integrated platform, based on open standards, that enables rapid deployment and integration of business applications and processes. Combined with an environment that allows true virtualization and automation of the infrastructure, it enables delivery of IT capability on demand. An on demand operating environment must be flexible, self-managing, scalable, economical, resilient, and based on open standards. Three major areas should be analyzed when building an on demand operating environment, - integration: provides the facilities to gain a unified view of processes, people, information, and systems.

- virtualization: simplifies deployment and improves use of computing resources by hiding the details of the underlying hardware and system software, allowing for consoli- dation and the ability to adapt to changing demand.

- automation: overcomes the complexity of systems management to enable better use of assets, improved availability and resiliency, and reduce costs based on business policy and objectives.

On Demand architectures induces variation of workloads applied to system environments reaching a scale never reached before, and impacting a much larger scope and variety of components than ever before. This variation impacts the whole customer business solution, including both applications and their associated infrastructures. From an IT perspective, this translates into being able to provide a company with a flexible infrastructure driven by a mechanism constantly adapting and adjusting the global system capacities, to the constantly changing application workload.

Today, there is no existing system which enables the optimization of a global Application System, including software application packages and their associated Infrastructure i.e., hardware and middleware. In general, existing application system optimizers are only acting at either the application level, or the infrastructure level, but they do not act at the two levels in the same logical flow.

Existing systems, impacting both applications and infrastructure, address the monitoring, modeling and planning phases, and propose actions to be taken at system or application level. Existing system does not execute real time optimization actions, with an immediate result at the business application level. Thus today's systems provide a limited scope of optimization.

Optimizing a global business solution system requires several separated steps, including monitoring, analyzing, modeling, planning and taking actions at applications and/or system levels; these systems are described in some publications, each of them being related to a specific scope of action only. For example, systems for monitoring and improving application performance are described in http: //www. umt . com/site/index_356.html and in http: //www. redbooks . ibm. com/redbooks/pdfs/sg246057. pdf .

Summary of the Invention

Thus, it is a broad object of the invention to remedy the shortcomings of the prior art as described here above.

It is another object of the invention to provide a management system which defines and applies a federated set of actions based upon application components and system architecture analysis.

It is a further object of the invention to provide a self-optimized management application system acting on application level, system level, and global architecture level .

It is still a further object of the invention to provide a self-optimized management system adapted to reduce cost of application system management and global cost of application infrastructure.

The accomplishment of these and other related objects is achieved by a method for optimizing the execution of at least one application component in a computer environment comprising a plurality of resources, a set of said plurality of resources being dedicated to said at least one application component, said method comprising the steps of, - at initialization phase: creating a system data model table comprising a description of the main features of said plurality of resources; and, - creating an application data model table adapted to store a description of the resources allocated to and required by said at least one application component, the response time of said at least one application component, and the response time required by said application component;

- during runtime:

- collecting the status of the resource allocated to said at least one application component and storing said status in said application data model table; - collecting the response time of said at least one application component and storing said response time in said application data model table;

- comparing the resource allocated to said at least one application component with the resource required by said at least one application component;

- comparing the response time of said at least one application component with the response time required by said at least one application component; and,

- if the response time of said at least one application component is greater than the response time required by said at least one application component, if the usage of said dedicated resources is within the resource requirement of said at least one application component, and if at least one second application component is running, delay- ing the execution of said at least one second application component if the priority of said at least one second application component is below the priority of said at least one application component or if said at least one second application component is more resource consuming than said at least one application component; - else if the response time of said at least one application component is greater than the response time required by said at least one application component and if the usage of said dedicated resources is below the resource requirement of said at least one application component, allocating more of said dedicated resource to said at least one application component;

- else if said response time of said at least one application component is greater than the response time required by said at least one application component and if the totality of said plurality of resource is not dedicated to said at least one application component, provisioning a part said plurality of resources not dedicated to said at least one application component, to said at least one application component.

Further embodiments of the invention are provided in the appended dependent claims .

Further advantages of the present invention will become apparent to the ones skilled in the art upon examination of the drawings and detailed description. It is intended that any additional advantages be incorporated herein. Brief Description of the Drawings

Figure 1 illustrates the general environment of the system of the invention referred to as Application System Intelligent Optimizer.

Figure 2 depicts the system data model table associated to the dedicated system and to the global system pool.

Figure 3 illustrates an application data model table corresponding to a particular module of an enterprise application package.

Figure 4 shows an example of the hierarchy of the application components illustrated on the table of figure 3 and the three level of optimization of the invention.

Detailed Description of the Preferred Embodiment

According to the invention there is provided a manage- ment system which defines and applies a federated set of actions, resulting from the combination of input data gathered from the different components, including

• applications data, such as

- actual global workload; - actual workload per type (e.g., online, batch, prints, and updates) ;

- actual response time per workload types; and,

• infrastructures data, such as : - systems (e.g., CPU, Memory, I/O, Network, Disk usage) middleware (e.g., database volumes and types of accesses, and response time;

- application server (e.g., volumes and types of trans- actions and response time) ;

The data gathered will result into a self-optimized application system, through actions taken at the following different levels, in a logical order from simplest to more complex: - application level such as job priorities, job reorganization (e.g., online versus batch and update versus read only) ;

- system level, within a predefined and assigned set of resource (workload management principles, managing priori- ties within a defined scope of resource) ; and,

- global architecture level, by extending the resource allocated to the applications from a shared pool (provisioning principles) , and adding resource dynamically to the application system infrastructure, according to need, and when previous step has reached its limits of action.

Likewise, the optimization according to the invention can be done at a macroscopic stage (e.g., application module or system entity) and/or at a microscopic stage (particular transaction of an application module or system sub-entity) . In a preferred embodiment, the optimization is first applied at a macroscopic stage and the stage is successively decreased until the system reaches the desired state of optimization, or until the lower stage has been reached. The stage of an application or of a system entity can be determined, for example, by the number and the precision of its main features and characteristics.

The core of the invention is based on three major principles : - both applications workload and required system resource are considered as components, enabling a wide variety of application-to-Resource combinations and (re) allocation decisions;

- the actual applications workload and system resource usage are monitored and compared to the defined requirements; and,

- when difference between actual and required state is observed, optimization actions are taken.

Figure 1 illustrates the general environment 100 of the disclosed invention referred to as Application System Intelligent Optimizer (ASIO) . It should be noticed that the system environment includes dedicated subsystems assigned to specific applications and global subsystems i.e., pool of system resources not dedicated to any specific application. The data used by ASIO system 105 are coming from both the application environment, Application Data 110, and the system environment, System Data 115. These initial data are complemented by application system policies and rules that are entered in the system through an application system policies and rules interface 120. Application system policies and rules can be entered by a user or accessed from storage or network (not represented) . Application system policies and rules are stored in a knowledge base 125 comprising an application and system data model and associ- ated status. Application and system policies and rules are preferably defined through interface 120 during a setup or initialization step and are updated if requested.

The ASIO algorithm comprises an initialization step and a runtime mode. As mentioned above, during the initializa- tion step, the application characteristics and policies (defining the ASIO algorithm rules) are preferably determined, the dedicated systems and the global system are identified, and the application and system data model is set .

In the runtime mode, the ASIO algorithm monitors and optimizes the application system by,

- analyzing application resource requirements to collect status information by comparing application resource requirements with allocated application resources; - analyzing status information and the variations between required resource and actual allocated resource;

- determining the set of recommended actions and converting these actions into orders executable by the corresponding executing systems; - transmitting orders to the executing system, at the right level,

- application level;

- dedicated system level; and,

- global system pool level.

To that end, an application transaction and system resource analyzer 130 analyzes the application data 110 and the system data 115 and transmits application transaction and system resource status to knowledge base 125. Such status are periodically updated according to a predetermined frequency parameter. As a consequence, knowledge base 125 summarizes all the information characterizing the state of the system from both system and application perspectives, as well as the application requirements and the available resources .

An application and system monitoring module 135 monitors the data stored in knowledge base 125 to check the behavior of the different components of the application system (AS) to determine whether or not application requirements are fulfilled. By comparing application requirements with application status, application and system monitoring module 135 determines if application optimizer 140 must give orders to the different elements of the AS, to enable the optimization of the global system, by combining actions at the application, dedicated systems and global system pool environment .

If application and system monitoring module 135 determines that application resource requirements are different than allocated application resources and exceed a predetermined threshold, a first test 145 corresponding to a first level of optimization is done to determine whether or not application workload can be optimized. If application workload can be optimized, the order for managing applica- tion workload priorities according to application system policies and rules recommendations is determined (box 150) and the order is transmitted to application package functions 155. If application workload can not be optimized, a second test 160 corresponding to a second level of optimi- zation is done to determine whether or not existing resource can be added to application system. If existing resource can be added to application system, the order for allocating more resource to applications according to application and system policies and rules recommendations is determined (box 165) and the order is transmitted to the dedicated system optimization functions 170. If existing resource can not be added to application system, a third test 175 corresponding to a third level of optimization is done to determine whether or not additional resource can be added to application system. If additional resource can be added to applica- tion system, the order for provisioning more resource to applications according to application system policies and rules recommendations is determined (box 180) and the order is transmitted to the global system pool provisioning and orchestration manager 185.

It should be noticed that orders, or recommended actions, can include adding or releasing resources, according to the differences observed between the requirement and the monitored status. Likewise, the execution of the orders can be either executed automatically by the application system, or be proposed to an operator as an action to be done .

According to the first level of optimization, application component of transaction type are associated to system components (dedicated system) and are potentially reorgan- ized, or rescheduled, by the ASIO engine according to system component status and resource availability through the application package functions 155.

The second level of optimization can address both module and family of transaction types of components. It is associated to dedicated system component level. ASIO algorithm uses a combination of application and dedicated system components parameters to dynamically adapt system resource to the application component workload, using dedicated system optimization functions 170 like workload management, dynamic partitioning, and dynamic data base optimization.

The third level of optimization addresses application module types of components, it concerns interaction with the global system pool of resource. ASIO algorithm uses a combi- nation of application component and system component parameters to request addition of system resource from the available pool of resource through the provisioning and orchestration manager 185.

In a preferred embodiment, the knowledge base 125 comprises two tables referred to as system data model and application data model, characterizing the state of the system from both system and application perspectives, as well as the application requirements and the available resources .

• System data model (infrastructure data)

System data model table is a description of the whole system resource comprising the dedicated system and to the global system pool. It thus describes the total resources available for the application system to operate in an optimized way. In a preferred embodiment, the system data model resource inventory is a table that rows represents resources and columns represents resource main features . For example, table 200 of figure 2 depicts the system data model table associated to the dedicated system and to the global system pool. As illustrated on figure 2, each row of the system data model table 200, generically referred to as 205, corresponds to a specific resource. For example, row 205-3 describes a single system (S) . The number of rows depends upon the system and upon the granularity that is required for optimizing the system. The granularity can be updated, if required, when the ASIO is running. For example, if storage features can be stored in a single row, it is possible to split later such row in several rows characterizing sub-storage device features, allowing a greater level of optimization. As mentioned above, each column of the system data model table 200, generically referred to as 210, corresponds to the main features of the resources. For example, column 210-1 comprises information relative to CPU charac- teristics while column 210-2 concerns memory characteristics. Likewise, number of columns depends upon the system characteristics and upon the granularity that is required for optimizing the system. The granularity can be updated, if required, when the ASIO is running. For example, if CPU characteristics can be stored in a single column, it is possible to split later such column in several column characterizing sub-CPU characteristics, such as CPU itself and cache, allowing a greater level of optimization. Still in a preferred embodiment, the system data model table is completed during the initialization step, as mentioned above. Depending upon the resource types and resource features, some cells of the system data model table can be empty. For example, even if storage devices may comprise CPU, CPU is not a main feature of this kind of resource and so, the corresponding cell can be left empty. Such cell can be identified through the application and system policies and rules interface 120 of figure 1. It should be understood that the model is flexible enough, so that new resource types, and associated parameters, can be defined, and entered into the ASIO logic flow, through the flexible association of the resource model to the application model. In particular, the system data model table is updated when new resources are added to the system environment .

Resources are preferably described in the system data model table using their main features corresponding to the parameters that applications workload components will use to define their specific resource requirements. Naturally the key characteristics that must be identified for each resource of the system depends upon the kind of resource itself. For example, here are the main characteristics that should be memorized for the following resources,

• Single system : System ID

- dedicated to an application component (yes/no) ;

- architecture type and OS version: for example, Intel (xx processor), Unix (e.g., AIX, HPunix, or Solaris), zOS, Linux (e.g., RedHat or Suze) , or I5/0S;

- CPU (processor speed (MHZ) , usage (%) , and number of partitions;

- memory (central memory size (MB) and usage (%) ) ;

- hard disk (capacity dedicated to system (GB) and usage (%)); and,

I/O (number, I/O bandwidth associated to the system (GB/sec) , and usage (%) ) . • Logical partition : Partition ID

(same characteristics as for a system) and,

- link to single system ID.

• Database : database ID - type (e.g., DB2, Oracle, and SQL DB);

- release;

- DB Size (MB) ;

- allocated memory (buffer pool and usage (%) ) ; and,

- any other key parameters (depending, for example, upon the implemented database) .

• Application / transaction server :

- type (e.g., CICS, Tuxedo, WebSphere, and WebLogic) ; and,

- release.

Naturally, other types of system resources can be defined and to be associated to application components for optimization purpose.

For sake of illustration, it is assumed that each resource parameter of table 200 is "flexible and remotely manageable" i.e., that its value can be remotely changed for optimization purpose. If one would require non remotely manageable resource parameters in the system data model table, an additional status can be used to indicate whether or not the corresponding parameter is remotely manageable. • Application data model

Application data model table establishes the link between the system infrastructure and the application behavior. Application data are summarized in application data model table wherein each rows contains the main parameters of a a particular application, a particular application component, or a particular application sub-component, depending upon the required granularity. Each column of the application data model table characterizes a particular resource required by the applications and currently allocated to these applications. Once again, the number of column depends upon the required granularity and can be adapted dynamically. Depending upon the type of the applications and the type of the parameters, some cells of the application data model table can be left empty. For example, not any database parameter (requested nor allocated) is assigned to an application component that do not use any database. Such cell can be determined through the application system policies and rules interface 120 of figure 1.

The application data model table is preferably created at the initialization step and updated each time a particular application, a particular application component, or a particular application sub-component is launched or stopped and on a regular basis according to a predetermined frequency parameter.

Turning now to figure 3, here is depicted an application data model table 300 corresponding to a particular module of an enterprise application package, an inventory management module, that is composed of application compo- nents and sub-components such as inventory management module, inventory status transaction, update inventory- transaction, and print inventory summary transaction. As mentioned above, each row of application data model table 300, generically referred to as 305, comprises the main parameters of a particular application, a particular application component, or a particular application sub-component. Each column of application data model table 300, generically referred to as 310, characterizes a particular resource required by the applications and currently allocated to these applications. For example, row 305-2 contains the main parameters of the inventory status transaction and columns 310-1 and 310-2 contains the value of the response time and priority parameters. In particular, the actual response time of the inventory status transaction is equal to 0.9 second while the required maximum response time of this transaction is equal to 2 seconds and the priority of this transaction is set to high. Still in a preferred embodiment, a column is assigned to the dedicated systems and comprise information relative to the dedicated system identification (ID) , its requested dedicated part (Rqd) and its allocated dedicated part (Act) .

As a consequence, each application component is characterized by a set of parameters and a corresponding set of parameter values determining resource requirements which are requested for the application component to behave according to the defined policies and rules. For example, the update inventory transaction is characterized by the parameters "response time" and "priority" and by the corresponding parameter values "2 seconds" and "low". For example, here are the main parameters and parameter values, or policies and rules, that could be used to characterize application, application component, or application sub-components, • Application component: application parameters

- application component type (e.g., application module, family of transaction, business transactions, and IT transaction (Job or task) ) - associated hierarchy:

- application module (e.g., inventory management)

- business transactions (e.g., inventory status, and update inventory) ;

- IT transactions (e.g., queries associated to a status request and commits associated to an update inventory) ;

- transaction type (e.g. user interaction (Dialog), batch, update, external access, and print)

• Application components : policies and rules - expected response time (seconds) ; and,

- priority (e.g., high, medium, or low) .

• Application components : resource requirement parameters type of system required (e.g., associated operating system, database, and middleware) ; and, - workload characteristics (according to application component) in resource required (e.g.,

- system CPU (%) ;

- required memory (MB) ;

- database tables space (MB) ; - required I/O bandwidth (MB/s) ;

- disk space (GB) ; and, - network bandwidth (GB/s) ) .

This Application component structure enables to adapt the parameters characterizing the component, and the associated resource required. It should be noticed that response times can be either truly measured response times, or average response times (over a predetermined period of time) .

The hierarchical structure enables also to use ASIO engine for a level of granularity which will be modular and dependent on the size and complexity of the global application system. Its implementation can be progressive, starting with the highest level (application component - module type level) , to progressively go down to certain low level components, which may be critical to the business using this application system. In particular, the application data model table can be updated upon user request or when the execution of an application component can not be optimized. In this last case, it is necessary to determine which application sub-components can be optimized. This can be done through a user's interface or automatically, by storing pairs of application sub-components and resources in an additional column. In such case, by determining the type of available resources, the system is able to determine which application sub-components can be optimzed and thus, to create new entries in the application data model table for these application sub-components .

Figure 4 illustrates the hierarchy of the previous example and the three level of optimization. As depicted, boxes 400 to 415 represent application component parameters and boxes 420 to 430 represent possible optimizations. More particularly, box 400 contains the main parameters of the application workload component that name is inventory management. As shown, the main parameters of the inventory- management component are its name, the workload patterns (ref. all parameters), the name of the system dedicated to this application component (X) , the actual and the requested CPU average usage (80% and 60%, respectively) , the actual and the requested database buffer pool (each of 100 MB) , and the actual and the required response time (2.3s and 2s, respectively) . Box 405, 410, and 415 contain child transaction profiles i.e., the main parameters of application components linked to a parent application component. In particular, box 405 contains the name of the application component (inventory status) , its type (dialog) , its prior- ity (medium) , the actual and the required CPU average usage (30% and 60%, respectively) , the actual and the requested response time (1.4s and Is, respectively). If required, the execution of each application component can be optimized according to the first, second, or third level of optimiza- tion mentioned above by reference to figure 1. For example, inventory management component can be optimized according to the third level of optimization that consists in provisioning and orchestring new resource (box 420) . Likewise, the inventory status component can be optimized according to the second level of optimization consisting in dedicating system e.g., workload management, dynamic partition adaptation, or database optimization. Finally, the update inventory component and the print inventory component can be optimized according to the first level of optimization that basically consists in scheduling and prioritizing the jobs.

Turning back to figure 1, the application transaction and system resource analyzer 130 checks the allocated parameter values of each application component defined in the application data model table 300 on a regular basis given by a predetermined frequency parameter of the knowledge base 125. In a further embodiment, this predetermined frequency parameter depends upon the type of application components . These allocated parameter values are stored within application data model table 300. In the same time, the application system monitoring module 135 compares the requested parameter values to the allocated parameter values stored in application data model table 300.

If the allocated parameter values do not belong to the requested parameter values, the ASIO algorithm checks the system to optimize it according to the three level of optimization discussed above and detailed herein below.

• First level of optimization (box 150) : analyzing and managing application components

If the response time, or average response time, of one of the application components, or child-component, is greater than the requested response time determined in the application data model table 300 and if the associated dedicated resource (as seen at the application workload component level corresponding to the inventory management module in the example) are within the requirements defined in the application data model table 300, the ASIO algorithm compares the response time status of all application components and child-components to define how many and which application components have response time problems and require actions from ASIO. If application components having the lowest priority (as defined in the knowledge base 125 e.g., high, medium, and low) or if less demanding (in term of priority) type of application components (in descending orders e.g., update, dialog, batch, and print) are running, the ASIO algorithm transmits the order to delay the lowest priority application components and the more CPU-demanding type of application components to the application scheduling and prioritizing management module so as to get more resource available for the troubled application component.

If the result after a predetermined monitoring cycle, is back to normal, no further action is required. Such predetermined monitoring cycle can be stored, for example, in the knowledge database 125. If the result is still bad after the predetermined monitoring cycle, or if the actual dedicated environment resource status is not within the defined requirements, the ASIO algorithm tries to apply the second level of optimization.

• Second level of optimization (box 265) : analyzing and managing dedicated resources

If the ASIO algorithm has detected application components, or child components, having response time greater than requested response time and if the associated dedicated system has a global CPU usage below the requirement as defined in the application data model table 300, the ASIO algorithm starts analyzing dedicated system resource status.

According to the determined parameters relative to the dedicated system that are associated to the application component in the application data model table 300 and that are over the usage limit defined in the application data model table 300 (if partitioned system: CPU, Memory, I/O - Data Base storage pull size, paging rate, disk I/O rate and so on, these parameters are dependent on the dedicated system type and operating system) , the ASIO algorithm identifies the parameters which are over utilized versus the requirement defined in the application data model table 300, and transmits order to the dedicated system management module of the corresponding dedicated resource, using standard protocols such as SNMP or CIM, asking for additional capacity to be allocated to the application components that response time is greater than requested response time.

If several parameters are over the defined limits, iterative requests are made by the ASIO algorithm, with priorities defined in the knowledge base 125 (e.g., from

CPU, Memory, I/O, or to DB buffer pool size and paging rate), according to the dedicated system type.

Such mechanism of workload management, dynamic partitioning, and data base optimization functions are used (according to the dedicated system ability, and as defined in the system component description) , for allocating additional resource from the dedicated system to the application component.

If the application component results are back to normal after these actions and after a predetermined monitoring cycles, no further action will be required. If results are still over the defined limits or if the dedicated system has a global CPU usage over the defined requirement after these actions and after a predetermined monitoring cycles, ASIO algorithm tries to apply the third level of optimization. • Third level of optimization (box 180) : analyzing and managing global resource pool

If ASIO algorithm has detected application components, or child components, having response time greater than the defined limit, and if the dedicated system has a global CPU usage over the defined requirement, or if the first and second level of optimization are not successful in getting the response times back to normal, ASIO algorithm analyzes the global server pool status and starts actions through the provisioning and orchestration manager 185. The global server pool status is determined by comparing system data model table 200 and application data model table 300 to determine the available and non dedicated resources, that can be allocated to the application component that response time is greater than the defined limit.

According to the application component requiring additional resource, provisioning and orchestration manager 185 determines which resource from the global server pool can be added to the application dedicated resource. Such determination is done by analyzing application data model table 300.

This operation of adding additional resources may involve several steps, such as assigning an IP address to a server, configuring network devices and load balancer in the data center, and installing software packages. It also requires software fixes in the server. Since these steps are done by any existing provisioning and orchestration module 185, they are not described into details. Depending on the application component, workflows developed by the application editor (ISV) can be used on one or more of the required steps .

All these operations are managed by the provisioning and orchestration manager 185, on request of the ASIO algorithm.

This request may result in an automated provisioning of additional resource e.g., server, to the application component, or to a recommendation made to an operator to do so, according to what is defined in the knowledge base 125.

The provisioning and orchestration manager 185 having its own monitoring and execution, is also able to de-provision resource e.g., server, assigned to an application component (from the global server pool) , if the average usage of this server is under a defined limit (when the peak application component workload period is over) .

If all application components are back to normal after having applied the third level of optimization, no further actions will be required else, the ASIO algorithm sends messages to the operator console, summarizing the status of the actions taken, and asking for manual intervention on the global system, to finalize the analysis and the optimization of the Application System, using human experience and expertise .

For sake of illustration, the previous described example of the inventory module can be implemented on an application system composed of PeopleSoft application package (PeopleSoft is a Trademark of Oracle International

Corporation), ERP modules, running on Unix servers, for example IBM AIX (IBM and AIX are Trademarks of International Business Machine Corporation) , IBM storage disks and associated networks as dedicated systems, using a DB2 data base manager (DB2 is a Trademark of International Business Machine Corporation) . An additional pool of servers made of Intel Blade servers (Intel is a Trademark of Intel Corporation) is also available in the scope of the application System. The first level of optimization can be implemented using PeopleSoft functions (job scheduling mechanisms) , the second level of optimization can be achieved using the logical partitioning associated to the workload manager of the Unix servers (e.g., AIX 5.3 level) and the third level of optimization can be achieved using IBM Tivoli provisioning and orchestration software (Tivoli is a Trademark of International Business Machine Corporation) .

By using the invention, the resulting application system intelligent optimizer, will result in:

- more efficient optimization, taking into account Applications and Infrastructure parameters, and avoiding wrong or slow reactions to rapid workload evolution;

- lower cost of application system management, by combining the monitoring, modeling and optimization phases, without requiring manual planning or operator action;

- lower global cost of application infrastructure, by both optimizing the global infrastructure usage (reducing the required investment by customer) ; and,

- better user experience (better internal and external user perception of the Application System) .

Naturally, in order to satisfy local and specific requirements, a person skilled in the art may apply to the solution described above many modifications and alterations all of which, however, are included within the scope of protection of the invention as defined by the following claims .

Claims

Claims :

1. A method for optimizing the execution of at least one application component in a computer environment comprising a plurality of resources, a set of said plurality of resources being dedicated to said at least one application component, said method comprising the steps of,

- at initialization phase: creating a system data model table comprising a description of the main features of said plurality of resources; and,

- creating an application data model table adapted to store a description of the resources allocated to and required by said at least one application component, the response time of said at least one application component, and the response time required by said application component;

- during runtime:

- collecting the status of the resource allocated to said at least one application component and storing said status in said application data model table;

- collecting the response time of said at least one application component and storing said response time in said application data model table;

- comparing the resource allocated to said at least one application component with the resource required by said at least one application component; - comparing the response time of said at least one application component with the response time required by said at least one application component; and,

- if the response time of said at least one application component is greater than the response time required by said at least one application component, if the usage of said dedicated resources is within the resource requirement of said at least one application component, and if at least one second application component is running, delay- ing the execution of said at least one second application component if the priority of said at least one second application component is below the priority of said at least one application component or if said at least one second application component is more resource consuming than said at least one application component;

- else if the response time of said at least one application component is greater than the response time required by said at least one application component and if the usage of said dedicated resources is below the resource requirement of said at least one application component, allocating more of said dedicated resource to said at least one application component;

2. The method of claim 1 further comprising the step of comparing the resources allocated to all the application components as defined in said application data model table with the available resources as defined in said system data model table.

3. The method of either claim 1 or claim 2 further comprising the step of adding the description of a new resource in said system data model table when said new resource is added to said computer environment.

4. The method of any one of the previous claims further comprising the step of adding a description of the resources allocated to and required by a sub-component of said at least one application component, the response time of said application sub-component, and the response time required by said application sub-component, to said application data model table.

5. The method of claim 4 wherein said application sub-component is an application transaction.

6. The method of either claim 4 and claim 5 wherein said step of adding a description of the resources allocated to and required by a sub-component of said at least one application component, the response time of said application sub-component, and the response time required by said application sub-component, to said application data model table, is executed upon user request.

7. The method of either claim 4 and claim 5 wherein said step of adding a description of the resources allocated to and required by a sub-component of said at least one application component, the response time of said application sub-component, and the response time required by said application sub-component, to said application data model table, is executed when the execution of said at least one application component can not be optimized.

8. The method of anyone of the previous claims wherein said description of the resources stored in said application data model table comprises CPU information.

9. An apparatus comprising means adapted for carrying out each step of the method according to any one of the claims 1 to 8.

10. A computer-like readable medium comprising instructions for carrying out each step of the method according to any one of the claims 1 to 8.