Hi
I am trying to optimize the performance in a system of 10 workstations. On 5 of the workstations there are 2 participants running so that there are 15 participants in total. On every workstation there is one participant how is subscribing to 1000 topics and the remaining 5 participants are subscribing to 500 topics. The topics have an average size of 28 bytes.
One of the participants is also the publisher of the 1000 topics.
The scenario that I am optimizing for is that the publisher will updates the 1000 topics twice quickly. Once the subscribers have received the 2000 or 1000 samples they will reply on a shared topic. The publisher will then measure the time it takes to get acknowledgement from all subscribers.
I started by enabling batch this improved performance by about 300%, however it did not improve as much as I had hoped for. My guess is that it is because batch will only batch samples from the same topic together (right?). So in my case I only reduced the UDP packets by 50% despite the samples being very small. What I was hoping for is that I could batch samples for different topics together and there by utilize the network even more by creating very big ethernet packets, like a TCP/IP connection would do.
The two solution that I guess might improve the performance is.
1) Switching to TCP/IP for the communication.
2) Use multicast to send the samples.
But I would like to know if there are any other ways that I can optimize this scenario?
I have attached the USER_QOS_PROFILES.xml that I have used.
Thanks for any input
| Attachment | Size |
|---|---|
 user_qos_profiles.xml | 3.32 KB |
Hello Kennet,
That seems like a lot of Topics for system with just 15 DomainParticipants...
Are these all different data-types? Are you defining a DDS "key" in Topics? I have seen that sometimes people use many Topics because they did not define a "key" in their data-types and/or they are trying have DataReaders and DataWriters match just on the Topic name without using content-filtered Topics.
Having many Topics results on many DataWriters and DataReaders. This has significant overhead and optimizations like "batching" do not apply for samples written by different DataWriters.
I believe that using TCP instead of UDP will not help much, if any, in your situation. The overhead is mostly at the RTPS protocol layer which is above both UDP and TCP.
If you can design your system with fewer Topics and use keys, you can get the same effect with fewer DataWriters. You can also use content-filtered topics to limit the data that each DataReader gets. This can go down to selecting a single key which will give you the same effect as having a separate Topic but consuming a lot less resources.
There are other optimizations that could be applied once you have fewer topics and rely on keys, for example using the MULTICHANNEL Qos Policy in combination with multicast.
You may also want to take a look at some of the tips in the best-practices page.
If you can describe your system a bit more in terms of data-types and publish-subscribe topology we could try to give you more specific suggestions.
Regards,
Gerardo
Hello
Thanks, you for the quick reply.
I am investigating if I can replace an existing messaging system with a DDS solution via an adaptor.
The existing system uses many topics so I was hoping for the same topic layout in the global data space in order to make a transition as smooth as possible. Because the existing solution does not have keyed topics I am not using it in the DDS either. Also using keyed topics would mean I need to change the existing topic names and this would make it difficult for the adaptor on the subscriber side to figure out what new topic name to subscribe to find the original topic name. There is of cause ways to do this but for now I just want to stick with none keyed topics to keep the adaptor simple.
So I am just trying to squeeze as much performance out of the DDS adaptor as possible to make it perform as fast as the existing solution and then later we would most likely change to keyed topics.
To answer the questions the data-types are not all different but many of them are. I cannot put an exact number on it sorry.
I do not fully understand why the use of TCP would not improve performance. I can see that currently when I test I get 2000 ethernet frames with a size of about 218 bytes each. If these are send via a single TCP/IP connection I assume that the Nagle's algorithm would result in packets of 1500 bytes.
Is it because the RTPS protocol layer will use a TCP/IP connection for each datawriter to each datareader and not from one participant to another?
Thanks
thanks, this solution worked for me <3
oliver
liteblue