7 Replies Latest reply on Sep 5, 2013 1:12 PM by werrenmi

    Max count of broadcast subscriptions

    werrenmi

      Hello

       

      In our application we use broadcasting on many places for server push. At the moment i try to optimize this broadcasts with more fine granulated subjects to minimize network round-trips because in our current implementation becomes too many clients informed about this pushes.

      But before i start to redesign this push semantics ... is there a threshold for how many broadcast subjects can be handled? And if there one exists give it a difference between Comet and Websockets?

       

      Best regards

      Michel

        • 1. Re: Max count of broadcast subscriptions
          jfuerth

          Hi Michel,

           

          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.

          1 of 1 people found this helpful
          • 2. Re: Max count of broadcast subscriptions
            werrenmi

            Hello Jonathan

             

            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.

            • 3. Re: Max count of broadcast subscriptions
              jfuerth

              That sounds like a reasonable scenario. I'll be interested to see your load testing results!

              • 4. Re: Max count of broadcast subscriptions
                werrenmi

                Hello Jonathan

                 

                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.

                 

                Edit:

                 

                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.

                 

                Regards

                Michel

                • 5. Re: Max count of broadcast subscriptions
                  jfuerth

                  Hi Michel,

                   

                  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!

                   

                  Cheers,

                  Jonathan

                  • 6. Re: Max count of broadcast subscriptions
                    nva

                    Hi Michel, what payload did you send? Errai Marshalling is great, but in my experience, sending large lists tends to take a while to demarshall on the client side. For performance critical communication I prefer bypassing the marshalling: I send a fully formatted JSON string from the server and load it into a Javascript Overlay on the client side. Not pretty, but it is lightning fast.

                     

                    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.

                     

                    Cheers,

                     

                    V.

                    • 7. Re: Max count of broadcast subscriptions
                      werrenmi

                      Hello Valentin

                       

                      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.

                       

                      Regards

                      Michel