Comet Server Performance – Who’s The Winner?


Interesting posting from Caplin on Comet performance, and how Caplin believe they stack up against the competition. I wonder if any other product company will counter with a posting? Maybe StreamHub (missed form Caplin’s posting) are interesting is providing some performance data?

~ by mdavey on May 5, 2010.

Posted in Trading

4 Responses to “Comet Server Performance – Who’s The Winner?”

  1. Thanks for the mention Matt – I posted a comment back on our blog.

    I am aware of StreamHub but they haven’t come up much around here, looks like it’s Java based with a JSON client side protocol.

    I’d welcome more published performance figures, we should have some new ones soon ourselves.

    Martin Tyler said this on May 5, 2010 at 11:16 am | Reply

  2. Paul’s sweeping attempt at classifying everything that might offer a realtime messaging capability via the Internet as Comet demonstrates a lack of understanding of the issues faced when implementing such multi platform streaming solutions for SDP. Comet, while relevant, in no way represents every product in this space, it simply (as the wiki link he included states) represents a number of techniques that enable the streaming of data from a server to a browser.

    Nirvana ( http://www.my-channels.com/ ) supports Comet ( and the WebSocket protocol )for our Javascript browser based clients however we do so much more than Comet for all of our other supported Enterprise, Web and Mobile clients.

    While the 9 questions Paul defines are relevant they are far from complete and although integration is mentioned in the prequel to the list it is subsequently glossed over. To establish a more complete list of discussion points to aid these types of technology decision one might also include:

    – Support for clustering and failover approaches this enabling compliance with business contingency policies.
    – Support for standards. Things like HTML5 WebSocket support, AMQP, JMS etc.
    – Support for integration with 3rd party technologies. Not just back end but client side integration for end to end B2B type solutions
    – Support for integration with existing enterprise management technologies. Measuring end to end latency is only possible if the underlying technologies used supports such functionality and expose it in administration and management API’s and tools.
    – Security, not just SSO but an understanding of authentication and entitlements and how such functionality can be leveraged in client implementations
    – Configuration management, both client and server. Snapshotting production environments, being able to roll back configurations and quickly deploy new instances.
    – Support for different messaging paradigms. Not everything fits into a publish/subscribe model. Some interactions require point to point or queue based communications.
    – Support for different deployment topologies, i.e broker and brokerless based servers, caching severs and server federation.

    Finally on the subject of performance in our experience clients pay little attention to vendor published results and always understandably insist on establishing what is possible in their respective environments; typically via a vendor bake off. To date Nirvana has proven to be very successful in these real world test case scenarios and consequently is used today by some of the worlds leading SDP implementations.

    Perhaps market share and implementation base should also be included in the questions to be asked !

    Paul Brant said this on May 5, 2010 at 6:59 pm | Reply

  3. Attractive component of content. I simply stumbled upon your weblog and in accession capital to
    assert that I acquire in fact loved account your blog
    posts. Anyway I will be subscribing on your feeds and even I success you get entry to persistently fast.

    comprar en tienda erotica said this on August 18, 2015 at 3:43 am | Reply

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.