About measuring message processing performance
The mechanism for measuring message processing performance is disabled by default. When enabled, information regarding message size, server processing time, and network travel time is available to the client that pushed a message to the server, to a client that received a pushed message from the server, or to a client that received an acknowledge message from the server in response a pushed message. A subset of this information is also available for access on the server.
You can use this mechanism across all channel types, including polling and streaming channels, that communicate with the LiveCycle Data Services ES server. However, this mechanism does not work when you make a direct connection to an external server by setting the useProxy property to false for the HTTPService and WebService tags because it bypasses the LiveCycle Data Services ES Proxy Server.
The MessagePerformanceUtils class defines the available message processing metrics. When a consumer receives a message, or a producer receives an acknowledge message, the consumer or producer extracts the metrics into an instance of the MessagePerformanceUtils class, and then accesses the metrics as properties of that class. For a complete list of the available metrics, see Available message processing metrics.
Measuring performance for different channel types
The types of metrics that are available and their calculations, depend on the channel configuration over which a message is sent from or received by the client.
Producer-acknowledge scenario
In the producer-acknowledge scenario, a producer sends a message to a server over a specific channel. The server then sends an acknowledge message back to the producer.
The following image shows the producer-acknowledge scenario:
If you enable the gathering of message processing metrics, the producer adds information to the message before sending it to the server, such as the send time and message size. The server copies the information from the message to the acknowledge message. Then the server adds additional information to the acknowledge message, such as the response message size and server processing time. When the producer receives the acknowledge message, it uses all of the information in the message to calculate the metrics defined by the MessagePerformanceUtils class.
Message-polling scenario
In a message-polling scenario, a consumer polls a message channel to determine if a message is available on the server. On receiving the polling message, the server pushes any available message to the consumer.
The following image shows the polling scenario:
If you enable the gathering of message processing metrics in this scenario, the consumer obtains performance metrics about the poll-response transaction, such as the response message size and server processing time. The metrics also include information about the message returned by the server. This information lets the consumer determine how long the message was waiting before it was pushed. However, the metric information does not identify the client that originally pushed the message onto the server.
Message-streaming scenario
In the streaming scenario, the server pushes a message to a consumer when a message is available; the consumer itself does not initiate the transaction.
The following image shows this scenario:
In this scenario, the message producer pushes a message, and then receives an acknowledge message. The producer can obtain metric information as described in Producer-acknowledge scenario.
When the server pushes the message to the consumer, the message contains information from the original message from the producer, and the metric information that the server added. The consumer can then examine the metric data, including the time from when the producer pushed the message until the consumer received it.
Measuring message processing performance for streaming and RTMP channels
For streaming and RTMP channels, a pushed message is sent to a consumer without the client first sending a polling message. In this case, the following metrics are not available to the consumer for the pushed message, but instead are set to 0:
- networkRTT
- serverPollDelay
- totalTime
Available message processing metrics
The following table lists the available message processing metrics defined by the MessagePerformanceUtils class:
|
Property |
Description |
|---|---|
| clientReceiveTime |
The number of milliseconds since the start of the UNIX epoch, January 1, 1970, 00:00:00 GMT, to when the client received a response message from the server. |
| messageSize |
The size of the original client message, in bytes, as measured during deserialization by the server endpoint. |
| networkRTT |
The duration, in milliseconds, from when a client sent a message to the server until it received a response, excluding the server processing time. This value is calculated as totalTime - serverProcessingTime. If a pushed message is using a streaming or RTMP channel, the metric is meaningless because the client does not initiate the pushed message; the server sends a message to the client whenever a message is available. Therefore, for a message pushed over a streaming or RTMP channel, this value is 0. However, for an acknowledge message sent over a streaming or RTMP channel, the metric contains a valid number. |
| originatingMessageSentTime |
The timestamp, in milliseconds since the start of the UNIX epoch on January 1, 1970, 00:00:00 GMT, to when the client that caused a push message sent its message. Only populated for a pushed message, but not for an acknowledge message. |
| originatingMessageSize |
Size, in bytes, of the message that originally caused this pushed message. Only populated for a pushed message, but not for an acknowledge message. |
| pushedMessageFlag |
Contains true if the message was pushed to the client but is not a response to a message that originated on the client. For example, when the client polls the server for a message, pushedMessageFlag is false. When you are using a streaming channel, pushedMessageFlag is true. For an acknowledge message, pushedMessageFlag is false. |
| pushOneWayTime |
Time, in milliseconds, from when the server pushed the message until the client received it. Note: This value is only relevant if the server and receiving client have synchronized clocks. Only populated for a pushed message, but not for an acknowledge message. |
| responseMessageSize |
The size, in bytes, of the response message sent to the client by the server as measured during serialization at the server endpoint. |
| serverAdapterExternalTime |
Time, in milliseconds, spent in a module invoked from the adapter associated with the destination for this message, before either the response to the message was ready or the message had been prepared to be pushed to the receiving client. This value corresponds to the message processing time on the server. |
| serverAdapterTime |
Processing time, in milliseconds, of the message by the adapter associated with the destination before the response to the message was ready or the message was prepared to be pushed to the receiving client. The processing time corresponds to the time that your code on the server processed the message, not when LiveCycle Data Services ES processed the message. |
| serverNonAdapterTime |
Server processing time spent outside the adapter associated with the destination of this message. Calculated as serverProcessingTime - serverAdapterTime. |
| serverPollDelay |
Time, in milliseconds, that this message sat on the server after it was ready to be pushed to the client but before it was picked up by a poll request. For a streaming or RTMP channel, this value is always 0. |
| serverPrePushTime |
Time, in milliseconds, between the server receiving the client message and the server beginning to push the message out to other clients. |
| serverProcessingTime |
Time, in milliseconds, between server receiving the client message and either the time the server responded to the received message or has the pushed message ready to be sent to a receiving client. For example, in the producer-acknowledge scenario, this value is the time from when the server receives the message and sends the acknowledge message back to the producer. In a polling scenario, it is the time between the arrival of the polling message from the consumer and any message returned in response to the poll. |
| serverSendTime |
The number of milliseconds since the start of the UNIX epoch, January 1, 1970, 00:00:00 GMT, to when the server sent a response message back to the client. |
| totalPushTime |
Time, in milliseconds, from when the originating client sent a message and the time that the receiving client received the pushed message. Note: This value is only relevant if the two clients have synchronized clocks. Only populated for a pushed message, but not for an acknowledge message. |
| totalTime |
Time, in milliseconds, between this client sending a message and receiving a response from the server. This property contains 0 for a streaming or RTMP channel. |
Considerations when measuring message processing performance
The mechanism that measures message processing performance attempts to minimize the overhead required to collect information so that all timing information is as accurate as possible. However, take into account the following considerations when you use this mechanism.
Synchronize the clocks on different computers
The metrics defined by the MessagePerformanceUtils class include the totalPushTime. The totalPushTime is a measure of the time from when the originating message producer sent a message until a consumer receives the message. This value is determined from the timestamp added to the message when the producer sends the message, and the timestamp added to the message when the consumer receives the message. However, to calculate a valid value for the totalPushTime metric, the clocks on the message-producing computer and on the message-consuming computer must be synchronized.
Another metric, pushOneWayTime, contains the time from when the server pushed the message until the consumer received it. This value is determined from the timestamp added to the message when the server sends the message, and the timestamp added to the message when the consumer receives the message. To calculate a valid value for the pushOneWayTime metric, the clocks on the message consuming computer and on the server must be synchronized.
One option is to perform your testing in a lab environment where you can ensure that the clocks on all computers are synchronized. For the totalPushTime metric, you can ensure that the clocks for the producer and consumer applications are synchronized by running the applications on the same computer. Or, for the pushOneWayTime metric, you can run the consumer application and server on the same computer.
Perform different tests for message timing and sizing
The mechanism for measuring message processing performance lets you enable the tracking of timing information, of sizing information, or both. The gathering of timing-only metrics is minimally intrusive to your overall application performance. The gathering of sizing metrics involves more overhead time than gathering timing information.
Therefore, you can run your tests twice: once for gathering timing information and once for gathering sizing information. In this way, the timing-only test can eliminate any delays caused by calculating message size. You can then combine the information from the two tests to determine your final results.