🎄 Happy Holidays! 🥳
Most of Solace is closed December 24–January 1 so our employees can spend time with their families. We will re-open Thursday, January 2, 2024. Please expect slower response times during this period and open a support ticket for anything needing immediate assistance.
Happy Holidays!
Please note: most of Solace is closed December 25–January 2, and will re-open Tuesday, January 3, 2023.
Getting Solace broker's message receipt timestamp
Hi all -
We are trying to run some performance tests on HA Group Message Broker software (Primary/Backup) with Guaranteed Messaging.
We have a few clients that ingest messages to broker at a consistent rate. And, a receiver which receives messages as they put on EXCLUSIVE Queue.
Is there a provision to use any message header or something to get the actual timestamp that Solace "RECEIVED/SAVED to MessageSpool" timestamp from the broker.
Information available at following link to use "getReceiveTimeStamp()" seems little ambiguous. I'm confused that Producer has to populate this value? or Broker itself would populate the header value upon receipt of the message from producer? If yes, does it signify message receipt timestamp or message persist timestamp to message spool?
https://solace.com/blog/inside-a-solace-message-using-header-properties/
This information is useful in bench marking the behavior. Please help.
Thanks,
Raghu
Best Answers
-
We don't recommend message-level logging within the broker because the performance impact masks all the info you're trying to understand about performance. A good snapshot is available via 'show system health':
eventmesh> show system health Statistics since: Jan 02 2020 13:21:06 UTC Units Min Max Avg Curr Thresh Events ------ ------- ------- ------- ------- -------- ------- Disk Latency us 357 1864 942 809 10000000 0 Compute Latency us 900 3355305 1405 1101 500000 34 Network Latency us 0 0 0 0 2000000 0 Mate-Link Latency us 0 0 0 0 2000000 0You can also gather smooth RTT for each connection using SEMP queries via HTTP, for example:
{ "data":{ "clientAddress":"172.17.0.1:51372", "clientName":"testclient000001", "compression":false, "encryption":false, "fastRetransmitCount":0, "msgVpnName":"default", "rxQueueByteCount":0, "segmentReceivedOutOfOrderCount":0, "smoothedRoundTripTime":1894000, "tcpState":"established", "timedRetransmitCount":0, "txQueueByteCount":0, "uptime":36 }, "links":{ "uri":"http://localhost:8080/SEMP/v2/monitor/msgVpns/default/clients/testclient000001/connections/172.17.0.1%3A51372" }, "meta":{ "request":{ "method":"GET", "uri":"http://localhost:8080/SEMP/v2/monitor/msgVpns/default/clients/testclient000001/connections/172.17.0.1%3A51372" }, "responseCode":200 }6 -
Hey Raghu... as Ken said, the broker doesn't timestamp or log messages specifically for performance reasons. To measure the latency of your setup, the SdkPerf latency tests that Ken mentioned will provide a baseline of the latency between a publishing application and a consumer application through the Solace broker using our APIs. That will provide the bar from which to compare against. Then any additional latency you observe at the application layer would belong to your application.
Check these links, and let us know if you need more help:
https://docs.solace.com/SDKPerf/Example-Commands.htm
https://docs.solace.com/SDKPerf/Command-Line-Options.htm#Performa
https://solace.com/downloads/ (scroll all the way to the bottom for SdkPerf)5
![[Deleted User]](https://w9.vanillicon.com/v2/92ec916368359668b84da436190d19ac.svg)
Answers
-
Hi, we don't publish a distinct broker timestamp on the messages. However, if what you're trying to do is test latency, we have done a lot of that and built latency testing capabilities into the sdkperf test suite. SDKPerf publishers put a timestamp from the local clock into each message, and the consumers extract it from the message and measure the latency delta. Note that you'd need to run the producer and consumer on the same host so they have comparable timestamps.
Is that the kind of benchmarking you're interested in doing?
1 -
Hi Kov,
Thank you very much for the information.
Yes, we're looking for similar bench marking. However, trying to understand what broker metrics (from inside broker) we could propagate to Queue Consumers.
Also, is the logging enabled by default to track each message id in different hops to find out where the latency is?
For instance, Producer to Broker (Network), Broker to Message Spool (Disk latency), Broker to Consumer (Network) etc.
Wondering, if additional logging could help us understand the outliers better in high throughput scenarios. Does it write gigantic logs if we enable Debug option if any. Please suggest.Thanks,
Raghu0 -
We don't recommend message-level logging within the broker because the performance impact masks all the info you're trying to understand about performance. A good snapshot is available via 'show system health':
eventmesh> show system health Statistics since: Jan 02 2020 13:21:06 UTC Units Min Max Avg Curr Thresh Events ------ ------- ------- ------- ------- -------- ------- Disk Latency us 357 1864 942 809 10000000 0 Compute Latency us 900 3355305 1405 1101 500000 34 Network Latency us 0 0 0 0 2000000 0 Mate-Link Latency us 0 0 0 0 2000000 0You can also gather smooth RTT for each connection using SEMP queries via HTTP, for example:
{ "data":{ "clientAddress":"172.17.0.1:51372", "clientName":"testclient000001", "compression":false, "encryption":false, "fastRetransmitCount":0, "msgVpnName":"default", "rxQueueByteCount":0, "segmentReceivedOutOfOrderCount":0, "smoothedRoundTripTime":1894000, "tcpState":"established", "timedRetransmitCount":0, "txQueueByteCount":0, "uptime":36 }, "links":{ "uri":"http://localhost:8080/SEMP/v2/monitor/msgVpns/default/clients/testclient000001/connections/172.17.0.1%3A51372" }, "meta":{ "request":{ "method":"GET", "uri":"http://localhost:8080/SEMP/v2/monitor/msgVpns/default/clients/testclient000001/connections/172.17.0.1%3A51372" }, "responseCode":200 }6 -
Hey Raghu... as Ken said, the broker doesn't timestamp or log messages specifically for performance reasons. To measure the latency of your setup, the SdkPerf latency tests that Ken mentioned will provide a baseline of the latency between a publishing application and a consumer application through the Solace broker using our APIs. That will provide the bar from which to compare against. Then any additional latency you observe at the application layer would belong to your application.
Check these links, and let us know if you need more help:
https://docs.solace.com/SDKPerf/Example-Commands.htm
https://docs.solace.com/SDKPerf/Command-Line-Options.htm#Performa
https://solace.com/downloads/ (scroll all the way to the bottom for SdkPerf)5
