We know of an implementation in which a single topic carries updates for a set of items and JMS selectors are used by the Data Adapter in order to extract from the topic only the currently subscribed items.
And that message rate is not smaller than yours.
However, the performance may depend on the specific JMS implementation.
Note that a topic guarantees the order of the messages and packing all the items in the same topic causes the inter-item message ordering to be maintained;
this is an unneeded effort, as then Lightstreamer only guarantees intra-item message ordering.
Lightstreamer can handle a 400 messages per second inbound traffic on normal machines. However, if you can accept a filtered flow on your clients and want to ensure maximim scalability, it could be beneficial filtering the flow at the origin.
Note that you don't need to put a filter before JMS or in the Data Adapter, but you can rather take advantage of the Preprocessor (
see this FAQ for an introduction).
But consider that the filtering only works at item level. It is not clear to me if a "market" corresponds to an item or to multiple items. If your 20 updates per second for a market are broadly distributed among a large number of items, no filtering is possible.
May you please clarify your second question?
Do you refer to configuring filtering? Or to refusing subscriptions? Or to discarding events? Or to sending user-specific events?
Or to something else?
