I think we are good let's close this issue.

If those two number match and the collection set generation (the stress command) takes account for the bulk of the processing time then we're in a good place. I suspect the generation is being limited by some other factor like memory/GC.

Based on the latest results from the profile above we've show that the performance of the TSS integration layer is sufficient and the rest is really up to the plugin implementation.

I'm good to resolve this with the results we have unless you think something warrants further research. 

I think they more or less do. Here is a comparison between the two:

Open

But the events generation rate by the stress command doesn't seem to be ~40k but ~11k for numeric attributes and ~4,5k for string attributes.

It promised ~41k:

Open

My CPU seems to hover around 50% for all cores:

Open

it almost  looks like the cpu usage is caped at 50%.

Looking at the profiler it shows me most time is spent generating the events by the stress command, logging and karaf:

Open

=> Maybe my local system is just not performant enough to produce the 41k?

For the case of the in-memory plugin:

I would expect the number of samples/sec reported by the plugin to match the number of "numeric attributes per second" reported by the stress tool.

We need to figure out why these don't match and understand where the time is being spent.

@Jesse White, I finished the investigation.
Probably it's best to go together over the results?
Let me know.