Performance of content filter

Hi Josef,

The section 5.4.2 of the RTI Core Libraries and Utilities Users Manual specifies all the coniditions that needs to be satisfied inorder to perform writer side filtering. I have listed the section below:

A DataWriter will automatically filter data samples for a DataReader if all of the following are
true; otherwise filtering is performed by the DataReader.
1. The DataWriter is filtering for no more than writer_resource_limits.max_remote_reader_filters DataReaders at the same time.

• There is a resource-limit on the DataWriter called writer_resource_limits.max_remote_reader_filters (see DATA_WRITER_RESOURCE_LIMITS QosPolicy (DDS Extension) (Section 6.5.4)).This value can be from 0-32. 0 means do not filter any DataReader and 32 (default value) means filter up to 32 DataReaders.
• If a DataWriter is filtering max_remote_reader_filters DataReaders at the same time and a new filtered DataReader is created, then the newly created DataReader (max_remote_reader_filters + 1) is not filtered. Even if one of the first (max_remote_reader_filters) DataReaders is deleted, that already created DataReader (max_remote_reader_filters + 1) will still not be filtered. However, any subsequently created DataReaders will be filtered as long as the  number of DataReaders currently being filtered is not more than writer_resource_limits.max_remote_reader_filters.

2. The DataReader is not subscribing to data using multicast.
3. There are no more than 4 matching DataReaders in the same locator (see Peer Descriptor Format (Section 14.2.1)).
4. The DataWriter has infinite liveliness. (See LIVELINESS QosPolicy (Section 6.5.13).)
5. The DataWriter is not using an Asynchronous Publisher. (That is, the DataWriter’s PUBLISH_MODE QosPolicy (DDS Extension) (Section 6.5.18) kind is set to DDS_SYNCHRONOUS_PUBLISHER_MODE_QOS.) See Note  elow.
6. If you are using a custom filter (not the default one), it must be registered in the DomainParticipant of the DataWriter and the DataReader.

Notes:
Connext supports limited writer-side filtering if asynchronous publishing is enabled. The mid-
dleware will not send any sample to a destination if the sample is filtered out by all the
DataReaders on that destination. However, if there is one DataReader to which the sample has to
be sent, all the DataReaders on the destination will do reader side filtering for the incoming sam-
ple.
In addition to filtering new samples, a DataWriter can also be configured to filter previously
written samples stored in the DataWriter’s queue for newly discovered DataReaders. To do so,
use the refilter field in the DataWriter’s HISTORY QosPolicy (Section 6.5.10).

To check if the filtering is being performed on the reader you can monitor the value of the filtered_sample_count in the DDS_DataReaderProtocolStatus. You can use the get_datareader_protocol_status api to query the current value of DDS_DataReaderProtocolStatus.

Inorder to understand the performance difference that you are observing when using content filter, I will need some more information about your test:

1. How many data readers do you have with content filters installed?
2. In your test are you writing samples for the same instance or different instances? If you are writing for different instances then can you specify how many samples are you writing per instance on an average?
3. Are you measuring the throughput on the reader side or on the writer side? If you are mesuring throughput on the reader side then are you taking into account the samples that might have been filtered and hence never received by the reader?

Also it will be helpful if you are able to send me a reproducer inorder to look into this further.

Regards,

Roshan

Hi Josef:

I'd like to follow up on what Roshan asked about your test sending new instances every time, or multiple samples for a small set of instances.

When filtering on key fields ONLY (i.e., the filter does not filter on anything other than key fields), once an instance has been filtered, the filter can cache the results of the filter (pass or fail). When subsequent samples of that instance need to be filtered, Connext DDS checks the cache results based on the instance handle, and avoids the need to filter the actual sample.

Especially when using DynamicData, which deserializes the sample before filtering, saving the overhead of deserialization and filtering can result in a significant improvement in performance. But this improvement is only realized if the filter has seen that instance before. If the test is always sending new instances (such as writing an incrementing value in the key field) then the optimization is never invoked.

Filters that include non-key fields, or types that have so many key fields that every sample is its own instance, prevent this optimization from being utilized.

As you can see, both the design on the test, and the design of the filter, can significantly influence the performance results you get.

Regards,

Kevin

Hi Josef,

I was looking through the reproducer you have attached. One thing I noticed is that you have added "CEP" as a NONKEY_MEMBER. So the type you are using is not a keyed type and hence the optimization will not take effect. If you want the member to be used as a key then use the following snippet;

structTc->add_member("CEP",-1,factory->get_primitive_tc(DDS_TK_USHORT),DDS_TYPECODE_KEY_MEMBER,ex);

if (ex != DDS_NO_EXCEPTION_CODE) {

    std::cerr << "! Unable to add member to struct typecode, error=" << ex << std::endl;

    goto done;
}

Can you give that a try and see if you are getting better results? In the meantime I am also trying to reproduce the behavior you are observing.

Regards,

Roshan

Hi Josef,

I tried compiling the application you provided but ran into issues with that. So instead I have updated the shipped Hello_dynamic example to include the changes you made for using CFT and ran some tests inhouse.

In my tests I was able to verify that when using Content Filtered Topic where the filter expression is only based on a key fields there is about 20% degradation in throughput. Note that I am not able to reproduce the 50 times degradation that you have reported. 

Also note that with some Qos modifications I am even able to achieve ~0% degradation in throughput.

I noticed that in your test you were writing to 2 different instances but the filter expression was filtering for only one of the instances being written. So when measuring the throughput on the subscriber you were only considering 50% of the samples that were originally being written. So the throughput stats being reported on the subscriber application was not reflective of the actual throughput the publishing application was able to achieve. In my test I have changed this so that the filter expression is filtering for all the instances that are being written.

I am attaching the updated Hello_dynamic code so that you can run the same test and verify if you see a similar behavior. I have added 2 new parameters to the application:

• -instanceVal <value> : This is the value that will be assigned to CEP (key field) when publishing. On the subscriber if content filter is being used then the expression will be CEP = <value>.If this option is not provided then the publisher will switch between CEP=384 and CEP=640 and the subscriber if using content filter will have the expression (CEP=384) or (CEP=640)
• -useCft                     : This option enables the use of content filter on the subscriber application. This is not needed on the publisher application.

Also note that with the USER_QOS_PROFILES.xml that I have provided here I expect ~0% degradation in throughput. 

If required do modify the application to reproduce the original problem you were reporting and send it back to me.

Regards,

Roshan