Firefox 3.0b5: Massive Comet Scalability

by Alessandro AlinoneApril 24th, 2008

Today a customer asked me if Lightstreamer works on Firefox 3.0 beta 5. I had tested previous beta versions of Firefox 3.0 but not yet beta 5. I was so impressed with its scalability (in terms of concurrent Comet sessions opened on multiple tabs) that I had to write this musing.

Basically, I was able to open 32 instances of the Stock List Demo on 32 tabs, with no significant slackenings. I stopped, but I could definitely open many more. [I did this test on a local network. Connecting to our server from the Internet could be slower. Does anybody feel like doing this test, that is, opening more tabs until the browser hangs? If so, Install Firefox 3.0, put "" in your clipboard, then start typing control-t,control-v (or command-t, command-v for Mac users of course), Enter. Please comment below on the results].

Firefox 3.0 beta 5

This test is possible because Lightstreamer does not suffer from the 2-connection limit. Multiple instances of a Comet application or even different Comet applications connecting to the same server can automatically share the same physical connection. In fact, after opening these 30+ instances, a netstat confirmed that one single socket was opened to the server.

Notice that this Stock List Demo is configured with a bandwidth limit of 30 kbits/s for the Comet socket. This means that all the instances will share this bandwidth limit. After opening many instances, you should notice a reduction in the update frequency (notice I said frequency reduction, not delivery delay. This is a key point of Adaptive Streaming and Congestion Control. In other words, you will see less updates, not old/delayed updates. I will probably return on this topic in a future article).

Besides, notice that each instance does its own subscriptions, that is, only the Comet channel is shared, while the subscriptions are completely independent. This is useful because each application could want to subscribe to the same items with different schemas and/or with a different quality of service (in terms of frequencies, buffering, etc.).

Let me know your thoughts.

4 Responses to “Firefox 3.0b5: Massive Comet Scalability”

  1. Brian Says:

    I’m a little fuzzy on what you’re trying to test. Are you opening tons of tabs to show that Firefox can duplicate sessions but merge the requests? That’s not surprising - it shares one session between all those tabs. FF2 does the same thing.

    I’m not sure how you would verify that all those tabs are concurrently processing updates, and not just running code on the active tab. Wouldn’t that also make it look like only one connection was in use?

    You really need to verify that you have 30 different sessions all concurrently requesting updates to completely different collections of stock lists before you get into a real-world scenario for stressing your application. If you could visibly verify that they’re each Comet application instance in each browser window was still receiving updates on unique data, then that would be certainly more convincing.

  2. Alessandro Alinone Says:

    Brian, with this experiment I was trying to show several aspects that have proven very important in real-world scenarios:

    1) It often happens that a Comet application (especially if not well tuned) tends to use much CPU on the client-side to process and display the updates. Having 30 concurrent front-ends pushing high-frequency data without cluttering the CPU surprised me a bit, because in the last eight years of Comet experience I’ve struggled many times with client-side CPU bottlenecks even on a single instance of an application.

    2) Running multiple instances of the same application, or multiple applications that connect to the same server, is exactly the same for the purpose of this test. In both the cases, the 2-connection limit would arise, if the Comet engine is not able to automatically multiplex multiple sessions on the top of a single session (and connection). This test shows that the automatic sharing of the Comet connection works well even across tons of instances.

    3) The subscriptions coming from each tab are completely independent. If you subscribed to different stocks from each tab, the result would be exactly the same. In other words, the data is sent from the server to each table individually. You can appreciate that by opening so many tabs that you saturate the allocated bandwidth (30 kbits/sec; opening 30 tabs is more than enough) and noticing that the data is not in sync. The reason is that the data is sampled on the server side independently for each subscription. Notice that out-of-sync does not mean delayed or incoherent. To understand this, do this experiment: click on a high-frequency stock (for example “Ations Europe”) to display its real-time graph. You will see that the popup window shows data sampled at 3 updates/sec, while the main windows shows the same data sampled at 0.5 updates/sec. They are two independent subscriptions to the same item, that is sampled on the server side with different frequencies. The same applies across multiple tabs. Even if they all subscribe to the same item at 0.5 updates/sec max frequency, they are all sampled independently, leading to different views across the tabs when the server has to throttle the outbound flow. Of course, if an application has the requirement to show exactly the same samples of the data cross multiple views or instances, there are many ways to achieve that with Lightstreamer. You can see this behavior very well by sniffing the network traffic.

    4) Only one tab contains and handles the actual connection to Lightstreamer Server (such tab is said to host the “Master Push-Page”), while the others (that host normal “Push-Pages”) attach to it. The Master Push-Page is contained in the first tab. That means that if you close the first tab, all the other tabs will stop receiving data, because the Comet connection is broken. But the magic comes from the automatic “engine migration”. If you close the first tab, after a few seconds the other Push-Pages will elect a new Master, the Comet connection will migrate to it, and all the tabs will attach to it and recover their subscriptions. Give it a try.

  3. Aman Gupta Says:

    How do you get multiple tabs/windows to share one comet connection?

  4. Alessandro Alinone Says:

    [UPDATE] The final version of Firefox 3 has fully confirmed these impressive results. A video is available on Lightstreamer’s blog:

Copyright 2015 Comet Daily, LLC. All Rights Reserved