This article is part of a series, beginning with Analytics Application - Concepts and Metrics Explained
The Analytics Application included with Pulse Services Director operates on a dataset which is made from individual records, each of which describes a single transaction performed by Pulse Traffic Manager (vTM). This data includes (but is not limited to):
| The time at which the transaction occurred. |
The effective 'path' along which the transaction passed. That is:
|
| The size of the data received/transmitted. |
| The duration of the transaction. |
| Timings for various parts of the processing that the vTM had to undertake to process the transaction. |
| (For HTTP requests) Details of the request and response including request types, headers and URIs, response codes, response headers, and so on. |
| The outcome of the transaction. That is, how the transaction ended, both in terms of how the connection ended, and (where applicable) the HTTP response code. |
|
The full transaction is represented in a JSON schema, which can be downloaded from any Enterprise Management licensed vTM, by navigating to System > Analytics Export > Transaction Metadata and selecting "View JSON Schema for transaction metadata") |
The Analytics Application provides the user with tailored visualisations, and the tools to examine and drill into these potentially enormous datasets. These features enable the user to diagnose system problems, assess system performance, and so on.
The following example shows two requests making their way through a vTM cluster to back-end pool nodes, along with excerpts from the analytics transaction records that would be generated as a result.
The vTM cluster hosts two virtual servers: first, a simple web application; and second, an Ecommerce API gateway. Each application has been assigned resource pools and a set of dedicated server nodes with backup pools.
From the diagram, you can see that Request/Response #1 is a simple HTTP GET transaction. In addition to the path through the system, we also record the URL which is the subject of the GET request.
On the other hand, Request/Response #2 is a POST request to an Ecommerce gateway managed by the same cluster of vTMs.
Terminology: Transactions, Connections and Requests
Looking at the diagram above, we need to make sure we agree our terminology for Transactions, Connections and Requests.
Transactions: A transaction can be considered as the processing that a vTM undertakes to handle an incoming client connection or request. It may involve running TrafficScript, making a load balancing decision, creating a back-end connection to a server or any of a number of other traffic management activities. While a transaction is a meaningful unit for a vTM internally, it is not necessarily a useful abstraction for end users. This is because a transaction represents two distinct concepts: a connection and a request.
Connections: A connection represents a communication channel established over a network, over which data can be transferred. For example, a TCP connection.
Requests: A request is a higher level concept, usually capturing a protocol exchange carried over a connection. For example, a HTTP request-response carried over a TCP connection. Note that multiple requests can be carried over the same connection, for example HTTP keepalive requests.
The type of transaction record emitted by a particular vServer depends on the protocol of the vServer concerned; some protocols emit Request Records, while others emit Connection Records.
Some protocols are able to emit request records. All vServers that are configured to use one of the following protocols will emit request records:
- http
- https
- siptcp
- sipudp
- rtsp
- dns
- dns_tcp
NOTE - for all other protocols, refer to Protocols that Emit Connection Records.
- Inspect HTTP headers in order to optimise load balancing decisions at the vTM.
- Update the requests/responses as they pass through the vTM.
Each analytics record for those vServers corresponds to a single request/response. Each request/response pair is carried over a virtual connection established from the client to the server via a vTM. The transaction record shows protocol-level information, such as bytes sent and received, duration, HTTP request type, HTTP response code, headers, and so on. Multiple requests/responses can be carried over the same underlying connection.
For all request-based transaction records, request duration is determined by subtracting the time the first byte was received by vTM from the client from the time the final response byte is sent by vTM to the client.
This section addresses all protocols that are not listed in Protocols that Emit Request Records. For example, UDP, LDAP, POP3, and others. All vServers that are configured to use non-request protocols will emit connection records.
When recording analytics for vServers with a non-request based protocol, each analytics record corresponds to a virtual connection established from the client to the server via a vTM. The record includes connection-level information such as:
- Bytes sent and received.
- Duration.
- How the connection was closed.
However, it does not include information about any higher-level protocols carried over the connection. The connection duration is the length of the complete elapsed time period between initial establishment of the connection and its end.
NOTE - It is theoretically possible that a vTM that emits request records could also emit connection records, but this is not currently the case. The Analytics Application treats connection-based and request-based vServers separately. As a result, when a connection-based metric is selected, the connection data will not include data for vServers that emit request records, and vice-versa. The "Throughput (Mbps)" metric is an exception to this, as it applies equally to request-based and connection-based transaction records.
This article is part of a series, beginning with Analytics Application - Concepts and Metrics Explained
Next: Understanding Time Charts and Metrics
