Evaluating performance of an application using event-driven transactions

• US 8,677,324 B2
• Filed: 01/31/2011
• Issued: 03/18/2014
• Est. Priority Date: 01/31/2011
• Status: Active Grant

• Current Assignee: Micro Focus LLC (Open Text Corporation)
• Original Assignee: Hewlett-Packard Development Company, L.P. (HP Inc.)
• Inventors: Markuza, Dmitry, Schwartz, Dror, Kraus, Moshe Eran
• Primary Examiner(s): Das, Chameli
• Application Number:
  US13/017,522
• Publication Number:
  US 20120198476A1
• Time in Patent Office: 1,142 Days
• Field of Search: None
• US Class Current: 717/127
• CPC Class Codes: G06F 11/3414 Workload generation, e.g. scripts, playback
• CPC Class Codes: G06F 11/3433 for load management allocation of a server based on load conditions G06F9/505; load rebalancing G06F9/5083; redistributing the load in a network by a load balancer H04L67/1029
• CPC Class Codes: G06F 2201/86 Event-based monitoring
• CPC Class Codes: G06F 2201/87 Monitoring of transactions

Abstract

An event-driven performance measurement technique provides a set of transaction definitions that specify transaction actions that correspond to start and end points of a transaction. Events associated with execution of an application are received by a processor-based machine. The machine uses the events to generate transactions in accordance with the set of transaction definitions. The transactions can be used to evaluate performance of the application.

Claims

1. A method comprising:

recording into a script a plurality of script actions representative of a user'"'"'s interactions with an application;

replaying the script of recorded actions;

receiving, by a processor-based machine, events that occur as a result of execution of the application, wherein the received events are dispatched by event sources during the replaying of the script; and

using the received events to generate, by the processor-based machine, transactions for evaluating performance of the application when executed, wherein the transactions are generated in accordance with a set of transaction definitions,

wherein each transaction definition in the set specifies actions which correspond to a start point and an end point of a transaction associated with execution of the application, and wherein the transaction definitions are provided separately from the script.

2. The method as recited in claim 1, wherein the events dispatched by the event sources are stored in a storage device, and wherein the events are dispatched from the storage device and the transactions are generated after the replaying of the script.

3. The method as recited in claim 1, wherein the action specified by a transaction definition as corresponding to the transaction start point is not directly initiated by any script action recorded into the script.

4. The method as recited in claim 1, wherein at least some of the actions specified by the transaction definitions do not directly correspond to any actions recorded in the script.

5. The method as recited in claim 1, further comprising:

modifying the set of transaction definitions; and

using the received events to generate new transactions in accordance with the modified set of transaction definitions.

6. The method as recited in claim 5, wherein the new transactions are generated without replaying the script.

7. The method as recited in claim 1, further comprising:

evaluating the transactions to assess the performance of the executed application.

17. The method of claim 1, wherein receiving the events comprises:

receiving at least one event from an external source that is separate from the script; and

receiving at least one event from execution of the script.

19. The method as recited in claim 1, wherein generating the transactions comprises mapping the received events to the actions specified by the transaction definitions.

8. A performance measurement system, comprising:

a memory to store a set of transaction declaration files, wherein each of the transaction declaration files defines a transaction including specifying transaction actions that correspond to a start point and an end point of the transaction, the start point and the end point being defined by rules in the respective transaction declaration file;

a processor to execute an event manager module to receive events associated with execution of an application in a computing system and to generate transactions by mapping the received events to the specified transaction actions, wherein the transactions provide a measurement of a performance of the application; and

an automation script stored in the memory, wherein the automation script contains script actions representative of recorded user interactions with the application, and wherein the set of transaction declaration files are stored in the memory separately from the script.

9. The system as recited in claim 8, wherein at least one of the transaction declaration files specifies a transaction action for a start point that is not directly initiated by any script action contained in the automation script.

10. The system as recited in claim 8, wherein at least one of the transaction declaration files specifies a transaction action that does not directly correspond to any script action contained in the automation script.

11. The system as recited in claim 8, wherein the processor is to execute the automation script to test performance of the application, and wherein at least some of the received events are dispatched by an event source other than the automation script, and at least another of the received events corresponds to an output of the automation script.

12. The system as recited in claim 11, further comprising a storage device to store the received events that are accessible by the event manager module for generation of the transactions.

13. The system as recited in claim 12, wherein the set of transaction declaration files is modified after the automation script is executed, and wherein the event manager module uses the stored events to generate transactions in accordance with the modified set of transaction declaration files without re-executing the automation script.

14. An article comprising a non-transitory computer readable storage medium to store instructions that when executed by a computer cause the computer to:

execute an automation script, wherein the automation script contains script actions representative of a user'"'"'s interactions with an application on a computing system;

receive events dispatched as a result of the execution of the automation script; and

generate transactions associated with execution of the application in accordance with a plurality of transaction definitions, wherein the transaction definitions are not contained within the automation script,

wherein each of the transaction definitions specifies transaction actions that correspond to a start point and an end point of the corresponding transaction, the start point and the end point specified by rules in the respective transaction definition, and wherein the transactions are generated by mapping the received events to the specified transaction actions.

15. The article as recited in claim 14, wherein the instructions further cause the computer to persist the received events to a storage device, and wherein the transactions are generated by mapping the stored received events to the specified transaction actions after the automation script has been executed.

16. The article as recited in claim 14, wherein at least one of the transaction definitions specifies a transaction action that corresponds to a start point that is not directly initiated by any script action contained in the automation script.

18. The article of claim 14, wherein receiving the events comprises:

receiving at least one event from an external source that is separate from the automation script; and

receiving at least one event from execution of the automation script.