Transactions matching for multi-tier architectures
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.
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.