1 of 1 people found this helpful
The server-side message bus code manages subscriptions using HashMaps keyed on the subject name. After a cursory search, I didn't find any code that iterates over all the keys in these subscription maps, so there shouldn't be any major performance penalties for having a large number of subject names in these maps.
Of course, code doesn't always perform the way we expect it to, and every environment and workload have their own special pathological cases. The best way to find the answer to your question is to devise a load test that exercises your whole app (including the Errai bus) in the same way (and with the same number of connected clients) you expect it to be exercised during peak times. If the performance meets doesn't meet your needs, use a profiler to find the hot spots.
Since you're considering a change to your existing app, it might be worthwhile to write a simple test app that subscribes to 5000 subjects (or more, depending on your needs), with a corresponding server-side service that periodically broadcasts to those subjects.
Thanks for your fast response.
We design our app for up to 1000 concurrent clients for different customers on the same AS instance. The clients for the same costumer receives a notification for each edit start and / or value change on dto fields.
Therefore theortical there can exists up to 10000 subscription, but in real this should never be the case.
I will test it and tell my results.
That sounds like a reasonable scenario. I'll be interested to see your load testing results!
After a first Test ... well done . It's quite hard to make a realistic test, since this can only be accomplished with 1000 really separate clients ... we are a small company . As workaround for 10 subscriptions per client, we have tested 1000 subscriptions per client. Server and each client on it's own host. The LAN is a 1 Gb
The test procedure was:
- One client (initiator) sends 1000 RPC's to the server.
- The server executes a broadcast for each of those RPC's.
- Any other client sends again a RPC's for each received broadcast (one time).
- The Server executes again a broadcast for each RPC.
- The first initiator client only counts the received broadcasts ... results in 10000 broadcasts.
Duration in our environment was 17 secs ... trully fast!
One bottleneck is for sure the CPU core count and performance of the server. The network payload size is much smaller as expect. The other the browser performance.
Maybe we find time to test the same procedure with websockets instead of Comet.
I forgot. We has tried to make a harder test as well, with 5000 subscriptions per client. But this seems to reach the possibility on the browsers, 2 ones was no more responsible during the test.
That sounds like a good test: you've got RPC requests coming from several clients simultaneously, you're forcing the server to do full-duplex communication, and most importantly you're verifying the accuracy of the results!
Thanks for taking the time to describe your test scenario. I hope this inspires others in the Errai community to run load simulations and stress tests on their systems too. It's never too early to learn how far you can push your system before it falls over!
Where demarshalling performance is not critical, either due to the use case or the amount/structure of data, definitely the Errai Marshalling is the way to go.
Yes, this is also my experience. The dto that will be send in both cases, the RPC's and broadcasts contains approximately the count and types of the real dto's of our application for the broadcast case. A couple of Strings, an Integer and one very simple collection.
I have attached the test project. Maybe its usable for others
Edit: The test project is ready to use ... to define the count of "bots" and subscriptions change the values in the BotInformation class ... done.