A method, system and computer program product for recording and replaying a program execution in a client-server environment capable of supporting different client-server communication protocols. A common recorder of the exemplary embodiments identifies respective class files and libraries used by a client application to process client actions and data passed in client requests and server responses. The recorder stores class files and data in a replay file and later re-creates server loads and client actions based on the class files, data and client action results in the replay file during a replay of the execution.

Patent
   9009676
Priority
Apr 02 2010
Filed
Apr 02 2010
Issued
Apr 14 2015
Expiry
Dec 05 2032
Extension
978 days
Assg.orig
Entity
Large
6
63
EXPIRED
7. A non-transitory computer readable storage medium executed by a computer having program code embodied therein and operable to:
determine, by a common recorder, a type of the client application from a plurality of client application types, wherein the common recorder is configured to identify applications of each of the plurality of application types, the plurality of application types comprising: a Web service application type, a remote method invocation (RMI) application type, a common Object request broker architecture (CORBA) application type an enterprise javabeans (EJB) application type, and Internet Inter-Orb Protocol (IIOP) application type;
identify, by the common recorder, particular class files used by the client application to process client actions during the execution based on the determined type of the client application,
identify by the common recorder, data passed in client requests and data returned in server responses to be recorded using contents the identified class files;
record, by the common recorder, the identified class files and the identified data in a replay file; and
generate a server load based on the replay file during a replay execution by recreating actions of the client application using the data recorded in the replay file during a replay execution:
wherein the common recorder utilizes the particular class files of the client application to interact with the server,
wherein the common recorder interfaces with remote interface stubs of a plurality of client applications executed on at least one client, wherein, if the determined application the comprises the Web service application type the identifying the particular class files comprises identifying dynamic proxy class files of the client application;
wherein, if the determined application type comprises the remote method invocation (RMI) application type, the identifying the particular class files comprises identifying stub class tiles and skeleton class files of the client application, and
wherein, if the determined application type comprises one of the CORBA application type, EJB application type, and IIOP application type the identifying the particular class files comprises identifying “Ties” files of the client application.
1. A computer-implemented method for recording and replaying an execution of a client application in a client-server environment, comprising:
determining, by a common recorder, a type of the client application from a plurality of client application types, wherein the common recorder is configured to identify applications of each of the plurality of application types, the plurality of application types comprising: a Web service application type, a remote method invocation (RMI) application type, a common Object request broker architecture (CORBA) application type an enterprise javabeans (EJB) application type, and Internet Inter-Orb Protocol (IIOP) application type;
identifying, by the common recorder, particular class files used by the client application to process client actions during the execution based on the determined type of the client application,
identifying, by the common recorder, data passed in client requests and data returned in server responses to be recorded using contents the identified class files;
recording, by the common recorder, the identified class files and the identified data in a replay file; and
generating a server load based on the replay file by recreating actions of the client application using the data recorded in the replay file during a replay execution:
wherein the common recorder utilizes the particular class files of the client application to interact with the server,
wherein the common recorder interfaces with remote interface stubs of a plurality of client applications executed on at least one client,
wherein, if the determined application the comprises the Web service application type the identifying the particular class files comprises identifying dynamic proxy class files of the client application;
wherein, if the determined application type comprises the remote method invocation (RMI) application type, the identifying the particular class files comprises identifying stub class tiles and skeleton class files of the client application, and
wherein, if the determined application type comprises one of the CORBA application type, EJB application type, and IIOP application type the identifying the particular class files comprises identifying “Ties” files of the client application.
12. A common recorder for recording and replaying an execution of a client application in a client-server environment, comprising: a memory storing components; and a processor executing the stored components, the components comprising:
a component for determining a type of the client application from a plurality of client application types to process client actions and responses during the execution of the client application, wherein the common recorder is configured to identify applications of each of the plurality of application types, the plurality of application types comprising: a Web service application type, a remote method invocation (RMI) application type, a common Object request broker architecture (CORBA) application type an enterprise javabeans (EJB) application type, and Internet Inter-Orb Protocol (IIOP) application type;
a component for identifying particular class files used by the client application to process client actions during the execution based on the determined type of the client application,
a component for identifying data passed in client requests and data returned in server responses during the execution to be recorded using contents the identified class files;
a component for recording the identified class files and data in a replay file; and
a component for generating a server load based on the replay file by recreating actions of the client application using the data recorded in the replay file during a replay execution,
wherein the common recorder utilizes the particular class files of the client application to interact with the server,
wherein the common recorder interfaces with remote interface stubs of a plurality of client applications executed on at least one client,
wherein, if the determined application the comprises the Web service application type the identifying the particular class files comprises identifying dynamic proxy class files of the client application;
wherein, if the determined application type comprises the remote method invocation (RMI) application type, the identifying the particular class files comprises identifying stub class tiles and skeleton class files of the client application, and
wherein, if the determined application type comprises one of the CORBA application type, EJB application type, and IIOP application type the identifying the particular class files comprises identifying “Ties” files of the client application.
2. The method of claim 1, wherein the client requests include remote service and function calls initiated by the client application.
3. The method of claim 1, wherein the returned data include information for identifying the server.
4. The method of claim 3, wherein the server-identifying information includes a server IP address and a port number.
5. The method of claim 1, further comprising:
determining a method of passing the data in the client requests and in the server responses from a plurality of methods for passing the data,
wherein the plurality of methods of passing the data comprises remote service and function calls, remote socket calls, and HTTP function calls,
wherein if the determined method comprises the HTTP function calls, the identifying the data comprises identifying the client requests which include “GET” and “POST” function calls and the server responses which are HTTP responses,
wherein if the determined method comprises the remote socket calls, the identifying the data comprises identifying remote socket calls, and
wherein if the determined method comprises the remote service and function calls, the identifying the data comprises identifying call parameters.
6. The method of claim 1, wherein the client application is an HTTP application, the client requests include “GET” and “POST” function calls and the server responses are HTTP responses.
8. The non-transitory computer readable medium of claim 7, wherein the client requests include remote service and function calls initiated by the client application.
9. The non-transitory computer readable medium of claim 7, wherein the returned data include information for identifying the server.
10. The non-transitory computer readable medium of claim 9, wherein the server-identifying information includes a server IP address and a port number.
11. The non-transitory computer readable medium of claim 7, wherein the client application uses sockets in communicating with the server and the client requests include remote socket calls.
13. The common recorder of claim 12, wherein the client requests include remote service and function calls initiated by the client application.
14. The method of claim 1, wherein for different client application types different types of class files are provided, and based on the determined type of the client application, type of class files from the different types of class files are identified and searched for, wherein for different methods of passing data, different types of data are provided, and wherein based on a determined method type of passing data in the client requests and the server responses, a type of data from the different types of data is identified and searched for.

The invention relates generally to computer software development, and more particularly, to a common recording and replaying performance test tool capable of supporting different client-server protocols.

Record and replay is a technique that allows the execution of a software application to be recorded so that it can be played back at a later time and often in a different system environment. Record and replay is commonly used for performance testing in software development. In a client-server environment, record and replay performance test tools need to be concerned with the various protocols that the client and the server use to communicate with each other. In addition to the complexity and changing nature of communication protocols, each protocol typically has a unique set of requirements and interface components through which it interacts with the operating system. A record and replay performance test tool must support these unique requirements and work with the protocol interfaces in order to properly record and replay the execution of the application.

In a client-server environment, the client and the server can communicate with each other using one or more protocols like the Hypertext Transfer Protocol (HTTP), Java Remote Method Protocol (JRMP), Internet Inter-ORB Protocol (IIOP), Simple Object Access Protocol (SOAP), and Common Object Model (COM). The services associated with these protocols can be implemented in numerous ways, which make it difficult to have a single record and replay performance test tool that works with the different protocol implementations. In addition, the architecture of a client-server application varies from one operating environment to another depending on the type of the application. As a result, performance testing in such a client-server environment with a performance tool generally involves recording and replaying the actions that a user performs and the resulting processes.

Current recording tools typically provide a recording in a performance test either by using a proxy to intercept the user requests or creating client requests on the fly based on the user requests and the service definition language involved. Input to the program being recorded is sent through this proxy. The proxy examines client request and server response messages to capture the data that will be required for a replay of the program execution. In particular, the tool must examine network packets to extract relevant information and map this information to corresponding protocol messages being exchanged by the client and the server.

In a second type of record and replay tools, the tools must be able to recognize the service definition language being used in the communication between the client and the server and the operations defined by the service implementation of the respective communication protocol. Examples of the service definition languages include the Web Service Definition Language (WSDL) and the Interface Description Language (IDL). The tools then simulate client applications on the fly based on the client-server operation data that it captured.

A drawback of the above recording techniques is that the recording tools cannot be reused among the various protocols that the client and server use to communicate with each other because the interfaces and definitions are implemented differently in the protocols. In addition, the capturing of network packets during a client-server communications and mapping them to a particular protocol implementation will not work in all situations due to variations in the implementations of the underlying protocols.

For the recording performance test tools that are based on the service definition languages, tool developers face another challenge in the fact that not all applications and services use a definition language that allows data to be captured by the performance tools. In addition, this recording technique is more aligned towards Web services or Simple Object Access Protocol-based applications and generally cannot be applied to other types of service applications. As a result, with the emerging new client-server technologies, these performance test tools must be regularly updated with multiple recorders or protocol adapters that support new communication protocols and service implementations in order to be useful.

From the foregoing, it is appreciated that there still exists a need for a common record and replay performance test tool that is capable of recording a program execution and playing it back in different environments without the aforementioned drawbacks.

The invention relates to a method, system and computer program product for recording and replaying a program execution in a client-server environment by initially identifying class files associated with a client application for initiating client actions during the program execution and identifying data passed in client application requests and data returned in server responses. The identified class files and data are stored in a replay file. During a replayed execution, data in the replay file is used by the recording and replaying tool to generate server loads and recreate the client application processes.

The details of the exemplary embodiments of the invention, both as to its structure and operation, are described below in the Detailed Description section in reference to the accompanying drawings, in which like reference numerals refer to like parts. The Summary is intended to identify key features of the claimed subject matter, but it is not intended to be used to limit the scope of the claimed subject matter.

FIG. 1 is a block diagram of an exemplary data processing system in which aspects of the present invention might be implemented.

FIG. 2 is a block diagram illustrating an exemplary client-server computing environment in which aspects of the invention might be implemented.

FIG. 3 is a block diagram illustrating an exemplary embodiment of a record and replay system for a client-server environment according to aspects of the invention.

FIG. 4 is a block diagram illustrating an exemplary embodiment of a record and replay system for a Web service client-server environment, according to aspects of the invention.

FIG. 5 is a block diagram illustrating an exemplary embodiment of a record and replay system for a client-server environment in which the client application is a Remote Method Invocation (RMI) application, according to aspects of the invention.

FIG. 6 is a block diagram illustrating an exemplary embodiment of a record and replay system for a client-server environment in which the client application is a CORBA, EJB or IIOP application, according to aspects of the invention.

FIG. 7 is a high-level flow chart representing a process for recording and replaying an execution of a client application in a client-server environment, according to another exemplary embodiment of the invention.

FIG. 8 is a flow chart representing a detailed process for recording and replaying an execution of a client application in a client-server environment, according to yet another exemplary embodiment of the invention.

The invention relates to a method, system and computer program product for commonly recording and replaying a program execution in a client-server environment that supports different client-server communication protocols.

As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a method, system or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.

Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc. or any suitable combination of the foregoing.

Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

Aspects of the present invention are described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

The flowchart and block diagrams in the figures described below illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

Referring now to the drawings and in particular to FIG. 1, there is depicted a block diagram of a data processing system in which aspects of the present invention might be implemented. As shown, a data processing system 100 includes a processor unit 111, a memory unit 112, a persistent storage 113, a communications unit 114, an input/output unit 115, a display 116, and system bus 110. Computer programs are typically stored in persistent storage 113 until they are needed for execution, at which time the programs are brought into memory unit 112 so that they can be directly accessed by processor unit 111. Processor 111 selects a part of memory 112 to read and/or write by using an address processor 111 gives to memory 112 along with a request to read and/or write. Usually, the reading and interpretation of an encoded instruction at an address causes processor 111 to fetch a subsequent instruction, either at a subsequent address or some other address.

With reference now to FIG. 2, there is illustrated a block diagram of a representative client-server computing system 200 in which aspects of the invention might be implemented. The system 200 typically has multiple client applications 211 that communicate with a server 212 through a client-sever network 210. The clients 211 and server 212 might be hardware or software computer systems, or a combination thereof, that have functional components similar to those in FIG. 1. The clients 211 generally run client applications such as a Web browser for downloading data from a Web server represented by the server 212. In another example, the client application 211 might be a database application that submits database queries to a database server 212 to be processed by the server 212. A client 211 might communicate with the server 212 using a communication protocol like the Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), Java Remote Method Protocol (JRMP), Internet Inter-ORB Protocol (IIOP), Simple Object Access Protocol (SOAP), and Component Object Model (COM). The services between a client 211 and server 212 can be implemented in numerous ways based on the protocol specifications.

FIG. 3 is a block diagram illustrating an exemplary embodiment of a recording and replaying system 300 for a client-server environment according to aspects of the invention. The system 300 includes a sever 312 and a client 314 that communicate through client requests 319 and server responses 320. A client application 315, such as a Web service application, runs on the client 314 and uses class files 313 to process client actions generated by the client application 315. The type of class files 313 depends on the particular type of the client application 315. For example, if the client application 315 is a Java application, then the class files 313 include Java class files that the client application 315 would need during its execution. If the client application 315 is a Web application, then the class files 313 include remote Web services and remote functions calls invoked by the Web application. The client application 315 has a Remote Interface Stub 316 for interfacing with a common recorder 317 and providing aspects of the invention as described below in reference to FIGS. 4-8. The common recorder 317 might run on the client 314, server 312 or another computer connected to the client 314.

During interactions between the client application 315 and the server 312, the common recorder 317 identifies particular class files 313 that the client application 315 needs for initiating and processing client actions, data passed by the client application 315 in the client requests 319, and data returned by the server 312 in the server responses 320 to the client 314. The common recorder 317 stores the identified class files 313 and data from the client requests 319 and server responses 320 in a replay file 318. Similarly to the common recorder 317, the replay file 318 might reside on the client 314, the server 312 or another computer connected to the client 314. During a later replay of the client-server interactions in another system environment, the common recorder 317 will use the data recorded in the replay file 318 to recreate the client actions, client processes and their respective results.

The class files 313 include remote method calls and function calls invoked by the client application as well as stub files, skeleton files and proxies that hold the logic for networks and input/output necessary to complete the remote calls. The data passed in client requests 319 and server responses 320 include information for identifying the server like the server's IP address and port number, data related to the remote calls and data passed in the remote call parameters. The type of data captured by the common recorder is determined from the contents of the class files. In the exemplary embodiments of the invention, the replay file 318 is a normal output text file that includes the class files, stub files, skeleton files, remote method and function calls, and data passed in the remote and function calls as captured by the common recorder.

FIG. 4 is a block diagram illustrating an exemplary embodiment of a record and replay system 400 for a Web service client-server environment. The client 414 and server 412 are similar to those described with reference to FIG. 3. A Web service client application 415, like a Web browser, runs on the client 414 and typically uses dynamic proxy class files 413 to process client actions that are initiated by the Web client application 415. The dynamic proxy class files 413 are client proxy class files that hold the definitions and functions of the remote service calls invoked by the client application 415.

FIG. 5 is a block diagram illustrating an exemplary embodiment of a recording and replaying system 500 for a client-server environment in which the client application 515 is a Remote Method Invocation (RMI) application. The client 514 and server 512 are similar to those described with reference to FIG. 3. An RMI-type client application 515, such as a Java application used for invoking remote methods in a server, runs on the client 514 and uses stub and skeleton class files 513 to process client actions initiated by the RMI client application 515. The stub and skeleton class files 513 include remote functions that are defined for interacting with the server 512. These files also have the network definitions, inputs, outputs and sockets used by the RMI client application 515.

FIG. 6 is a block diagram illustrating an exemplary embodiment of a recording and replaying system 600 for a client-server environment in which the client application 615 is a Common Object Request Broker Architecture (CORBA) application, Enterprise JavaBeans (EJB) application or Internet Inter-Orb Protocol (IIOP) application. CORBA is a mechanism in software for normalizing method call semantics between application objects that reside either in the same address space of the application or a remote address space (e.g., a remote host on a network). CORBA enables software written in multiple computer languages and running on multiple computers to work together on multiple platforms. The Enterprise JavaBeans (EJB) protocol is a managed, server-side component architecture for modular construction of enterprise applications. The Internet Inter-Orb Protocol (IIOP) is an implementation of the General Inter-ORB Protocol (GIOP) for TCP/IP. GIOP is an abstract protocol by which object request brokers (ORBs) communicate in distributed computing environments.

The client 614 and server 612 in FIG. 6 are similar to those described with reference to FIG. 3. A CORBA-type client application 615, such as a remote application that allows communications between two or more CORBA objects, runs on the client 614 and might require certain “Ties” files as well as class files 613 to process client actions initiated by the client application 615. The “Ties” files 613 for a COBRA-type application include functional code similar to that of the stub and skeleton class files in the case of a RMI application. The client application 615 might also be an EJB-type or an IIOP-type client application. Since CORBA, EJB and IIOP are basically different implementations of the same client-server communications protocol, the “Ties” files and class files for them that are examined and captured by the common recorder are generally similar in their definitions and contents.

Refer now to FIG. 7 which illustrates a high-level flow chart representing a process for recording and replaying an execution of a client application in a client-server environment by a common recorder, according to an exemplary embodiment of the invention. At block 711, the common recorder 317 identifies class files that the client application 315 needs to process client actions initiated by the client 314. The common recorder 317 further examines client requests 319 and server responses 320 to identify data passed in these requests and responses, per block 712. At block 713, the common recorder 317 stores the required class files 313 and identified data in a replay file 318 that would be used by a recording and replaying performance test tool during a replay of the program execution. During the replayed execution, the common recorder 317 recreates the same sever loads that the server 312 processed during the recorded execution, based on data recorded in the replay file 318. The server load generation is represented by block 714 of FIG. 7.

FIG. 8 is a flow chart representing a detailed process for recording and replaying an execution of a client application 315 in a client-server environment by a common recorder 317, according to an exemplary embodiment of the invention. At block 811, the common recorder 317 determines the type of client application 315 that is running in the client computer 314 in which the application execution is to be recorded by the recorder 317. Based on the client application information, the common recorder 317 determines the relevant class files that the application 315 would need to initiate its actions during execution, as represented by blocks 813-816. For example, if the client application 315 is a Web application, then in the exemplary embodiments of the invention, the common recorder 317 identifies the dynamic class files used to process client actions, as shown by block 813. If the client application 315 includes Remote Invocation Method (RMI) function calls, then the common recorder 317 identifies the stub class files and skeleton class files used in by the RMI function calls that the client application 315 invokes, per block 814. For a client application 315 based on the CORBA, EJB or IIOP protocol implementations, the common recorder 317 identifies the “Ties” files associated with the protocol implementations, as shown by block 815. Other protocols could similarly be supported by the common recorder 317, as represented in block 816, by identifying the libraries and function calls used by the client application 315 to initiate client actions during its communication with the server 312.

The common recorder 317 further identifies data included in the requests that the client application 315 sends to the server 312 as well as data returned by the server 312 in its responses to the client requests. At block 817, the common recorder 317 determines the methods that the client 314 and server 312 use to pass data between them based on client requests 319 and server responses 320. If the client application 315 invokes remote service and function calls, then the common recorder 317 examines the stubs, skeleton class files along with the main client class files, per block 818. If the client application 315 invokes remote socket calls for communicating with the server 312, then the common recorder 317 of the exemplary embodiments identifies the socket-ins and socket-outs associated with remote calls to be captured, as shown by block 819. For HTTP function calls invoked by a Web application or Web service, the common recorder 317 examines and captures data associated with the GET and POST requests initiated by the client application 315, in block 820. Other methods for passing data between the client 314 and the server 312 could similarly be supported by identifying remote function calls from the client class files and any proxy files associated with the methods and recording data passed in the function calls, per block 821.

Continuing at block 822 of FIG. 8 where the client 314 and the server 312 communicate with each other by exchanging client requests 319 and server responses 320. During the client-server interactions, the common recorder 317 stores the identified class files and data in a replay file 318, per block 823. The recorded data in the file 318 is then used by the common recorder 317 to re-create the client application actions and results during a replayed execution, as shown by block 824. In addition, the common recorder 317 re-creates server work loads to be processed by the server 312 during the replay, per block 825.

The subject matter described above is provided by way of illustration only and should not be construed as limiting. Various modifications and substitutions of the described components and operations can be made by those skilled in the art without departing from the spirit and scope of the present invention defined in the following claims, the scope of which is to be accorded the broadest interpretation so as to encompass such modifications and equivalent structures. As will be appreciated by those skilled in the art, the systems, methods, and procedures described herein can be embodied in a programmable computer, computer executable software, or digital circuitry. The software can be stored on computer readable media. For example, computer readable media can include a floppy disk, RAM, ROM, hard disk, removable media, flash memory, a “memory stick”, optical media, magneto-optical media, CD-ROM, etc.

Chua, Stevenson, Dash, Rakesh Kumar

Patent Priority Assignee Title
10067848, Jul 27 2016 Meta Platforms, Inc Methods and systems for benchmarking web browser performance
10187283, Nov 19 2013 TELEFONAKTIEBOLAGET LM ERICSSON PUBL Testing the performance of a layer 3 proxy device using traffic amplification
10983856, Jun 28 2019 Microsoft Technology Licensing, LLC Identifying root causes of performance issues
11429507, Jun 10 2020 General Electric Company Performance benchmarking for real-time software and hardware
11586533, Sep 21 2020 International Business Machines Corporation Creating a mock for an integration flow
9477579, Aug 09 2013 SHENZHEN XINGUODU TECHNOLOGY CO , LTD Embedded software debug system with partial hardware acceleration
Patent Priority Assignee Title
5774717, Dec 15 1995 SAP SE Method and article of manufacture for resynchronizing client/server file systems and resolving file system conflicts
5960436, Aug 29 1997 International Business Machines Corp. Transaction compaction for replay of transactions from client to server
5974572, Oct 15 1996 MICRO FOCUS LLC Software system and methods for generating a load test using a server access log
6119247, Jun 22 1998 International Business Machines Corporation Remote debugging of internet applications
6145121, Apr 17 1997 Washington, University of; UNIVERISTY OF WASHINGTON Trace based method for the analysis, benchmarking and tuning of object oriented databases and applications
6249886, Oct 17 1997 Computer system and computer implemented process for performing user-defined tests of a client-server system with run time compilation of test results
6253228, Mar 31 1997 Apple Inc Method and apparatus for updating and synchronizing information between a client and a server
6286046, Dec 22 1997 International Business Machines Corporation Method of recording and measuring e-business sessions on the world wide web
6311327, Mar 02 1998 SHENZHEN XINGUODU TECHNOLOGY CO , LTD Method and apparatus for analyzing software in a language-independent manner
6321263,
6463578, Nov 23 1999 International Business Machines Corporation Systems, methods and computer program products for debugging java server page files using compiled java class file modifications
6543011, Jul 15 1999 International Business Machines Corporation Method for event recording in java
6567767, Sep 19 2000 Unisys Corporation Terminal server simulated client performance measurement tool
6587969, Jun 22 1998 HEWLETT-PACKARD DEVELOPMENT COMPANY, L P Software system and methods for testing the functionality of a transactional server
6609084, Aug 10 2001 QNAP SYSTEMS, INC Data transfer performance measuring system and method
6631345, Aug 12 1999 GLOBALFOUNDRIES Inc Recording, storing, and emulating user interaction events
6694288, Aug 06 2001 MICRO FOCUS LLC System and method for automated analysis of load testing results
6721941, Aug 27 1996 JPMORGAN CHASE BANK, N A , AS SUCCESSOR AGENT Collection of timing and coverage data through a debugging interface
6763380, Jan 07 2000 JPMORGAN CHASE BANK, N A , AS SUCCESSOR AGENT Methods, systems and computer program products for tracking network device performance
6862711, Aug 03 1999 International Business Machines Corporation Method and apparatus in a data processing system for providing an interface for non-intrusive observable debugging, tracing, and logging data from execution of an application
6865692, Oct 27 2000 Oracle International Corp Enterprise test system having program flow recording and playback
6918106, Jul 31 2000 Oracle America, Inc Method and apparatus for collocating dynamically loaded program files
7010532, Dec 31 1997 International Business Machines Corporation Low overhead methods and apparatus for shared access storage devices
7072951, Oct 03 2000 Oracle America, Inc HTTP transaction monitor with capacity to replay in debuggings session
7171588, Oct 27 2000 Oracle International Corp Enterprise test system having run time test object generation
7191441, Aug 06 2001 International Business Machines Corporation Method and apparatus for suspending a software virtual machine
7257516, Sep 20 2001 GOOGLE LLC Method, apparatus, and program for eliminating thread skew in multithreaded performance benchmarks
7269603, Dec 17 2003 Sprint Communications Company L.P.; SPRINT COMMUNICATIONS COMPANY, L P Enterprise naming service system and method
7376917, Aug 25 2003 XILINX, Inc. Client-server semiconductor verification system
7506047, Mar 30 2001 BMC SOFTWARE, INC Synthetic transaction monitor with replay capability
7543000, Jan 23 2006 SAP SE Method and system combining state replication and operational-replay synchronization
7552424, Oct 06 2003 SAP SE Apparatus and method for identifying a system under test
7613597, Jan 20 2006 International Business Machines Corporation Non-intrusive method for simulation or replay of external events related to an application process, and a system implementing said method
7752604, Sep 02 2004 International Business Machines Corporation Method, system and program product for recording and replaying target service interaction data
7809728, Jul 09 2003 Canon Kabushiki Kaisha Recording/playback apparatus and method
8001531, Jul 30 2007 Nvidia Corporation Translation of a shader assembly language binary for debugging a graphics application running on a remote device
8024299, Oct 20 2006 Oracle International Corporation Client-driven functionally equivalent database replay
8145705, Mar 18 2003 Red Hat, Inc System and method for record and playback of collaborative web browsing session
8185910, Aug 27 2008 Method and system for testing interactions between web clients and networked servers
8639796, Dec 16 2004 Hewlett-Packard Development Company, L.P.; HEWLETT-PACKARD DEVELOPMENT COMPANY, L P Monitoring the performance of a streaming media server using server-side and client-side measurements
20020065911,
20020156881,
20030033118,
20030055883,
20030208476,
20040078684,
20040107415,
20040268314,
20060047496,
20070288619,
20080065702,
20080097960,
20080141221,
20090037914,
20090089404,
20100005455,
20100058366,
20100115496,
20110225569,
JP2000200230,
JP2002073431,
JP2003173277,
WO2005071560,
///
Executed onAssignorAssigneeConveyanceFrameReelDoc
Mar 31 2010CHUA, STEVENSONInternational Business Machines CorporationASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS 0241820371 pdf
Apr 01 2010DASH, RAKESH KUMARInternational Business Machines CorporationASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS 0241820371 pdf
Apr 02 2010International Business Machines Corporation(assignment on the face of the patent)
Date Maintenance Fee Events
Dec 03 2018REM: Maintenance Fee Reminder Mailed.
May 20 2019EXP: Patent Expired for Failure to Pay Maintenance Fees.


Date Maintenance Schedule
Apr 14 20184 years fee payment window open
Oct 14 20186 months grace period start (w surcharge)
Apr 14 2019patent expiry (for year 4)
Apr 14 20212 years to revive unintentionally abandoned end. (for year 4)
Apr 14 20228 years fee payment window open
Oct 14 20226 months grace period start (w surcharge)
Apr 14 2023patent expiry (for year 8)
Apr 14 20252 years to revive unintentionally abandoned end. (for year 8)
Apr 14 202612 years fee payment window open
Oct 14 20266 months grace period start (w surcharge)
Apr 14 2027patent expiry (for year 12)
Apr 14 20292 years to revive unintentionally abandoned end. (for year 12)