System and procedure for measuring the performance of applications by means of messages

[0002] 1. Technical Field

[0003] The present invention describes a procedure for measuring the performance of processing steps in programs or parts of programs by means of messages, particularly in application programs which are distributed over several computers.

[0004] 2. Prior Art

[0005] In distributed applications, program parts run on several computers which are usually different. They communicate with one another by transmitting messages over one or more networks.

[0006] It is very difficult to determine the end-to-end response time of transactions in a distributed application and to evaluate large response times in particular.

[0007] The determination and evaluation of the end-to-end response time of a transaction in a distributed application is necessary because of the following points:

[0008] During the development of an application, performance bottlenecks need to be recognised early and removed through design improvements.

[0009] During the installation of a distributed application, performance problems often occur. These are connected to the local configuration of hardware and software not having been tested using the new product. In such cases it is very difficult for the customer to assign an error to one of the products involved.

[0010] After the successful commissioning of a distributed application, one will want to measure and evaluate the end-to-end response time of transactions. This is necessary in order to be able to ensure the availability of the application for the user. In addition, one wishes to analyse the end-to-end response time by components in order to recognise the cause of a fault on exceeding a pre-given limit value.

[0011] The determination of the end-to-end response time of transactions in distributed applications is technically necessary.

[0012] Currently there are a number of procedures for determining the end-to-end response time.

[0013] One of the procedures for determining the end-to-end response time is based on the idea of fitting the application parts with instruments so that they can signal the start and end of transactions (or transaction parts) to an agent running outside the application. The agent ensures that the data are brought together centrally and evaluated. In this procedure, the measurements of transaction parts belonging to a transaction call cannot be correlated, i.e. one cannot know which measurement values belong to a particular transaction call. In order to facilitate a correlation, a globally clear identification of the transaction call must be introduced into this procedure. Such an extended procedure is technically complex because the agent is outside the application logic and therefore globally clear identifications are required. As all measurement values for evaluation have to be collected together at a central point, the discovery of associated values from a large number of measurement values is very laborious.

[0014] In addition, there are costly hardware monitors with common electronic clocks with which one can monitor system calls over several computers. Hardware monitors are expensive and the instrumentation is very costly. A disadvantage of hardware monitors is in that they cannot supply any data to application levels. Thus calls from operating system services can be counted and measured but the allocation of transactions to an application is difficult. In addition, only computers with the same type of architecture can be monitored. This often does not occur with distributed applications because the servers and clients are usually different.

[0015] Otherwise there are the so-called profilers with which one can determine which program parts run on a computer and how often and how much time is spent in which program parts. However, it is not possible to receive coherent information on transaction parts running on different computers.

[0016] All the above procedures are based on the application being measured from outside, i.e. the application logic and instrumentation being fully separate or separate as far as is possible.

[0017] The task of the present invention is to suggest a procedure which allows the performance data of transactions to be received together with the application data, so that they are easy to report and that an analysis of the end-to-end response time is very simple.

[0018] More specifically, the present invention relates to a process for measuring the performance of processing stages of programs or parts of programs by means of messages in a data-processing system, wherein the message which is to be processed by a program receives an area for entries of performance data and the particular processing stage concerned deposits a performance marker in this area.

[0019] The present invention further relates to a process for the determination and evaluation of response times of processing stages of a program or parts of a program by means of messages in a data-processing system, wherein the message which is to be processed in a program receives an area for time entries, and that the processing stage of the particular program deposits a time marker in this area.

[0020] Still further, the present invention is directed to a data-processing system containing at least one computer, operating system software and programs, characterised in that the message to be processed by means of a program contains an area for performance and/or time entries, and that the particular processing stage of this message deposits a performance entry and/or time entry in this area.

[0021] Even further, the present invention is directed to data carriers containing a program for the performance of a process as described above.

[0022] The advantages of the procedure in accordance with the present invention are that the integrated processing of application data and performance data describing a transaction call are combined in a response message. All data are available at one point and at the same time.

[0023] As the measurement data belonging to a transaction call are combined in a response message, the different transaction paths taken are also able to be recognised and evaluated. The procedure can be used for both the analysis of design and installation problems as well as for ensuring the availability of applications.

[0024] Preferred embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

[0025] FIG. 1 shows a client-server architecture in which the procedure according to the invention is used to determine the performance data of a transaction call in a distributed application.

[0026] FIG. 2A shows the procedure according to the invention using as an example a distributed application in a client-server architecture.

[0027] FIG. 2B shows the design of the time marks according to the invention.

[0028] In distributed applications, program parts run on several computers. Examples of distributed applications are bank programs, flight booking programs or database programs. Particularly important is compliance with response times in distributed networks, as compliance with certain response times is an object of the agreement between data processing suppliers and users.

[0029] FIG. 1 shows a simple distributed application consisting of a client program on a workstation computer connected over a network to the server program on another computer. The client program sends requests to the server program and receives responses. The term for requests and responses is messages. The end-to-end response time from creating a request to receiving the result can be determined through comparing two time measurements in the client program. The duration of individual processing stages of the request/response cannot, however be determined in this way.

[0030] FIG. 2A shows the individual processing stages in executing a request in a distributed network. An example of this is the request for payment of a certain sum of money from a cash-point machine. This request can be broken down into the following processing stages, as FIG. 2A shows:

[0031] 1. Request created by client (e.g. payment of money)

[0032] 2. Request goes to the network

[0033] 3. Request is decoded by the server

[0034] 4. Request funds is checked by the server (e.g. there sufficient funds in the account)

[0035] 5. Response created by the server (e.g. pay the amount requested)

[0036] 6. Response goes from network to client

[0037] 7. Response is decoded by client

[0038] 8. Response is analysed by client

[0039] 9. Response is carried out (the sum of money is paid out).

[0040] The procedure in accordance with the invention allocates an area for entries of time marks (time mark area) to each message (request/response); see FIG. 2B. As the message (request/response) runs through several processing stages as shown in FIG. 2A, the message receives a time mark (Z1, Z2, Z3, etc.) after each freely definable start and end of a processing stage. As shown in FIG. 2A, the message “Pay me a sum of DM 300”, for example, contains 9 time marks by the time the desired amount is paid out. From these 9 time entries, the end-to-end response time of the respective message can be determined quickly, or the duration of individual processing stages can be determined. The individual processing stages can be freely defined by the user. Generally, the processing stage is defined by transitions of program parts, program functions or other definable interfaces.

[0041] FIG. 2B shows the principal structure of a message with the area for time entries using the example of a direct debit enquiry in a bank application.

[0042] The enquiry consists of enquiry transaction data such as desired debit amount, account number, bank sort, code, PIN number and time mark area. The time mark area contains the respective time marks which are left behind by the respective processing stage.

[0043] Preferably, each time mark consists of:

[0044] 1. A Description with

[0045] computer identification (client/server—C/S)

[0046] a unique identification of the message in the client (request/response—e.g. 1267)

[0047] a component describing the processing stage(e.g. queue)

[0048] 2. A Value of the Computer System Time

[0049] An example of a time mark of the “Create request” processing stage:

[0050] C “00001267” create request “12:00:02.100”

[0051] C stands for the identification of the computer—here it is “client”

[0052] 00001267 stands for the identification of a certain request

[0053] Create request—describes the concrete processing stage

[0054] 12:00:02.100 stands for the time of the request.

[0055] At the start and end of each processing stage, such a time mark can be written in the message (request/response).

[0056] The course in FIG. 2A can thus be described as follows:

[0057] 1. The client program writes time marks in the message (request/response).

[0058] 2. After the request is transmitted over the network to the server computer, the server program writes further time marks in the request.

[0059] 3. The server creates a response and transfers the existing time marks from the request to the response.

[0060] 4. During the processing of the response, further time marks are entered.

[0061] 5. After the response is transmitted over the network to the client computer, the client program writes the last time mark in the response.

[0062] 6. Before the response is deleted, the time marks are written to a file for further evaluation.

[0063] After such processing of the message (request and response), the file contains, for example, the following entries:

[0064] The evaluation of time marks is carried out based on the identifiers of the respective request. All time marks with the same identifier in the respective request are evaluated as follows:

[0065] 1. Differences are established between the values of the respective processing stages of a request. Thus the execution time for respective processing stages are determined. In this context it is emphasised that it is not possible in general to compare system time values from different computers with one another because their clocks are not synchronised.

[0066] 2. The difference between system time values at the first time mark in the request and the last time mark in the response is thus the end-to-end response time.

[0067] In addition, the network time not recorded can also be determined as follows:

[0068] Network time=response from network−request to network−(response to network−request from network).

[0069] The subdivision of network time according to request and response is not possible without a standardised system time.

[0070] The evaluation of time marks in the above stated example can be carried out as follows:

[0071] Through the integrated processing of application data and performance data, the measurement data which describe the processing stages of a transaction are contained in a response message. This has the advantage that the correlation problem here is easy to resolve, which would otherwise be very difficult. Frequently, processing stages of a transaction are inhomogenous, i.e. different processing calls do not always run according to the same pattern. As the measurement data belonging to a processing call are combined in a response message, these different paths which are taken are also easy to recognise and evaluate.

[0072] A particular advantage of this invention is that in addition to the important response times of requests/responses, other performance data such as the use of the CPU, memory, input and output units as well as the network are also written into the area set aside for performance entries and are can therefore be easily measured and evaluated.

[0073] While the invention has been particularly shown and described with respect to preferred embodiments thereof, it will be understood by those skilled in the art that the foregoing and other changes in form and details may be made therein without departing from the spirit and scope of the invention.