server bottleneck

[PaulW]

Thank you for your reply. I am attaching a screenshot of the VisualVM output showing high CPU usage by the PUMP POOLED threads and o.b.e.d and o.b.g.j methods. The method g.b.b.a also has a very high "Self Time" but does not appear to be the CPU bottleneck. I am using the latest version of Lightstreamer Moderato (Lightstreamer 6.0 b1 build 20140801). If you open the lightstreamer.jar file as a zip archive, the file /com/lightstreamer/o/b/e.class contains the method "d" and /com/lightstreamer/o/b/g.class contains the method "j". I am sending the ADD commands as real-time updates.

[DarioCrivelli]

The results from the VisualVM are quite puzzling, because they don't mention other methods invoked beside the two marked as hot spots;
and also because the first one is a two-line-long final method that I expected to be expanded inline by the JVM.
But, indeed, they spot an operation that is likely to be involved in this CPU problem; and it is not easy to fix it.
Actually, your usage of the COMMAND mode, by sending thousands of real-time ADD events in a loop, is a use case that was not expected and was not optimized properly.

You could resort to the snapshot case and send the events that make up a search result as part of a snapshot.
This means that you cannot have a persistent subscription on which to send the search results, but that you have to perform a one-shot subscription for each search, so that you can leverage the snapshot for the answer.
The snapshot in COMMAND mode is handled in a different way that does not involve the reported bottleneck.