Real time resource tracking use case

[DarioCrivelli]

I confirm that the number of items that can be processed is only limited by system resources. The memory requirements of using items instead of fields (let's say two items with one field each versus one item with two fields) are certainly higher. But in a case in which only one client subscribes to all these items, the difference should not be of an order of magnitude.
Note that the client doesn't need to specify every single item upon subscription, as it can use a "group name" that will be expanded by the Metadata Adapter. The matter would be similar for fields, where you can specify a "schema name".

In terms of CPU, the operations upon each field update are similar in the two cases. If the updates provided by the back-end come in separate events for the different fields, then keeping them separated on different items may be beneficial.
But we don't have formulas to predict the impact and rely on customer tests on the specific scenarios.

I appreciate your suggestion and agree that this use case is suitable for a Lightstreamer demo. Since this is not our application field, do you have any sample code to share, particularly for a realistic car movement simulator?

[mkgn]

At the moment I am building a mock-up application to simulate this use case and also to test the limits of Lightstreamer. I have talked to three car rental services and each of them has around 150-300 cars. Usually about 70%-90% of them are constantly active (taking passengers to destinations).

Considering the discussion we had, I thought to keep the car registration no. as the item name in the backend. Every car will push it's location every 5 seconds. Which means there can be around 600 items (600 cars from 3 car rental services). Now I am not sure whether 600 items is too much for Lightstreamer.

Then I got confused with one thing (May be too much forum reading, API docs etc... ). http://forums.lightstreamer.com/show...ndMessage+item

http://forums.lightstreamer.com/show...-back-using-LS

Problem is, individual car should only send it's location to it's own item which is named after car registration no in LS. Car owner(s) has a dashboard with a map where he subscribe to X amount of items (cars) from LS client. This is my problem. In the client, should I subscribe to each car item that i own? This seems very inefficient.

What if I have an item per owner where all the cars of that owner send it's location to one item(say company name). So any employees has only one item to watch for (similar to a chat room). Since all cars are now pushing to same item, to differentiate and do any processing we can send a car registration no and other data such as {car : XYZ, speed:10, distance:100} etc... At the place where LS picks the data, we can parse it and do whatever we want.

What do you think? I will surely submit the code once i get through this. At the moment I am confused about certain things.

[DarioCrivelli]

The number of items is not a problem per se; it only adds some memory requirement, as said, but a light one. Tens of thousands of items are normally managed by production LS applications.
The heavy part can be the management of the update flow, particularly for the client, if it has to plot all positions of all cars. But this load is the same, regardless that the updates are related with multiple items or always the same.

Your proposal is also feasible; if I understand correctly, there is a single item with fixed fields which multiplexes the updates of the various cars. This can be done with DISTINCT mode, which (unlike MERGE mode) ensures that different updates are never conflated (so, if you update a car and omit a field, this field will not be filled with the previous update, which can refer to a different car).
Obviously, this is suitable for the clients which want to see all cars, not for clients interested in a single car.
The problem is that, if the overall flow is too heavy for the client and you try to leverage the frequency limit offered by Lightstreamer to resample the data, there is no guarantee that some car won't have all its updates filtered out. On the other hand, with separate items, if you set frequency limits on each, the Server applies a round-robin behavior.

Let me stress that even with one item per car there is no need for the client to explicitly subscribe to all cars.
The simplest thing to do is getting the list of cars from the Server as well, by using "two-level push". This is shown in our portfolio demo, which is similar, as you actually manage portfolios of cars.
This implies some work on the client side, to get the list of cars and subscribe to each car, but this is handled by Lightstreamer Web Client library, which supports two-level push directly, as the demo subscripion code shows.
Under the hood, all single subscriptions for each car still take place and this may be inefficient; but the figures involved should be manageable. Should scalability requirements come, a more complicated strategy could be devised.