Difference between two adapters

[DarioCrivelli]

The log shows that there is an underlying frequency limit of 3 updates per second due to the license in use.
This accounts for the suppression of some update when two or more are produced in short interval.
As discussed above, you can request the item as unfiltered, but you must be sure that the average frequency of updates of this item is steadily less than 3 per second.
Otherwise you can use setRequestedBufferSize and determine a size that is a trade-off between possible lost (i.e filtered out) updates and possible update delays.

This does not explain why an item in COMMAND mode yields fewer updates than an equivalent item in MERGE mode.
We can investigate this case, but please provide some precise references.
If you saw this happening in the run of the provided log, please specify two item names for the COMMAND and MERGE subscriptions with different behaviors.

[ManKeer]

Thanks Dario,

But I need the answers for the following questions:

1 - Is there any way to increase the (max frequency update)/item/second to more than 3?
2 - What is the max message size that can be sent?
3 - for the purpose of BW, which is better: sending small message to equivalent item [ # items = 400]... OR.... combining all messages in one big message and send it to common item [common item for 400 items].

4 - for BW calculation purpose: each client has one connection (one session), it has subscribed for 100 items, each item has 3 updates per second as you mentioned, if each message size is 50 bytes, then BW required is:

100 * 3 * 50 * 8/1000 = 120 kbits/second, Am I right???

if we combine those 100 items in 1 item, the max message size is 5000 bytes, then new BW is:
1 * 3 * 5000 * 8/1000 = 120 kbits/second, same as above?

so if the above is true, I need to know what is the effect of large message size?

Thanks for your kind help and usual support.

[DarioCrivelli]

In a general scenario, separate items perform better, because it may happen that only part of the 100 items get an update, while others don't.
In this case, only the updates for items that really change are sent.
On the other hand, for a single big item, a single combined update is sent every time any of the 100 values included is different.
You could reduce this problem by using fields, so that you can use a single item with 100 different fields.
In this case, in the combined update, the values that don't change are not included.
But the set of fields is fixed, so this assumes that the needed set doesn't change in time.

So, only if you confirm that all 100 items change values every time, is your count correct, but for some encoding overhead to be added.
With different items the overhead is quite small (about a dozen bytes per update, hence to be added to the 50 figure).
With a single item, the Lightstreamer overhead is small, but the overhead needed to pack the 100 values in a single one has also to be considered.
More overhead is due the generation of websocket messages and TCP packets.
With many updates, Lightstreamer can pack multiple updates in a single message, but it tries to forge small messages, hence with 100 items it may use more messages and add some overhead, whereas with one big item it is forced to use a single message.
However, small messages give some benefits, for instance when the communication channel is narrow.

To resume, assuming that the bandwidth is the same (i.e. all values change every time), single large message should not have a negative impact.
The differences are at implementation level (like memory fragmentation) and should not be significant in normal situations.
In fact, Lightstreamer doesn't enforce a maximum message size.
Obviously, really big sizes may incur in resource issues, but a safety size is difficult to estimate.

About update frequency, you can experiment with unlimited frequency by configuring a DEMO license
(you should set DEMO in <license_type> and <contract_id> in lightstreamer_edition_conf.xml).
This limits the number of sessions to 20.
If you opt for upgrading your license, you can contact info@lightstreamer.com