US20060265430A1 - Transactions matching for multi-tier architectures - Google Patents
Transactions matching for multi-tier architectures Download PDFInfo
- Publication number
- US20060265430A1 US20060265430A1 US11/134,568 US13456805A US2006265430A1 US 20060265430 A1 US20060265430 A1 US 20060265430A1 US 13456805 A US13456805 A US 13456805A US 2006265430 A1 US2006265430 A1 US 2006265430A1
- Authority
- US
- United States
- Prior art keywords
- end transaction
- transaction type
- type
- types
- server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/02—Topology update or discovery
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/12—Shortest path evaluation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/535—Tracking the activity of the user
Definitions
- the present invention relates to the field of application performance analysis and more particularly to performance analysis of networked multi-tier applications.
- SniffersTM and other devices are used to trace individual packets passing through the network to identify bottlenecks, routing problems, packet loss, etc.
- this approach for detecting network problems and analyzing application performance is limited to direct interactions between a client and a server. For multi-tier applications, such devices cannot be utilized to monitor and analyze interactions between different tiers.
- a client sends a request to an application server.
- the application server processes the client request, and in response, sends one or more requests to a database server for preparing a response to the client.
- communications between the client and the application server are separate from the communications between the application server and the database server; that is, they do not share any network packets.
- the application server is serving many concurrent client requests, it is difficult to ascertain which server requests made to the database server were caused by a particular client request.
- determining which server request was caused by which client request is an important factor for analyzing application performance.
- Some techniques used to analyze the performance of a multi-tier application include operating such an application in a controlled testing environment, where one client request is being processed by the application at a time. But such techniques may not be able to accurately ascertain that the downstream activity is actually caused by the observed client requests. Moreover, many problems associated with multi-tier applications do not appear except in a high-volume production environment, where many client requests are being processed at a time. Thus, processing one client request at a time may not be a feasible solution for analyzing a multi-tier application's performance. Other techniques establish the relationships between the transactions observed on both sides of an application based on knowledge of the application's complete model or internal structure. However, the feasibility of such techniques is usually limited to simple applications.
- the present invention is a system and method for mapping transactions on both sides of a front-end server.
- one or more types of front-end transactions and one or more types of back-end transactions are identified.
- the times of occurrence of these transactions are identified.
- Possible associations between the identified front-end transaction types and the back-end transaction types are then built based on a time constraint. For example, a back-end transaction type is associated with a front-end transaction type if the back-end transaction type starts after the front-end transaction type has started and ends before the front-end transaction type has ended.
- each back-end transaction type is caused by one front-end transaction type and the number of associations between a given front-end transaction type and a given back-end transaction type remains constant. For example, if a back-end transaction type occurs during an instance of a front-end transaction type but does not occur during another instance of the front-end transaction type, then the association between the back-end transaction type and the front-end transaction type is eliminated.
- a frequency of occurrence of each front-end transaction type and a frequency of occurrence of each back-end transaction type with respect to the front-end server are determined.
- One or more linear relationships are then established to express the frequency of each back-end transaction type as a linear combination of frequencies of one or more front-end transaction types.
- the established one or more linear relationships represent a mapping of front-end transaction types and back-end transaction types.
- FIG. 1 is an illustration of one example of a network environment in which the present invention can operate.
- FIG. 2 is an exemplary diagram that may result from observing transactions on both sides of a front-end server.
- FIG. 3 is an exemplary graph depicting a relationship between front-end requests and back-end requests.
- FIG. 4 is a flowchart illustrating a process implemented by one embodiment of the present invention for mapping transactions on both sides of a front-end server without knowledge of the front-end server's internal structure.
- FIG. 5 is a timing diagram illustrating exemplary sequences of front-end and back-end requests.
- FIG. 6 is a timing diagram illustrating other exemplary sequences of front-end and back-end requests.
- FIG. 7 is a flowchart illustrating a process implemented by another embodiment of the present invention for mapping transactions on both sides of a front-end server without knowledge of the front-end server's internal structure.
- FIG. 8 is an exemplary graph showing transaction frequencies of given front-end transaction types and back-end transaction types.
- Certain aspects of the present invention include process steps and instructions described herein in the form of an algorithm. It should be noted that the process steps and instructions of the present invention could be embodied in software, firmware or hardware, and when embodied in software, could be downloaded to reside on and be operated from different platforms used by a variety of operating systems.
- the present invention also relates to an apparatus for performing the operations herein.
- This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer.
- a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, application specific integrated circuits (ASICs), or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.
- the computers referred to in the specification may include a single processor or may be architectures employing multiple processor designs for increased computing capability.
- FIG. 1 is an illustration of one example of a network environment 100 in which the present invention can operate.
- a client 102 sends a front-end request 103 to a front-end server 104 such as an application server. Responsive to the received front-end request 103 , the front-end server 104 submits one or more back-end requests to a back-end server 106 such as a database server. The front-end server 104 further receives from the back-end server 106 one or more responses to the submitted back-end requests. Based on the responses from the back-end server 106 , the front-end server 104 prepares a response 107 to the front-end request 103 and provides the response 107 to the client 102 .
- an agent residing on the front-end server 104 observes the front-end requests received from the client 102 and the back-end requests submitted to the back-end server 106 .
- the agent is adapted to identify the type and time range of each transaction on either side of the front-end server 104 .
- a transaction is a request-response pair.
- the front-end request 103 and the response 107 constitute a single transaction, and the time range of the transaction is measured between the time the front-end server 104 receives the request 103 from the client 102 and the time the front-end server 104 sends the response 107 to the client 102 .
- a transaction type is determined using an input defined by an end user.
- a transaction type may be defined by a specific protocol.
- HTTP hypertext transfer protocol
- the transaction type for hypertext transfer protocol may be the uniform resource locator (URL), a part of the URL that defines a specific command, a set of key-value pairs from headers of a Hypertext Transfer Protocol (HTTP) POST request, etc.
- HTTP Hypertext Transfer Protocol
- the transaction type for database servers may be described by a structured query language (SQL) statement, etc.
- SQL structured query language
- the request or transaction type may be derived from the content of the request or transaction.
- the front-end server 104 is assumed to work as a deterministic black box; that is, each front-end request of a given type generates a fixed sequence of back-end requests.
- the same sequence of back-end requests (having the same number of requests and the same types across different occurrences of sequences) will be generated by each occurrence of the given front-end request type. For example, if an instance of front-end request type B generates an instance of back-end request type a and an instance of back-end request type b in that order, other instances of front-end request type B will also generate instances of back-end request types a and b in that order.
- the agent residing in the front-end server 104 may observe multiple, possibly overlapping in time, front-end requests and the resulting back-end requests. In addition, some of the back-end requests may not have been caused by any of the front-end requests.
- An embodiment of the invention determines which front-end request, if any, generates a given back-end request.
- FIG. 2 is an exemplary diagram that may result from observing the transactions on both sides of the front-end server 104 .
- Solid arrows on the right of the diagram represent back-end requests that may have been resulted from the front-end request represented by the solid arrow on the left of the diagram, based on time consideration.
- the back-end requests represented by the solid arrows start after the start of, and end before the end of, the front-end request represented by the solid arrow.
- some of these back-end requests represented by the solid arrows may have resulted from other front-end requests (represented by the dashed arrows) in the same time range.
- the relationship shown in FIG. 2 may be represented by the graph depicted in FIG. 3 . In FIG.
- the front-end request types are shown as numbers and back-end request types are shown as letters.
- a system of constraints can be formulated as follows: remove some minimal number of the edges in the graph so that (1) there is no more than one edge coming into each node representing a back-end request type (because each back-end request type is generated by one front-end request type) and (2) for each front-end request type, the number and types of generated back-end request types remain the same.
- FIG. 4 illustrates a process for mapping transactions on both sides of the front-end server 104 without knowledge of the internal structure of the front-end server 104 , according to an embodiment of the invention.
- both front-end transactions and back-end transactions and their individual timings are observed.
- possible associations between front-end transaction types and back-end transaction types are built based on time constraints.
- a system of constraints is built such that (1) each back-end transaction is caused by one front-end transaction and (2) the number of associations between front-end transactions of a given type and back-end transactions of a given type remain the same.
- one or more associations between the front-end transactions and the back-end transactions are eliminated so as to satisfy the system of constraints. For example, the least possible number of associations between the front-end transactions and the back-end transactions are eliminated to satisfy the system of constraints
- An algorithm is developed to determine which front-end request type generates a given back-end request type based on the system of constraints.
- N front-end requests and K back-end requests are observed.
- the number of front-end requests is denoted as CR n
- the number of back-end requests is denoted as SR k .
- the front-end request type is denoted as CT n
- the back-end request type is denoted as ST k .
- a matrix of Boolean variables x nk is introduced.
- the Boolean variable x nk has the value of 1 if front-end request n may have caused back-end request k.
- the Boolean variable x nk has the value of 0 if front-end request n may not have caused back-end request k.
- the matrix of Boolean variables x nk is initialized according to a temporal sequence; that is, x nk is set to the value of 1 if the k-th back-end request starts after the start of, and ends before the end of, the n-th front-end request.
- each back-end request is attributed to no more than one front-end request, a set of inequalities on the values x nk is imposed; namely, ⁇ k ⁇ x nk ⁇ 1.
- a matrix of integer variables y nk is defined, where the first index n ranges from 1 to the number of front-end request types, and the second index k ranges from 1 to the number of back-end request types.
- the value y nk provides the number of back-end requests of type ST k generated by each front-end request of type CT n .
- the Y matrix is initialized as follows: for each front-end request of type CT n , count the number of back-end requests of each type ST k that may have been caused by the front-end request z k . If the n-th row of the Y matrix has not been initialized, z k is stored in the n-th row of the Y matrix. Otherwise, y nk is replaced with the minimum of y nk or z k .
- a front-end request of type A generates, for example, two back-end requests of type a
- another front-end request of type A will generate two back-end requests of type a as well. Accordingly, if more than two back-end request candidates are observed in response to a front-end request of type A, these back-end requests will eventually be eliminated as candidates except two back-end requests of type a.
- the complete system of equations may then be solved by identifying those equations to the elements of the matrix X, where the sum is 0, and by setting the corresponding x ij to 0. For those x ij not set in the solutions, trial and error may be used to solve the equations. Even though the number of trials may be large, but each step involves a simple arithmetic operation (e.g., summation). Therefore, the execution time is expected to be reasonable. Further improvements to the process of obtaining solution can be implemented to improve efficiency.
- FIG. 5 is a timing diagram illustrating exemplary sequences of front-end and back-end requests.
- a front-end request can cause many back-end requests, and a back-end request can be caused by one front-end request.
- front-end requests are represented by capitalized letters, and back-end requests are represented by lower case letters. The numerals represent particular instances of requests.
- back-end request type a may have been caused by front-end request type A because back-end request type a starts after the start of, and ends before the end of, front-end request type A. It can be determined at time period 1 that back-end request type a cannot have been caused by front-end request type B because back-end request type a starts before the start of front-end request type B. Furthermore, at time period 1 , it cannot be determined if back-end request type b is caused by front-end request type A or front-end request type B. This is because back-end request type b starts after both front-end request types A and B have started and ends before both front-end request types A and B have ended.
- back-end request type c may have been caused by front-end request type B. This is because back-end request type c starts after front-end request type A has ended (thus cannot be caused by front-end request type A), but starts after the start of, and ends before the end of, front-end request type B.
- back-end request type c may have been caused by front-end request type B because it again starts after the start of, and ends before the end of, front-end request type B.
- back-end request type b cannot be caused by front-end request type B because an instance of back-end request type b does not occur during this particular instance of front-end request type B.
- the same sequence of back-end requests will be generated by each occurrence of a given front-end request type.
- back-end request type b may have been caused by front-end request type A.
- back-end request type b may have been caused by front-end request type A since it starts after the start of, and ends before the end of, this particular instance of front-end request type A. It can also be determined that back-end request type a cannot be caused by front-end request type A because an instance of back-end request type a does not occur during this instance of front-end request type A. Thus, back-end request type a is not caused by either front-end request type A or front-end request type B; it may have occurred due to activity of the server not related to any front-end request.
- X (c1,B1) X (c2,B2) .
- front-end request type B may cause back-end request type c.
- X (b1,A1) x (b2,A2) .
- the variable X (b1,B1) can be determined to be 0 because there is not an occurrence of back-end request type a during the occurrence of front-end request type B2.
- front-end request type A may cause back-end request type b.
- front-end request type A cannot cause back-end request type a because there is not an occurrence of back-end request type a during the occurrence of front-end request type A2.
- FIG. 6 is a timing diagram illustrating other exemplary sequences of front-end and back-end requests. Again, front-end requests are represented by capitalized letters, and back-end requests are represented by lower case letters. As shown in FIG. 6 , two instances of front-end request type B and two instances of back-end request type b occur during time period 5 . It cannot be determined which instance of back-end request type b is caused by which instance of front-end request type B. However, since both instances of back-end request type b start after the start of, and end before the end of, both instances of front-end request type B, it can be determined that back-end request type b may have been caused by front-end request type B. For analyzing application performance, it is not important to determine which specific instance of a given front-end request type causes which specific instance of a given back-end request type.
- FIG. 7 illustrates a process for mapping transactions on both sides of the front-end server 104 without knowledge of the internal structure of the front-end server 104 , in accordance with an alternative embodiment of the invention.
- both front-end transactions and back-end transactions are observed. For example, the statistics of both front-end transactions and back-end transactions are observed.
- a frequency of occurrence of each front-end transaction type and a frequency of occurrence of each back-end transaction type are established.
- a system of linear relationships is established to express the transaction frequency of each back-end transaction type as a linear combination of transaction frequencies of the front-end transaction types.
- the linear combination of transaction frequencies thus expresses a mapping between a front-end transaction type and one or more back-end transaction types.
- This alternative embodiment of the invention even though may provide less accurate results because it is statistical in nature, has the advantages of providing an incremental model and incurring less computation.
- FIG. 8 illustrates an exemplary graph showing transaction frequencies of front-end transaction types A and B and back-end transaction types a and b.
- a 1 , b 1 , a 2 , and b 2 are the values determined from the data and representing the mapping between front-end and back-end transactions.
- a 1 determines how many transactions of type a result from each transaction of type A. These values, therefore, constitute the output (end result) of the algorithm.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
A system and method for mapping transactions on both sides of a front-end server. One or more types of front-end transactions and one or more types of back-end transactions are identified. In addition, the times of occurrence of these transactions are identified. Possible associations between the identified front-end transaction types and the back-end transaction types are then built based on a time constraint. One or more of these associations are then eliminated such that each back-end transaction type is caused by one front-end transaction type and the number of associations between a given front-end transaction type and a given back-end transaction type remains constant.
Description
- The present invention relates to the field of application performance analysis and more particularly to performance analysis of networked multi-tier applications.
- Network problems manifest themselves to end users as degradation of application performance. To detect such network problems, Sniffers™ and other devices are used to trace individual packets passing through the network to identify bottlenecks, routing problems, packet loss, etc. However, this approach for detecting network problems and analyzing application performance is limited to direct interactions between a client and a server. For multi-tier applications, such devices cannot be utilized to monitor and analyze interactions between different tiers.
- As an example, a client sends a request to an application server. The application server processes the client request, and in response, sends one or more requests to a database server for preparing a response to the client. In this scenario, communications between the client and the application server are separate from the communications between the application server and the database server; that is, they do not share any network packets. Thus, if the application server is serving many concurrent client requests, it is difficult to ascertain which server requests made to the database server were caused by a particular client request. However, determining which server request was caused by which client request is an important factor for analyzing application performance.
- Some techniques used to analyze the performance of a multi-tier application include operating such an application in a controlled testing environment, where one client request is being processed by the application at a time. But such techniques may not be able to accurately ascertain that the downstream activity is actually caused by the observed client requests. Moreover, many problems associated with multi-tier applications do not appear except in a high-volume production environment, where many client requests are being processed at a time. Thus, processing one client request at a time may not be a feasible solution for analyzing a multi-tier application's performance. Other techniques establish the relationships between the transactions observed on both sides of an application based on knowledge of the application's complete model or internal structure. However, the feasibility of such techniques is usually limited to simple applications.
- What is needed is a technique for effectively analyzing the performance of a multi-tier application without knowledge of the application's internal structure.
- The present invention is a system and method for mapping transactions on both sides of a front-end server. According to an embodiment of the invention, one or more types of front-end transactions and one or more types of back-end transactions are identified. In addition, the times of occurrence of these transactions are identified. Possible associations between the identified front-end transaction types and the back-end transaction types are then built based on a time constraint. For example, a back-end transaction type is associated with a front-end transaction type if the back-end transaction type starts after the front-end transaction type has started and ends before the front-end transaction type has ended. One or more of these associations are then eliminated such that each back-end transaction type is caused by one front-end transaction type and the number of associations between a given front-end transaction type and a given back-end transaction type remains constant. For example, if a back-end transaction type occurs during an instance of a front-end transaction type but does not occur during another instance of the front-end transaction type, then the association between the back-end transaction type and the front-end transaction type is eliminated.
- In an alternative embodiment of the invention, a frequency of occurrence of each front-end transaction type and a frequency of occurrence of each back-end transaction type with respect to the front-end server are determined. One or more linear relationships are then established to express the frequency of each back-end transaction type as a linear combination of frequencies of one or more front-end transaction types. The established one or more linear relationships represent a mapping of front-end transaction types and back-end transaction types.
- The features and advantages described in the specification are not all inclusive and, in particular, many additional features and advantages will be apparent to one of ordinary skill in the art in view of the drawings, specification, and claims. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the invention subject matter.
-
FIG. 1 is an illustration of one example of a network environment in which the present invention can operate. -
FIG. 2 is an exemplary diagram that may result from observing transactions on both sides of a front-end server. -
FIG. 3 is an exemplary graph depicting a relationship between front-end requests and back-end requests. -
FIG. 4 is a flowchart illustrating a process implemented by one embodiment of the present invention for mapping transactions on both sides of a front-end server without knowledge of the front-end server's internal structure. -
FIG. 5 is a timing diagram illustrating exemplary sequences of front-end and back-end requests. -
FIG. 6 is a timing diagram illustrating other exemplary sequences of front-end and back-end requests. -
FIG. 7 is a flowchart illustrating a process implemented by another embodiment of the present invention for mapping transactions on both sides of a front-end server without knowledge of the front-end server's internal structure. -
FIG. 8 is an exemplary graph showing transaction frequencies of given front-end transaction types and back-end transaction types. - A preferred embodiment of the present invention is now described with reference to the figures where like reference numbers indicate identical or functionally similar elements. Also in the figures, the left most digit of each reference number corresponds to the figure in which the reference number is first used.
- Reference in the specification to “one embodiment” or to “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiments is included in at least one embodiment of the invention. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment.
- Some portions of the detailed description that follows are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps (instructions) leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic or optical signals capable of being stored, transferred, combined, compared and otherwise manipulated. It is convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. Furthermore, it is also convenient at times, to refer to certain arrangements of steps requiring physical manipulations of physical quantities as modules or code devices, without loss of generality.
- It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing” or “computing” or “calculating” or “determining” or “displaying” or “determining” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system memories or registers or other such information storage, transmission or display devices.
- Certain aspects of the present invention include process steps and instructions described herein in the form of an algorithm. It should be noted that the process steps and instructions of the present invention could be embodied in software, firmware or hardware, and when embodied in software, could be downloaded to reside on and be operated from different platforms used by a variety of operating systems.
- The present invention also relates to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, application specific integrated circuits (ASICs), or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus. Furthermore, the computers referred to in the specification may include a single processor or may be architectures employing multiple processor designs for increased computing capability.
- The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may also be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will appear from the description below. In addition, the present invention is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the present invention as described herein, and any references below to specific languages are provided for disclosure of enablement and best mode of the present invention.
- In addition, the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter. Accordingly, the disclosure of the present invention is intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.
-
FIG. 1 is an illustration of one example of anetwork environment 100 in which the present invention can operate. As shown, aclient 102 sends a front-end request 103 to a front-end server 104 such as an application server. Responsive to the received front-end request 103, the front-end server 104 submits one or more back-end requests to a back-end server 106 such as a database server. The front-end server 104 further receives from the back-end server 106 one or more responses to the submitted back-end requests. Based on the responses from the back-end server 106, the front-end server 104 prepares aresponse 107 to the front-end request 103 and provides theresponse 107 to theclient 102. - In an embodiment of the invention, an agent residing on the front-
end server 104 observes the front-end requests received from theclient 102 and the back-end requests submitted to the back-end server 106. The agent is adapted to identify the type and time range of each transaction on either side of the front-end server 104. A transaction is a request-response pair. Thus, in the example illustrated inFIG. 1 , the front-end request 103 and theresponse 107 constitute a single transaction, and the time range of the transaction is measured between the time the front-end server 104 receives therequest 103 from theclient 102 and the time the front-end server 104 sends theresponse 107 to theclient 102. - A transaction type is determined using an input defined by an end user. Particularly, a transaction type may be defined by a specific protocol. For example, the transaction type for hypertext transfer protocol (HTTP) may be the uniform resource locator (URL), a part of the URL that defines a specific command, a set of key-value pairs from headers of a Hypertext Transfer Protocol (HTTP) POST request, etc. In another example, the transaction type for database servers may be described by a structured query language (SQL) statement, etc. In an embodiment of the invention, there are a finite number of front-end request types and a finite number of back-end request types.
- The request or transaction type may be derived from the content of the request or transaction. As an example, the
client 102 may submit a request corresponding to the URL “http://<>/pd.php?pid=15&user_id=19” to the front-end server 104. In this example, the part of the URL “http://<>/pd.php?pid=15” would define a single request type, if the user specified that the user_id argument should be ignored. Thus, URLs having the form of “http:/<>/pd.php?pid=15&user_id= . . . ” constitute the same request type, despite their differences in user_id. That is, the “user_id” part of the URL sent by theclient 102 is irrelevant for defining the request's type. - In an embodiment of the invention, the front-
end server 104 is assumed to work as a deterministic black box; that is, each front-end request of a given type generates a fixed sequence of back-end requests. The same sequence of back-end requests (having the same number of requests and the same types across different occurrences of sequences) will be generated by each occurrence of the given front-end request type. For example, if an instance of front-end request type B generates an instance of back-end request type a and an instance of back-end request type b in that order, other instances of front-end request type B will also generate instances of back-end request types a and b in that order. Thus, the agent residing in the front-end server 104 may observe multiple, possibly overlapping in time, front-end requests and the resulting back-end requests. In addition, some of the back-end requests may not have been caused by any of the front-end requests. An embodiment of the invention determines which front-end request, if any, generates a given back-end request. -
FIG. 2 is an exemplary diagram that may result from observing the transactions on both sides of the front-end server 104. Solid arrows on the right of the diagram represent back-end requests that may have been resulted from the front-end request represented by the solid arrow on the left of the diagram, based on time consideration. Specifically, the back-end requests represented by the solid arrows start after the start of, and end before the end of, the front-end request represented by the solid arrow. However, some of these back-end requests represented by the solid arrows may have resulted from other front-end requests (represented by the dashed arrows) in the same time range. The relationship shown inFIG. 2 may be represented by the graph depicted inFIG. 3 . InFIG. 3 , the front-end request types are shown as numbers and back-end request types are shown as letters. To determine which front-end request type generates a given back-end request type, a system of constraints can be formulated as follows: remove some minimal number of the edges in the graph so that (1) there is no more than one edge coming into each node representing a back-end request type (because each back-end request type is generated by one front-end request type) and (2) for each front-end request type, the number and types of generated back-end request types remain the same. -
FIG. 4 illustrates a process for mapping transactions on both sides of the front-end server 104 without knowledge of the internal structure of the front-end server 104, according to an embodiment of the invention. At 402, both front-end transactions and back-end transactions and their individual timings are observed. At 404, possible associations between front-end transaction types and back-end transaction types are built based on time constraints. At 406, a system of constraints is built such that (1) each back-end transaction is caused by one front-end transaction and (2) the number of associations between front-end transactions of a given type and back-end transactions of a given type remain the same. At 408, one or more associations between the front-end transactions and the back-end transactions are eliminated so as to satisfy the system of constraints. For example, the least possible number of associations between the front-end transactions and the back-end transactions are eliminated to satisfy the system of constraints - An algorithm is developed to determine which front-end request type generates a given back-end request type based on the system of constraints. According to an embodiment of the invention, N front-end requests and K back-end requests are observed. The number of front-end requests is denoted as CRn, and the number of back-end requests is denoted as SRk. The front-end request type is denoted as CTn, and the back-end request type is denoted as STk. A matrix of Boolean variables xnk is introduced. The Boolean variable xnk has the value of 1 if front-end request n may have caused back-end request k. Otherwise, the Boolean variable xnk has the value of 0 if front-end request n may not have caused back-end request k. The matrix of Boolean variables xnk is initialized according to a temporal sequence; that is, xnk is set to the value of 1 if the k-th back-end request starts after the start of, and ends before the end of, the n-th front-end request.
- Since each back-end request is attributed to no more than one front-end request, a set of inequalities on the values xnk is imposed; namely,
In addition, a matrix of integer variables ynk is defined, where the first index n ranges from 1 to the number of front-end request types, and the second index k ranges from 1 to the number of back-end request types. The value ynk provides the number of back-end requests of type STk generated by each front-end request of type CTn. - The Y matrix is initialized as follows: for each front-end request of type CTn, count the number of back-end requests of each type STk that may have been caused by the front-end request zk. If the n-th row of the Y matrix has not been initialized, zk is stored in the n-th row of the Y matrix. Otherwise, ynk is replaced with the minimum of ynk or zk. Thus, if a front-end request of type A generates, for example, two back-end requests of type a, then another front-end request of type A will generate two back-end requests of type a as well. Accordingly, if more than two back-end request candidates are observed in response to a front-end request of type A, these back-end requests will eventually be eliminated as candidates except two back-end requests of type a.
- Since it is now known how many back-end requests of a given type each front-end request of a given type generates, more equations for the elements of the matrix X may be created. Thus, for each front-end request type CTn and back-end request type STk, the sum of xij, where CRi is of type CTn and SRj is of type STk, is equal to ynk.
- The complete system of equations may then be solved by identifying those equations to the elements of the matrix X, where the sum is 0, and by setting the corresponding xij to 0. For those xij not set in the solutions, trial and error may be used to solve the equations. Even though the number of trials may be large, but each step involves a simple arithmetic operation (e.g., summation). Therefore, the execution time is expected to be reasonable. Further improvements to the process of obtaining solution can be implemented to improve efficiency.
-
FIG. 5 is a timing diagram illustrating exemplary sequences of front-end and back-end requests. A front-end request can cause many back-end requests, and a back-end request can be caused by one front-end request. InFIG. 5 , front-end requests are represented by capitalized letters, and back-end requests are represented by lower case letters. The numerals represent particular instances of requests. - As shown, at
time period 1, it can be determined that back-end request type a may have been caused by front-end request type A because back-end request type a starts after the start of, and ends before the end of, front-end request type A. It can be determined attime period 1 that back-end request type a cannot have been caused by front-end request type B because back-end request type a starts before the start of front-end request type B. Furthermore, attime period 1, it cannot be determined if back-end request type b is caused by front-end request type A or front-end request type B. This is because back-end request type b starts after both front-end request types A and B have started and ends before both front-end request types A and B have ended. - At
time period 2, it can be determined that back-end request type c may have been caused by front-end request type B. This is because back-end request type c starts after front-end request type A has ended (thus cannot be caused by front-end request type A), but starts after the start of, and ends before the end of, front-end request type B. - At
time period 3, it can be confirmed that back-end request type c may have been caused by front-end request type B because it again starts after the start of, and ends before the end of, front-end request type B. In addition, it can be determined attime period 3 that back-end request type b cannot be caused by front-end request type B because an instance of back-end request type b does not occur during this particular instance of front-end request type B. As discussed, the same sequence of back-end requests will be generated by each occurrence of a given front-end request type. Thus, it can be determined attime period 3 that back-end request type b may have been caused by front-end request type A. - At
time period 4, it can be confirmed that back-end request type b may have been caused by front-end request type A since it starts after the start of, and ends before the end of, this particular instance of front-end request type A. It can also be determined that back-end request type a cannot be caused by front-end request type A because an instance of back-end request type a does not occur during this instance of front-end request type A. Thus, back-end request type a is not caused by either front-end request type A or front-end request type B; it may have occurred due to activity of the server not related to any front-end request. - These observed sequences of front-end transactions and back-end transactions can be formulated into a set of equations according to the discussed algorithm. At
time 1, the following equations may be established:
X(a1,A1)=1 (1)
X (b1,A1) +X (b1,B1)=1 (i.e., one of the variables is 1, and the other variable is 0) (2) - At
time 2, the following equation may be established:
X(c1,B1)=1 (3) - At
time 3, the following equation may be established:
X(c2,B2)=1 (4) - And at
time 4, the following equation may be established:
X(b2,A2)=1 (5) - From
equations equations -
FIG. 6 is a timing diagram illustrating other exemplary sequences of front-end and back-end requests. Again, front-end requests are represented by capitalized letters, and back-end requests are represented by lower case letters. As shown inFIG. 6 , two instances of front-end request type B and two instances of back-end request type b occur duringtime period 5. It cannot be determined which instance of back-end request type b is caused by which instance of front-end request type B. However, since both instances of back-end request type b start after the start of, and end before the end of, both instances of front-end request type B, it can be determined that back-end request type b may have been caused by front-end request type B. For analyzing application performance, it is not important to determine which specific instance of a given front-end request type causes which specific instance of a given back-end request type. -
FIG. 7 illustrates a process for mapping transactions on both sides of the front-end server 104 without knowledge of the internal structure of the front-end server 104, in accordance with an alternative embodiment of the invention. At 702, both front-end transactions and back-end transactions are observed. For example, the statistics of both front-end transactions and back-end transactions are observed. At 704, a frequency of occurrence of each front-end transaction type and a frequency of occurrence of each back-end transaction type are established. At 706, a system of linear relationships is established to express the transaction frequency of each back-end transaction type as a linear combination of transaction frequencies of the front-end transaction types. The linear combination of transaction frequencies thus expresses a mapping between a front-end transaction type and one or more back-end transaction types. This alternative embodiment of the invention, even though may provide less accurate results because it is statistical in nature, has the advantages of providing an incremental model and incurring less computation. -
FIG. 8 illustrates an exemplary graph showing transaction frequencies of front-end transaction types A and B and back-end transaction types a and b. Transaction frequency is the count of transactions of a given type within a unit of time. From the graph illustrated inFIG. 8 , the following linear relationships may be established:
f a =a 1 f A +a 2 f B (6)
f b =b 1 f A +b 2 f B (7)
where fx represents the frequency of transaction type x. - Here, a1, b1, a2, and b2 are the values determined from the data and representing the mapping between front-end and back-end transactions. Thus, a1 determines how many transactions of type a result from each transaction of type A. These values, therefore, constitute the output (end result) of the algorithm.
- For example, in linear relationship 6, if a1 is 0 and a2 is 1, then fa=fB. Thus, it can be determined that each front-end transaction of type B causes one back-end transaction of type a.
- While particular embodiments and applications of the present invention have been illustrated and described herein, it is to be understood that the invention is not limited to the precise construction and components disclosed herein and that various modifications, changes, and variations may be made in the arrangement, operation, and details of the methods and apparatuses of the present invention without departing from the spirit and scope of the invention as it is defined in the appended claims.
Claims (28)
1. A method of mapping front-end transactions and back-end transactions of a front-end server, comprising the steps of:
identifying one or more types of front-end transactions and one or more types of back-end transactions and their times of occurrence with respect to the front-end server;
building possible associations between the identified front-end transaction types and the identified back-end transaction types based on a time constraint; and
eliminating one or more of the associations such that each back-end transaction type is caused by one front-end transaction type and the number of associations between a given front-end transaction type and a given back-end transaction type remains constant.
2. The method of claim 1 , wherein building the possible associations between the identified front-end transaction types and back-end transaction types based on the time constraint includes the step of:
associating a back-end transaction type with a front-end transaction type if the back-end transaction type starts after the front-end transaction type has started and ends before the front-end transaction type has ended.
3. The method of claim 1 , wherein eliminating the one or more associations includes the steps of:
identifying a back-end transaction type that occurs during an instance of a front-end transaction type but does not occur during another instance of the front-end transaction type; and
eliminating the association between the back-end transaction type and the front-end transaction type.
4. The method of claim 1 , wherein a front-end transaction represents a request sent by a client to the front-end server and a response sent by the front-end server to the client responsive to the request.
5. The method of claim 1 , wherein a back-end transaction represents a request sent by the front-end server to a back-end server and a response sent by the back-end server to the front-end server responsive to the request.
6. The method of claim 1 , wherein identifying the one or more types of the front-end transactions and the one or more types of the back-end transactions includes the steps of:
identifying the types of the front-end transactions based on contents of the front-end transactions; and
identifying the types of the back-end transactions based on contents of the back-end transactions.
7. The method of claim 1 , wherein eliminating the one or more associations includes the steps of:
eliminating the least possible number of the associations such that each back-end transaction type is caused by one front-end transaction type and the number of associations between a given front-end transaction type and a given back-end transaction type remains constant.
8. The method of claim 1 , wherein eliminating the one or more associations includes the step of:
removing, when a back-end transaction type is associated with more than one front-end transaction type, the associations so that the back-end transaction type is associated with one front-end transaction type.
9. A system for mapping transactions on both sides of a front-end server, the system comprising a module adapted to:
identify one or more types of front-end transactions and one or more types of back-end transactions and their times of occurrence with respect to the front-end server;
build possible associations between the identified front-end transaction types and the identified back-end transaction types based on a time constraint; and
eliminate one or more of the associations such that each back-end transaction type is caused by one front-end transaction type and the number of associations between a given front-end transaction type and a given back-end transaction type remains constant.
10. The system of claim 9 , wherein the module is adapted to build the possible associations between the identified front-end transaction types and back-end transaction types based on the time constraint by:
associating a back-end transaction type with a front-end transaction type if the back-end transaction type starts after the front-end transaction type has started and ends before the front-end transaction type has ended.
11. The system of claim 9 , wherein the module is adapted to:
identify a back-end transaction type that occurs during an instance of a front-end transaction type but does not occur during another instance of the front-end transaction type; and
eliminate the association between the back-end transaction type and the front-end transaction type.
12. The system of claim 9 , wherein a front-end transaction represents a request sent by a client to the front-end server and a response sent by the front-end server to the client responsive to the request.
13. The system of claim 9 , wherein a back-end transaction represents a request sent by the front-end server to a back-end server and a response sent by the back-end server to the front-end server responsive to the request.
14. The system of claim 9 , wherein the module is adapted to:
identify the types of the front-end transactions based on contents of the front-end transactions; and
identify the types of the back-end transactions based on contents of the back-end transactions.
15. The system of claim 9 , wherein the module is adapted to:
eliminating the least possible number of the associations such that each back-end transaction type is caused by one front-end transaction type and the number of associations between a given front-end transaction type and a given back-end transaction type remains constant.
16. The system of claim 9 , wherein if a back-end transaction type is associated with more than one front-end transaction type, the module is adapted to remove the associations so that the back-end transaction type is associated with one front-end transaction type.
17. A method of mapping front-end transactions and back-end transactions of a front-end server, comprising the steps of:
determining a frequency of occurrence of each front-end transaction type and a frequency of occurrence of each back-end transaction type with respect to the front-end server; and
expressing the frequency of each back-end transaction type as a linear combination of frequencies of one or more front-end transaction types.
18. The method of claim 17 , wherein the expression represents a mapping of front-end transaction types and back-end transaction types.
19. The method of claim 17 , wherein determining the frequency of occurrence of each front-end transaction type and the frequency of occurrence of each back-end transaction type includes the step of:
observing front-end transaction types and back-end transaction types to determine their occurrence statistics with respect to the front-end server.
20. The method of claim 17 , wherein determining the frequency of occurrence of each front-end transaction type and the frequency of occurrence of the back-end transaction type includes the steps of:
identifying a type of a front-end transaction based on content of the front-end transaction; and
identifying a type of a back-end transaction based on content of the back-end transaction.
21. The method of claim 17 , wherein a front-end transaction represents a request sent by a client to the front-end server and a response sent by the front-end server to the client responsive to the request.
22. The method of claim 17 , wherein a back-end transaction represents a request sent by the front-end server to a back-end server and a response sent by the back-end server to the front-end server responsive to the request.
23. A system for mapping transactions on both sides of a front-end server, the system comprising a module adapted to:
determine a frequency of occurrence of each front-end transaction type and a frequency of occurrence of each back-end transaction type with respect to the front-end server; and
express the frequency of each back-end transaction type as a linear combination of frequencies of one or more front-end transaction types.
24. The system of claim 23 , wherein the expression represents a mapping of front-end transaction types and back-end transaction types.
25. The system of claim 23 , wherein the module is adapted to determine the frequency of occurrence of each front-end transaction type and the frequency of occurrence of each back-end transaction type by:
observing front-end transaction types and back-end transaction types to determine their occurrence statistics with respect to the front-end server.
26. The system of claim 23 , wherein the module is adapted to:
identify a type of a front-end transaction based on content of the front-end transaction; and
identify a type of a back-end transaction based on content of the back-end transaction.
27. The system of claim 23 , wherein a front-end transaction represents a request sent by a client to the front-end server and a response sent by the front-end server to the client responsive to the request.
28. The system of claim 23 , wherein a back-end transaction represents a request sent by the front-end server to a back-end server and a response sent by the back-end server to the front-end server responsive to the request.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/134,568 US20060265430A1 (en) | 1995-09-29 | 2005-05-19 | Transactions matching for multi-tier architectures |
Applications Claiming Priority (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US456895P | 1995-09-29 | 1995-09-29 | |
US08/582,073 US6182224B1 (en) | 1995-09-29 | 1996-01-02 | Enhanced network services using a subnetwork of communicating processors |
US09/738,435 US6640243B1 (en) | 1995-09-29 | 2000-12-14 | Enhanced network services using a subnetwork of communicating processors |
US10/665,838 US6917966B1 (en) | 1995-09-29 | 2003-09-19 | Enhanced network services using a subnetwork of communicating processors |
US11/134,568 US20060265430A1 (en) | 1995-09-29 | 2005-05-19 | Transactions matching for multi-tier architectures |
Publications (1)
Publication Number | Publication Date |
---|---|
US20060265430A1 true US20060265430A1 (en) | 2006-11-23 |
Family
ID=34714187
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/665,838 Expired - Fee Related US6917966B1 (en) | 1995-09-29 | 2003-09-19 | Enhanced network services using a subnetwork of communicating processors |
US11/134,568 Abandoned US20060265430A1 (en) | 1995-09-29 | 2005-05-19 | Transactions matching for multi-tier architectures |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/665,838 Expired - Fee Related US6917966B1 (en) | 1995-09-29 | 2003-09-19 | Enhanced network services using a subnetwork of communicating processors |
Country Status (1)
Country | Link |
---|---|
US (2) | US6917966B1 (en) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20070136312A1 (en) * | 2005-12-12 | 2007-06-14 | Imperva, Inc | System and method for correlating between http requests and sql queries |
US20080189706A1 (en) * | 2007-02-01 | 2008-08-07 | Acei Ab | Transaction processing system and method |
US9602366B1 (en) * | 2010-03-03 | 2017-03-21 | Netscout Systems, Inc. | System and method for correcting clock discrepancy in simultaneous network traffic captures |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3973986B2 (en) * | 2002-07-12 | 2007-09-12 | 株式会社エヌ・ティ・ティ・ドコモ | Node search method, node, communication system, and node search program |
US20070271130A1 (en) * | 2006-05-19 | 2007-11-22 | Microsoft Corporation | Flexible scheduling and pricing of multicore computer chips |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6055492A (en) * | 1997-12-12 | 2000-04-25 | International Business Machines Corporation | System and method for providing trace information data reduction |
US20030140282A1 (en) * | 1999-06-03 | 2003-07-24 | Kaler Christopher G. | Method and apparatus for analyzing performance of data processing system |
US20050030979A1 (en) * | 2003-08-08 | 2005-02-10 | Malloy Patrick J. | Synchronizing packet traces |
US20060013228A1 (en) * | 2004-07-14 | 2006-01-19 | Malloy Patrick J | Packet tracing |
US20060050704A1 (en) * | 2004-07-14 | 2006-03-09 | Malloy Patrick J | Correlating packets |
US7249136B1 (en) * | 2003-09-11 | 2007-07-24 | At&T Corp. | Space-and time-efficient management and summarization of data using intermediate summary structure and hierarchical multidimensional histogram |
Family Cites Families (100)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
SE416367B (en) | 1976-09-07 | 1980-12-15 | Western Electric Co | EKOELIMINERINGSANORDNING |
US4161719A (en) | 1977-10-04 | 1979-07-17 | Ncr Corporation | System for controlling synchronization in a digital communication system |
US4445213A (en) | 1979-07-31 | 1984-04-24 | Bell Telephone Laboratories, Incorporated | Communication line interface for controlling data information having differing transmission characteristics |
US4316284A (en) | 1980-09-11 | 1982-02-16 | Bell Telephone Laboratories, Incorporated | Frame resynchronization circuit for digital receiver |
US4397020A (en) | 1980-09-11 | 1983-08-02 | Bell Telephone Laboratories, Incorporated | Error monitoring in digital transmission systems |
USRE33900E (en) | 1980-09-11 | 1992-04-28 | At&T Bell Laboratories | Error monitoring in digital transmission systems |
US4438511A (en) | 1980-11-10 | 1984-03-20 | Telebit Corporation | Packetized ensemble modem |
FR2500704A1 (en) | 1981-02-20 | 1982-08-27 | Devault Michel | ASYNCHRONOUS TIME SWITCH FOR DIGITAL NETWORK WITH INTEGRATION OF SERVICES |
US4419728A (en) | 1981-06-22 | 1983-12-06 | Bell Telephone Laboratories, Incorporated | Channel interface circuit providing virtual channel number translation and direct memory access |
US4424565A (en) | 1981-06-22 | 1984-01-03 | Bell Telephone Laboratories, Incorporated | Channel interface circuit with high speed data message header field translation and direct memory access |
US4439763A (en) | 1981-09-03 | 1984-03-27 | Bell Telephone Laboratories, Incorporated | Collision avoiding system and protocol for a multiple access digital communications system |
US4456957A (en) | 1981-09-28 | 1984-06-26 | Ncr Corporation | Apparatus using a decision table for routing data among terminals and a host system |
US4437087A (en) | 1982-01-27 | 1984-03-13 | Bell Telephone Laboratories, Incorporated | Adaptive differential PCM coding |
US4464658A (en) | 1982-03-05 | 1984-08-07 | At&T Laboratories | Multipoint data communication system with collision detection |
US4506358A (en) | 1982-06-25 | 1985-03-19 | At&T Bell Laboratories | Time stamping for a packet switching system |
US4532626A (en) | 1982-07-19 | 1985-07-30 | At&T Bell Laboratories | Collision avoiding system and protocol for a two path multiple access digital communications system |
US4507760A (en) | 1982-08-13 | 1985-03-26 | At&T Bell Laboratories | First-in, first-out (FIFO) memory configuration for queue storage |
US4499576A (en) | 1982-08-13 | 1985-02-12 | At&T Bell Laboratories | Multiplexed first-in, first-out queues |
US4771425A (en) | 1984-10-29 | 1988-09-13 | Stratacom, Inc. | Synchoronous packet voice/data communication system |
US4903261A (en) | 1984-10-29 | 1990-02-20 | Stratacom, Inc. | Synchronous packet voice/data communication system |
US4819228A (en) | 1984-10-29 | 1989-04-04 | Stratacom Inc. | Synchronous packet voice/data communication system |
US4646287A (en) | 1984-12-07 | 1987-02-24 | At&T Bell Laboratories | Idle period signalling in a packet switching system |
US4879551A (en) | 1985-04-26 | 1989-11-07 | International Business Machines Corporation | Switching array with concurrent marking capability |
US4679227A (en) | 1985-05-20 | 1987-07-07 | Telebit Corporation | Ensemble modem structure for imperfect transmission media |
US5054034A (en) | 1985-05-20 | 1991-10-01 | Telebit Corporation | Ensemble modem structure for imperfect transmission media |
US4833706A (en) | 1985-05-20 | 1989-05-23 | Telebit Corporation | Ensemble modem structure for imperfect transmission media |
US4644532A (en) | 1985-06-10 | 1987-02-17 | International Business Machines Corporation | Automatic update of topology in a hybrid network |
US4723267A (en) | 1985-06-17 | 1988-02-02 | Octocom Systems, Inc. | Telephone line interface and dialer circuitry for telecommunications equipment |
US4970678A (en) | 1985-10-24 | 1990-11-13 | International Business Machines Corporation | System for providing context-sensitive on-line documentation in a data processor |
US4679189A (en) | 1985-11-27 | 1987-07-07 | American Telephone And Telegraph Company | Alternate routing arrangement |
US4677423A (en) | 1986-01-06 | 1987-06-30 | American Telephone & Telegraph, At&T Bell Laboratories | ADPCM coder-decoder including partial band energy transition detection |
US4750136A (en) | 1986-01-10 | 1988-06-07 | American Telephone And Telegraph, At&T Information Systems Inc. | Communication system having automatic circuit board initialization capability |
US4757495A (en) | 1986-03-05 | 1988-07-12 | Telebit Corporation | Speech and data multiplexor optimized for use over impaired and bandwidth restricted analog channels |
US4763191A (en) | 1986-03-17 | 1988-08-09 | American Telephone And Telegraph Company, At&T Bell Laboratories | Dial-up telephone network equipment for requesting an identified selection |
US4835737A (en) | 1986-07-21 | 1989-05-30 | American Telephone And Telegraph Company, At&T Bell Laboratories | Method and apparatus for controlled removal and insertion of circuit modules |
JPH0793634B2 (en) | 1986-11-29 | 1995-10-09 | 株式会社東芝 | Bus adapter with address conversion function |
US4769811A (en) | 1986-12-31 | 1988-09-06 | American Telephone And Telegraph Company, At&T Bell Laboratories | Packet switching system arranged for congestion control |
US4769810A (en) | 1986-12-31 | 1988-09-06 | American Telephone And Telegraph Company, At&T Bell Laboratories | Packet switching system arranged for congestion control through bandwidth management |
US4827411A (en) | 1987-06-15 | 1989-05-02 | International Business Machines Corporation | Method of maintaining a topology database |
US4965772A (en) | 1987-06-15 | 1990-10-23 | International Business Machines Corporation | Method and apparatus for communication network alert message construction |
US4893306A (en) | 1987-11-10 | 1990-01-09 | Bell Communications Research, Inc. | Method and apparatus for multiplexing circuit and packet traffic |
US5088032A (en) | 1988-01-29 | 1992-02-11 | Cisco Systems, Inc. | Method and apparatus for routing communications among computer networks |
US4922486A (en) | 1988-03-31 | 1990-05-01 | American Telephone And Telegraph Company | User to network interface protocol for packet communications networks |
US4991169A (en) | 1988-08-02 | 1991-02-05 | International Business Machines Corporation | Real-time digital signal processing relative to multiple digital communication channels |
US4980897A (en) | 1988-08-12 | 1990-12-25 | Telebit Corporation | Multi-channel trellis encoder/decoder |
EP0363053B1 (en) | 1988-10-06 | 1998-01-14 | Gpt Limited | Asynchronous time division switching arrangement and a method of operating same |
US5255291A (en) | 1988-11-14 | 1993-10-19 | Stratacom, Inc. | Microprocessor based packet isochronous clocking transmission system and method |
US4962532A (en) | 1988-12-22 | 1990-10-09 | Ibm Corporation | Method for providing notification of classified electronic message delivery restriction |
JPH02187993A (en) | 1989-01-13 | 1990-07-24 | Mitsubishi Electric Corp | Associative memory device |
US5020058A (en) | 1989-01-23 | 1991-05-28 | Stratacom, Inc. | Packet voice/data communication system having protocol independent repetitive packet suppression |
JPH02308499A (en) | 1989-05-23 | 1990-12-21 | Toshiba Corp | Content-addressable memory |
US5095480A (en) | 1989-06-16 | 1992-03-10 | Fenner Peter R | Message routing system for shared communication media networks |
US4960310A (en) | 1989-08-04 | 1990-10-02 | Optical Corporation Of America | Broad band nonreflective neutral density filter |
US5003595A (en) | 1989-08-29 | 1991-03-26 | At&T Bell Laboratories | Secure dial access to computer systems |
US4962497A (en) | 1989-09-21 | 1990-10-09 | At&T Bell Laboratories | Building-block architecture of a multi-node circuit-and packet-switching system |
JPH03148940A (en) | 1989-11-06 | 1991-06-25 | Hitachi Ltd | Mutual connection system for lan and isdn |
IT1237302B (en) | 1989-11-30 | 1993-05-27 | Vinicio Vercellone | BASIC ELEMENT FOR THE CONNECTION NETWORK OF A FAST CELL SWITCHING NODE. |
US5014265A (en) | 1989-11-30 | 1991-05-07 | At&T Bell Laboratories | Method and apparatus for congestion control in a data network |
US5072449A (en) | 1989-12-21 | 1991-12-10 | Stratacom, Inc. | Packet framing using cyclic redundancy checking |
US5128945A (en) | 1989-12-21 | 1992-07-07 | Stratacom, Inc. | Packet framing using cyclic redundancy checking |
US5033076A (en) | 1990-01-31 | 1991-07-16 | At&T Bell Laboratories | Enhanced privacy feature for telephone systems |
FR2660818B1 (en) | 1990-04-06 | 1992-06-19 | France Telecom | FRAME SWITCHER FOR ASYNCHRONOUS DIGITAL NETWORK. |
US5228062A (en) | 1990-04-16 | 1993-07-13 | Telebit Corporation | Method and apparatus for correcting for clock and carrier frequency offset, and phase jitter in multicarrier modems |
US5206886A (en) | 1990-04-16 | 1993-04-27 | Telebit Corporation | Method and apparatus for correcting for clock and carrier frequency offset, and phase jitter in mulicarrier modems |
US5199049A (en) | 1990-04-27 | 1993-03-30 | At&T Bell Laboratories | Circuit and method of digital carrier detection for burst mode communication systems |
US5136580A (en) | 1990-05-16 | 1992-08-04 | Microcom Systems, Inc. | Apparatus and method for learning and filtering destination and source addresses in a local area network system |
US5226120A (en) | 1990-05-21 | 1993-07-06 | Synoptics Communications, Inc. | Apparatus and method of monitoring the status of a local area network |
DE69130271T2 (en) | 1990-07-26 | 1999-06-02 | Nec Corp., Tokio/Tokyo | Routing system suitable for the effective processing of routing information |
GB9019340D0 (en) | 1990-09-05 | 1990-10-17 | Plessey Telecomm | An asynchronous transfer mode switching arrangement providing broadcast transmission |
US5287453A (en) | 1990-09-18 | 1994-02-15 | Bull Hn Information Systems, Inc. | Fast remote file access facility for distributing file access requests in a closely coupled computer system |
FR2667465A1 (en) | 1990-09-27 | 1992-04-03 | Cit Alcatel | BRIDGE FOR CONNECTING A LOCAL AREA NETWORK, COMPLIANT WITH THE IEEE 802.3 STANDARD, TO A TELECOMMUNICATION NETWORK WITH ASYNCHRONOUS TEMPORAL TECHNIQUE. |
US5059925A (en) | 1990-09-28 | 1991-10-22 | Stratacom, Inc. | Method and apparatus for transparently switching clock sources |
US5243342A (en) | 1990-09-28 | 1993-09-07 | Stratacom, Inc. | Integrated PCM level control and conversion using a lookup table |
US5115431A (en) | 1990-09-28 | 1992-05-19 | Stratacom, Inc. | Method and apparatus for packet communications signaling |
EP0487235B1 (en) | 1990-11-21 | 1999-02-03 | AT&T Corp. | Bandwidth and congestion management in accessing broadband ISDN networks |
US5166930A (en) | 1990-12-17 | 1992-11-24 | At&T Bell Laboratories | Data channel scheduling discipline arrangement and method |
DE69214968T2 (en) | 1991-01-08 | 1997-05-28 | Nippon Electric Co | Switching system with an input distribution stage for time-marked packets and with an output stage for ensuring the correct order of the packets |
US5280480A (en) | 1991-02-21 | 1994-01-18 | International Business Machines Corporation | Source routing transparent bridge |
US5268592A (en) | 1991-02-26 | 1993-12-07 | International Business Machines Corporation | Sequential connector |
WO1992016066A1 (en) | 1991-02-28 | 1992-09-17 | Stratacom, Inc. | Method and apparatus for routing cell messages using delay |
US5274631A (en) | 1991-03-11 | 1993-12-28 | Kalpana, Inc. | Computer network switching system |
US5247516A (en) | 1991-03-28 | 1993-09-21 | Sprint International Communications Corp. | Configurable composite data frame |
US5241682A (en) | 1991-04-18 | 1993-08-31 | International Business Machines Corporation | Border node having routing and functional capability in a first network and only local address capability in a second network |
US5313582A (en) | 1991-04-30 | 1994-05-17 | Standard Microsystems Corporation | Method and apparatus for buffering data within stations of a communication network |
US5224099A (en) | 1991-05-17 | 1993-06-29 | Stratacom, Inc. | Circuitry and method for fair queuing and servicing cell traffic using hopcounts and traffic classes |
US5268900A (en) | 1991-07-05 | 1993-12-07 | Codex Corporation | Device and method for implementing queueing disciplines at high speeds |
DE69129851T2 (en) | 1991-09-13 | 1999-03-25 | International Business Machines Corp., Armonk, N.Y. | Configurable gigabit / s switch adapter |
US5280500A (en) | 1991-10-10 | 1994-01-18 | Crescendo Communications, Inc. | Method and apparatus for multilevel encoding for a local area network |
US5287103A (en) | 1991-12-30 | 1994-02-15 | At&T Bell Laboratories | Method and apparatus for providing local area network clients with internetwork identification data |
US5243596A (en) | 1992-03-18 | 1993-09-07 | Fischer & Porter Company | Network architecture suitable for multicasting and resource locking |
US5313454A (en) | 1992-04-01 | 1994-05-17 | Stratacom, Inc. | Congestion control for cell networks |
US5260933A (en) | 1992-05-15 | 1993-11-09 | International Business Machines Corporation | Acknowledgement protocol for serial data network with out-of-order delivery |
US5305311A (en) | 1992-05-20 | 1994-04-19 | Xerox Corporation | Copy network providing multicast capabilities in a broadband ISDN fast packet switch suitable for use in a local area network |
US5291482A (en) | 1992-07-24 | 1994-03-01 | At&T Bell Laboratories | High bandwidth packet switch |
US5260978A (en) | 1992-10-30 | 1993-11-09 | Bell Communications Research, Inc. | Synchronous residual time stamp for timing recovery in a broadband network |
US5274635A (en) | 1992-11-18 | 1993-12-28 | Stratacom, Inc. | Method and apparatus for aligning a digital communication data stream across a cell network |
US5568612A (en) * | 1992-11-18 | 1996-10-22 | Canon Kabushiki Kaisha | Method and apparatus for advertising services of two network servers from a single network node |
US5274643A (en) | 1992-12-11 | 1993-12-28 | Stratacom, Inc. | Method for optimizing a network having virtual circuit routing over virtual paths |
US5283783A (en) | 1993-01-28 | 1994-02-01 | Synoptics Communications, Inc. | Apparatus and method of token ring beacon station removal for a communication network |
US6029195A (en) * | 1994-11-29 | 2000-02-22 | Herz; Frederick S. M. | System for customized electronic identification of desirable objects |
-
2003
- 2003-09-19 US US10/665,838 patent/US6917966B1/en not_active Expired - Fee Related
-
2005
- 2005-05-19 US US11/134,568 patent/US20060265430A1/en not_active Abandoned
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6055492A (en) * | 1997-12-12 | 2000-04-25 | International Business Machines Corporation | System and method for providing trace information data reduction |
US20030140282A1 (en) * | 1999-06-03 | 2003-07-24 | Kaler Christopher G. | Method and apparatus for analyzing performance of data processing system |
US20050030979A1 (en) * | 2003-08-08 | 2005-02-10 | Malloy Patrick J. | Synchronizing packet traces |
US7249136B1 (en) * | 2003-09-11 | 2007-07-24 | At&T Corp. | Space-and time-efficient management and summarization of data using intermediate summary structure and hierarchical multidimensional histogram |
US20060013228A1 (en) * | 2004-07-14 | 2006-01-19 | Malloy Patrick J | Packet tracing |
US20060050704A1 (en) * | 2004-07-14 | 2006-03-09 | Malloy Patrick J | Correlating packets |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20070136312A1 (en) * | 2005-12-12 | 2007-06-14 | Imperva, Inc | System and method for correlating between http requests and sql queries |
US7640235B2 (en) * | 2005-12-12 | 2009-12-29 | Imperva, Inc. | System and method for correlating between HTTP requests and SQL queries |
US20080189706A1 (en) * | 2007-02-01 | 2008-08-07 | Acei Ab | Transaction processing system and method |
EP1953655A3 (en) * | 2007-02-01 | 2008-12-31 | Acei Ab | Transaction processing system and method |
US9602366B1 (en) * | 2010-03-03 | 2017-03-21 | Netscout Systems, Inc. | System and method for correcting clock discrepancy in simultaneous network traffic captures |
Also Published As
Publication number | Publication date |
---|---|
US6917966B1 (en) | 2005-07-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
Tribastone et al. | Scalable differential analysis of process algebra models | |
Gwadera et al. | Reliable detection of episodes in event sequences | |
US7035766B1 (en) | System and method for diagnosing computer system operational behavior | |
US8209567B2 (en) | Message clustering of system event logs | |
US7254646B2 (en) | Analysis of causal relations between intercommunicating nodes | |
Jiang et al. | Efficient and scalable algorithms for inferring likely invariants in distributed systems | |
WO2004053713A1 (en) | Automatic context management for web applications with client side code execution | |
Gulzar et al. | Perception and practices of differential testing | |
US20060265430A1 (en) | Transactions matching for multi-tier architectures | |
Vats et al. | Analyzing Markov chain Monte Carlo output | |
Lee et al. | Statistical reachability analysis | |
Kapus | Using PRISM model checker as a validation tool for an analytical model of IEEE 802.15. 4 networks | |
US11665185B2 (en) | Method and apparatus to detect scripted network traffic | |
Puranik et al. | Deletion presolve for accelerating infeasibility diagnosis in optimization models | |
US20040088278A1 (en) | Method to measure stored procedure execution statistics | |
Kogel et al. | Learning Mealy Machines with Local Timers | |
Beaulaton et al. | Security analysis of IoT systems using attack trees | |
Kubacki et al. | Multidimensional log analysis | |
Aldekhail et al. | Intelligent Identification and Resolution of Software Requirement Conflicts: Assessment and Evaluation. | |
Jackson et al. | Learning with queries corrupted by classification noise | |
EP3547193A1 (en) | Analysis device, analysis method and analysis program | |
Hasan | Formalized probability theory and applications using theorem proving | |
US11515995B2 (en) | Efficient computation of univariate statistical moments for side channel vulnerability evaluation | |
Walter et al. | Enumerative Data Types with Constraints | |
Heisinger et al. | QuAPI: Adding Assumptions to Non-Assuming SAT & QBF Solvers. |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: NETWORK GENERAL TECHNOLOGY, CAYMAN ISLANDS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MANIN, DMITRII YURIEVICH;REEL/FRAME:016596/0387 Effective date: 20050518 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |
|
AS | Assignment |
Owner name: NETSCOUT SYSTEMS, INC., MASSACHUSETTS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:NETWORK GENERAL TECHNOLOGY;REEL/FRAME:049489/0108 Effective date: 20190617 |