Run a spike to create and run a benchmark to assess performance limits of webjive.

In the end we want UIs that are fast: they handle high levels of data rates for a long time. Each screen should be able to handle an update rate of 1000 updated items/sec.

We also want UIs that can open new screens and populate them with data very quickly. In less than 2 sec a new screen is launched.

The goal of the spike is to characterize performance of WebJive and understand how close it comes to the levels specified above. If limits are found, then further investigations may ensue to understand the causes of the bottlenecks and possibly find remedies. (This could occur within this spike or not).

NOTE: I expect that some ad-hoc architectural bypasses need to implemented/prototyped to bypass known bottlenecks and discover unknown ones.

Acceptance criteria

 We need to be able to answr these questions:

• how close can we get to the performance requirements mentioned above (refresh rate 1KHz, rendering of a dashboard in less than 2s)?
• what are the major 2-3 bottlenecks in webjive? what is their relative impact?
• can they be overcome/bypassed by changing the underlying architecture?