Thanks for your quick response Tom. Few points for our clarification:
- Shouldn’t the message latency decrease with increasing message Size only if its being cached inside the broker infra?
- We are ensuring that we send unique messages each time hence ideally they shouldn’t be cached as they are not repetitive in nature.
- We have the clients(pub, sub) running in laptops and we are connecting to solace cloud broker for transmission. In this, we are sending Direct messages in Loop as well as all at once along with variations in number of topics and number of subscribers. We were expecting to get linear/exponential pattern for this experiment i.e Linear increase in Transmission Time as the message Size increases and the same was observed for some instances. But when we reach towards the limit of per msg ( i.e 64Mb) we see Transmission time to dip. The stats are part of the session properties and message header which is a solace feature. Solace broker’s monitoring service would have ideally filled the TX Stats and Timestamps for the message as soon the the message is sent/received by it into a topic / queue. So why should the applications be kept active/busy after their jobs are done?
- We have some constraints where we need to measure the NFRs without any wait. We are sending messages in 10-70MBs for now and see that this dip towards 63MB. Is this an expected pattern?