Re: [cometd-users] Cometd vs socket.io
1,068 views
Skip to first unread message
Simone Bordet
Mar 4, 2013, 4:43:05 PM3/4/13
to cometd-users
Hi,
On Mon, Mar 4, 2013 at 10:18 PM, Anqing Xu <anqi...@gmail.com> wrote:
> Hi,
>
> I want to add some real time features to a web portal that is relatively
> well established. The server is JEE based and we use Websphere v7. The UI
> is mostly Ext JS based. In other words the team is pretty savvy with both
> java and javascript.
>
> Now we need to add some real time trading features to the platform and I
> need some advice on which technology to adopt. It seems that websocket is
> the future but I don't see websocket as a realistic option because my
> customer base is enterprise and enterprise mostly uses IE.
> It seems that websocket is only supported on IE 10 and it will take years
> for IE 10 to be widely adopted in enterprise. So I need a technology that
> fills the gap.
>
> After some study, I've narrowed down my choices to cometd and socket.io. I'm
> new to both technologies. Here is my understanding:
>
> 1). Both cometd and socket.io support websocket if both server and browser
> supports it. If not, they both have fallback options such as flex socket,
> long polling etc. They are not that different in the aspect.
>
> 2). On the server side, it seems that cometd goes well with jetty, maybe
> with Tomcat 7 which has asynchronous servlet support but definitely not
> Websphere 7. So I may have to switch to a totally different web server such
> as Jetty. We use both Websphere and Tomcat 7 in our environment and feel
> comfortable with both but Jetty is a different story although I'm sure we
> can get up to speed with Jetty if needed.
Yes. The concepts behind are the same, so it should not take long to
get up to speed with Jetty.
> Can I expect mission critical
> quality real time features if we use Cometd inside Tomcat 7? Or it is
> better to just go with Jetty + Cometd if I choose to go with Cometd?
Tomcat has shown so far a less robust Servlet 3 implementation, with
several bugs reported, just browse this list's archives for more
information.
Jetty has been really stable for years now (since Jetty has been the
introducer of the async servlet technology).
See benchmarks here:
http://webtide.intalio.com/2011/09/cometd-2-4-0-websocket-benchmarks/.
We're working on an updated benchmark with Jetty 9 and CometD 3, but
it will take some more time.
> 3). On the browser side, most of our customers use IE, either IE 7, IE 8 or
> IE 9. Can I expect REAL real time performance with IE since it does not
> support websocket? My understanding is that websocket needs both server and
> browser support. If I go with Jetty + cometd, which will support websocket
> on the server side, but if we browser is IE 8 or IE 9, what should I expect?
> I guess websocket is out, right?
Correct.
> What kind of performance should I expect?
> This is a real time financial trading system so it is really mission
> critical.
It depends a lot on how you have implemented the JS application that
runs on the browser.
I have seen implemented a number of tricks here: since you're dealing
with humans, if the price changes every 10 ms, there is no point in
sending updates every 10 ms: the human eye will not be able to see it.
Depending on the use case, you can send messages to clients every 500
ms or 1 second.
On server side, CometD has shown to be able to process hundreds of
thousands of messages per second without problems.
So it's not much the client side performance that you should worry
about... even IE7 is probably able to display 1-2 messages/s.
Depending on your numbers, you want to scale on server-side.
> 4). My understanding is that socket.io is deployed in its own standalone
> node.js server. You can't embed it inside a JEE web server. The problem is
> that my platform is JEE based and I can't afford to rewrite everything in
> node.js.
I'm no expert in node.js, but at conferences it was kind of
interesting seeing node.js sessions presenting numbers like 1k users
at 100 messages/s, while we were presenting 100k users at 50k
messages/s.
Be totally sure that node.js scales for your needs - you might not
find what you expect.
--
Simone Bordet
----
http://cometd.org
http://webtide.com
http://intalio.com
Developer advice, training, services and support
from the Jetty & CometD experts.
Intalio, the modern way to build business applications.
On Mon, Mar 4, 2013 at 10:18 PM, Anqing Xu <anqi...@gmail.com> wrote:
> Hi,
>
> I want to add some real time features to a web portal that is relatively
> well established. The server is JEE based and we use Websphere v7. The UI
> is mostly Ext JS based. In other words the team is pretty savvy with both
> java and javascript.
>
> Now we need to add some real time trading features to the platform and I
> need some advice on which technology to adopt. It seems that websocket is
> the future but I don't see websocket as a realistic option because my
> customer base is enterprise and enterprise mostly uses IE.
> It seems that websocket is only supported on IE 10 and it will take years
> for IE 10 to be widely adopted in enterprise. So I need a technology that
> fills the gap.
>
> After some study, I've narrowed down my choices to cometd and socket.io. I'm
> new to both technologies. Here is my understanding:
>
> 1). Both cometd and socket.io support websocket if both server and browser
> supports it. If not, they both have fallback options such as flex socket,
> long polling etc. They are not that different in the aspect.
>
> 2). On the server side, it seems that cometd goes well with jetty, maybe
> with Tomcat 7 which has asynchronous servlet support but definitely not
> Websphere 7. So I may have to switch to a totally different web server such
> as Jetty. We use both Websphere and Tomcat 7 in our environment and feel
> comfortable with both but Jetty is a different story although I'm sure we
> can get up to speed with Jetty if needed.
Yes. The concepts behind are the same, so it should not take long to
get up to speed with Jetty.
> Can I expect mission critical
> quality real time features if we use Cometd inside Tomcat 7? Or it is
> better to just go with Jetty + Cometd if I choose to go with Cometd?
Tomcat has shown so far a less robust Servlet 3 implementation, with
several bugs reported, just browse this list's archives for more
information.
Jetty has been really stable for years now (since Jetty has been the
introducer of the async servlet technology).
See benchmarks here:
http://webtide.intalio.com/2011/09/cometd-2-4-0-websocket-benchmarks/.
We're working on an updated benchmark with Jetty 9 and CometD 3, but
it will take some more time.
> 3). On the browser side, most of our customers use IE, either IE 7, IE 8 or
> IE 9. Can I expect REAL real time performance with IE since it does not
> support websocket? My understanding is that websocket needs both server and
> browser support. If I go with Jetty + cometd, which will support websocket
> on the server side, but if we browser is IE 8 or IE 9, what should I expect?
> I guess websocket is out, right?
Correct.
> What kind of performance should I expect?
> This is a real time financial trading system so it is really mission
> critical.
It depends a lot on how you have implemented the JS application that
runs on the browser.
I have seen implemented a number of tricks here: since you're dealing
with humans, if the price changes every 10 ms, there is no point in
sending updates every 10 ms: the human eye will not be able to see it.
Depending on the use case, you can send messages to clients every 500
ms or 1 second.
On server side, CometD has shown to be able to process hundreds of
thousands of messages per second without problems.
So it's not much the client side performance that you should worry
about... even IE7 is probably able to display 1-2 messages/s.
Depending on your numbers, you want to scale on server-side.
> 4). My understanding is that socket.io is deployed in its own standalone
> node.js server. You can't embed it inside a JEE web server. The problem is
> that my platform is JEE based and I can't afford to rewrite everything in
> node.js.
I'm no expert in node.js, but at conferences it was kind of
interesting seeing node.js sessions presenting numbers like 1k users
at 100 messages/s, while we were presenting 100k users at 50k
messages/s.
Be totally sure that node.js scales for your needs - you might not
find what you expect.
--
Simone Bordet
----
http://cometd.org
http://webtide.com
http://intalio.com
Developer advice, training, services and support
from the Jetty & CometD experts.
Intalio, the modern way to build business applications.
Greg Wilkins
Sep 4, 2013, 8:36:51 PM9/4/13
to cometd...@googlegroups.com
On 5 March 2013 08:18, Anqing Xu <anqi...@gmail.com> wrote:
What kind of performance should I expect? This is a real time financial trading system so it is really mission critical.
Anqing,
Cometd has been used for financial trading applications with success before. We have used it to implement an in house forex trading desk where the users were in house traders that were extremely sensitive to latency. Cometd was able to provide low latency low jitter price feeds and trading responses that kept those traders more than happy.
It has also been used to public portfolios prices in retail applications. In this case performance is measured more in terms of numbers of users rather than latency. Cometd has performed well in that case.
Now the holey grail is to have all of the above - low latency, low jitter and large numbers of users. We have implemented non financial applications that test cometd in this scenario, but latency and jitter are very much dependant on the quality of the clients network connection. However a single server can definitely support many thousands of simultaneous users and give them a very low latency increment over what the network imposes.
regards
--
Greg Wilkins <gr...@intalio.com>
http://www.webtide.com
Developer advice and support from the Jetty & CometD experts.
Valerio Celletti
Oct 2, 2013, 9:22:41 AM10/2/13
to cometd...@googlegroups.com
Hi Anqing,
If you want to add real-time trading features to your web portal (which you stated that is well established, so I must assume that a not negligible number of concurrent users will use this feature after its release) then you should definitely consider Lightstreamer, as I checked your requirements accurately and it seems that it can do the trick without a huge effort.
I do agree that plain websockets are not a viable solution right now, as a number of browsers still don't support them. Plus, even if this is not your case - you are talking about enterprise desktop browsers-, but be aware that a number of 3G/LTE operators currently are blocking them. In any case, the real advantage of WebSockets arises for bi-directional communication, that is, when you send low latency updates FROM the client to the SERVER. Lightstreamer can choose the best transport among the many available (e.g http streaming), passing through any existing proxies and firewalls, so I guess this could be a plus in a corporate context.
Let me give you more details
1) Read above. Lightstreamer offers an excellent fallback mechanism as it can adapt the transmission to the actual browser, device and connection of each single client.
3) With Lightstreamer you definitely can have great performance even to "old fashioned" browsers. It has been deployed in a number of mission-critical projects within the financial industry, and many of them had the same concerns. Feel free to ask for more details, see a partial list of customers or just check some case studies on the blog.
We also recently issued an apple-to-apple data broadcasting comparison with socket.io (messages generated on the server side and sent to over 4 thousand clients, ran over two Amazon EC2 Machines) and LS proved to be able to scale better in terms of CPU usage, data latency, and bandwidth consumption, with some other useful features to improve the overall performance. Have a look at here. The same benchmarking kit has been left on GitHub, so you can get it and test other scenarios.
Hope that helps!
Regards,
Valerio
[full disclosure: I work for LS].
If you want to add real-time trading features to your web portal (which you stated that is well established, so I must assume that a not negligible number of concurrent users will use this feature after its release) then you should definitely consider Lightstreamer, as I checked your requirements accurately and it seems that it can do the trick without a huge effort.
I do agree that plain websockets are not a viable solution right now, as a number of browsers still don't support them. Plus, even if this is not your case - you are talking about enterprise desktop browsers-, but be aware that a number of 3G/LTE operators currently are blocking them. In any case, the real advantage of WebSockets arises for bi-directional communication, that is, when you send low latency updates FROM the client to the SERVER. Lightstreamer can choose the best transport among the many available (e.g http streaming), passing through any existing proxies and firewalls, so I guess this could be a plus in a corporate context.
Let me give you more details
1) Read above. Lightstreamer offers an excellent fallback mechanism as it can adapt the transmission to the actual browser, device and connection of each single client.
3) With Lightstreamer you definitely can have great performance even to "old fashioned" browsers. It has been deployed in a number of mission-critical projects within the financial industry, and many of them had the same concerns. Feel free to ask for more details, see a partial list of customers or just check some case studies on the blog.
We also recently issued an apple-to-apple data broadcasting comparison with socket.io (messages generated on the server side and sent to over 4 thousand clients, ran over two Amazon EC2 Machines) and LS proved to be able to scale better in terms of CPU usage, data latency, and bandwidth consumption, with some other useful features to improve the overall performance. Have a look at here. The same benchmarking kit has been left on GitHub, so you can get it and test other scenarios.
Hope that helps!
Regards,
Valerio
[full disclosure: I work for LS].
Simone Bordet
Oct 2, 2013, 10:26:07 AM10/2/13
to cometd-users
Valerio,
On Wed, Oct 2, 2013 at 3:22 PM, Valerio Celletti
<valerio....@lightstreamer.com> wrote:
> Hi Anqing,
>
> If you want to add real-time trading features to your web portal (which you
> stated that is well established, so I must assume that a not negligible
> number of concurrent users will use this feature after its release) then you
> should definitely consider Lightstreamer, as I checked your requirements
> accurately and it seems that it can do the trick without a huge effort.
While I appreciate you contributing/looking at CometD, your marketing
emails can go up to a certain point, which I think you surpassed with
this email in this public mailing list for an open source project
competitor with your closed source product.
The discussion here was about CometD and socket.io, and you moved it
to a LightStreamer advertisement.
> I do agree that plain websockets are not a viable solution right now, as a
> number of browsers still don't support them.
The majority of them do, well beyond 70%. So WebSocket *is* a viable
solution for 70% of the market out there.
> Plus, even if this is not your
> case - you are talking about enterprise desktop browsers-, but be aware that
> a number of 3G/LTE operators currently are blocking them.
I am not aware of this from our clients' reports, and even so, there
are easy workarounds.
Which providers you know that block WebSocket traffic ?
> In any case, the
> real advantage of WebSockets arises for bi-directional communication, that
> is, when you send low latency updates FROM the client to the SERVER.
Of course it's exactly the opposite.
> Lightstreamer can choose the best transport among the many available (e.g
> http streaming), passing through any existing proxies and firewalls, so I
> guess this could be a plus in a corporate context.
When CometD considered HTTP streaming, it always had problems with
proxies because of proxy buffering.
What would be interesting is discussing how you solved the problem,
and perhaps contributing a similar solution for CometD.
> Let me give you more details
> 1) Read above. Lightstreamer offers an excellent fallback mechanism as it
> can adapt the transmission to the actual browser, device and connection of
> each single client.
CometD does that too, and since long time before other competitors.
> 3) With Lightstreamer you definitely can have great performance even to "old
> fashioned" browsers. It has been deployed in a number of mission-critical
> projects within the financial industry, and many of them had the same
> concerns. Feel free to ask for more details, see a partial list of customers
> or just check some case studies on the blog.
Same for CometD.
> We also recently issued an apple-to-apple data broadcasting comparison with
> socket.io (messages generated on the server side and sent to over 4 thousand
> clients, ran over two Amazon EC2 Machines)
4k clients ?
You should look at the CometD benchmarks, where 2 years ago we were
able to send via WebSocket to 200k clients:
http://webtide.intalio.com/2011/09/cometd-2-4-0-websocket-benchmarks/.
We're working on the updated versions of this benchmark for CometD 3,
which I think will go well beyond 200k for one server.
> and LS proved to be able to scale
> better in terms of CPU usage, data latency, and bandwidth consumption, with
> some other useful features to improve the overall performance. Have a look
> at here. The same benchmarking kit has been left on GitHub, so you can get
> it and test other scenarios.
Unfortunately, you forgot the links.
I appreciate technical discussions, less almost pure-marketing emails
like yours, where you make claims (sometimes wrong, sometimes not
accurate) and present benchmark results without backing them with
links to the code that runs them.
I am sure you understand.
Thanks.
Developer advice, training, services and support
On Wed, Oct 2, 2013 at 3:22 PM, Valerio Celletti
<valerio....@lightstreamer.com> wrote:
> Hi Anqing,
>
> If you want to add real-time trading features to your web portal (which you
> stated that is well established, so I must assume that a not negligible
> number of concurrent users will use this feature after its release) then you
> should definitely consider Lightstreamer, as I checked your requirements
> accurately and it seems that it can do the trick without a huge effort.
emails can go up to a certain point, which I think you surpassed with
this email in this public mailing list for an open source project
competitor with your closed source product.
The discussion here was about CometD and socket.io, and you moved it
to a LightStreamer advertisement.
> I do agree that plain websockets are not a viable solution right now, as a
> number of browsers still don't support them.
solution for 70% of the market out there.
> Plus, even if this is not your
> case - you are talking about enterprise desktop browsers-, but be aware that
> a number of 3G/LTE operators currently are blocking them.
are easy workarounds.
Which providers you know that block WebSocket traffic ?
> In any case, the
> real advantage of WebSockets arises for bi-directional communication, that
> is, when you send low latency updates FROM the client to the SERVER.
> Lightstreamer can choose the best transport among the many available (e.g
> http streaming), passing through any existing proxies and firewalls, so I
> guess this could be a plus in a corporate context.
proxies because of proxy buffering.
What would be interesting is discussing how you solved the problem,
and perhaps contributing a similar solution for CometD.
> Let me give you more details
> 1) Read above. Lightstreamer offers an excellent fallback mechanism as it
> can adapt the transmission to the actual browser, device and connection of
> each single client.
> 3) With Lightstreamer you definitely can have great performance even to "old
> fashioned" browsers. It has been deployed in a number of mission-critical
> projects within the financial industry, and many of them had the same
> concerns. Feel free to ask for more details, see a partial list of customers
> or just check some case studies on the blog.
> We also recently issued an apple-to-apple data broadcasting comparison with
> socket.io (messages generated on the server side and sent to over 4 thousand
> clients, ran over two Amazon EC2 Machines)
You should look at the CometD benchmarks, where 2 years ago we were
able to send via WebSocket to 200k clients:
http://webtide.intalio.com/2011/09/cometd-2-4-0-websocket-benchmarks/.
We're working on the updated versions of this benchmark for CometD 3,
which I think will go well beyond 200k for one server.
> and LS proved to be able to scale
> better in terms of CPU usage, data latency, and bandwidth consumption, with
> some other useful features to improve the overall performance. Have a look
> at here. The same benchmarking kit has been left on GitHub, so you can get
> it and test other scenarios.
I appreciate technical discussions, less almost pure-marketing emails
like yours, where you make claims (sometimes wrong, sometimes not
accurate) and present benchmark results without backing them with
links to the code that runs them.
I am sure you understand.
Thanks.
Developer advice, training, services and support
Message has been deleted
Valerio Celletti
Oct 2, 2013, 11:14:48 AM10/2/13
to cometd...@googlegroups.com
Dom
Oct 11, 2013, 11:42:24 AM10/11/13
to cometd...@googlegroups.com
Anqing; I realise this is a bump, but I thought it was worth mentioned that we use CometD to send price feeds to our front end, and a low powered server is more than capable of serving over 20k clients with a daily peak of 20k ticks per second (not to each client, just on the price feed in general).
We have users still on IE6, and users using the latest version of chrome and none of them report any issues with connection ability or speed. Because of front end calculations we do not drop any or shape the ticks going to the clients. So CometD under Jetty is definitely viable.
Simon; In the UK most of the mobile network operators block web socket connections over 3G. Our native implementation in iOS of the CometD client code spends most of it's time using long polling; it's annoying but that's life.
Simone Bordet
Oct 11, 2013, 12:25:47 PM10/11/13
to cometd-users
Hi,
On Fri, Oct 11, 2013 at 5:42 PM, Dom <thep...@gmail.com> wrote:
> Anqing; I realise this is a bump, but I thought it was worth mentioned that
> we use CometD to send price feeds to our front end, and a low powered server
> is more than capable of serving over 20k clients with a daily peak of 20k
> ticks per second (not to each client, just on the price feed in general).
>
> We have users still on IE6, and users using the latest version of chrome and
> none of them report any issues with connection ability or speed. Because of
> front end calculations we do not drop any or shape the ticks going to the
> clients. So CometD under Jetty is definitely viable.
Thanks for the feedback !
> Simon; In the UK most of the mobile network operators block web socket
> connections over 3G. Our native implementation in iOS of the CometD client
> code spends most of it's time using long polling; it's annoying but that's
> life.
They block clear-text WebSocket ?
What about WebSocket over TLS ? I am positive it will be hard to block that.
WebSocket over TLS is of course supported out of the box by CometD and browsers.
On Fri, Oct 11, 2013 at 5:42 PM, Dom <thep...@gmail.com> wrote:
> Anqing; I realise this is a bump, but I thought it was worth mentioned that
> we use CometD to send price feeds to our front end, and a low powered server
> is more than capable of serving over 20k clients with a daily peak of 20k
> ticks per second (not to each client, just on the price feed in general).
>
> We have users still on IE6, and users using the latest version of chrome and
> none of them report any issues with connection ability or speed. Because of
> front end calculations we do not drop any or shape the ticks going to the
> clients. So CometD under Jetty is definitely viable.
> Simon; In the UK most of the mobile network operators block web socket
> connections over 3G. Our native implementation in iOS of the CometD client
> code spends most of it's time using long polling; it's annoying but that's
> life.
What about WebSocket over TLS ? I am positive it will be hard to block that.
WebSocket over TLS is of course supported out of the box by CometD and browsers.
Dominic Black
Oct 12, 2013, 9:13:32 AM10/12/13
to cometd...@googlegroups.com, cometd-users
Our mobile app doesn't even try wss. I'll ask the iOS dev to give it a shot.
Dominic
Dominic
--
--
You received this message because you are subscribed to the Google Groups "cometd-users" group.
To post to this group, send email to cometd...@googlegroups.com
To unsubscribe from this group, send email to cometd-users...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/cometd-users
Visit the CometD website at http://www.cometd.org
---
You received this message because you are subscribed to a topic in the Google Groups "cometd-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cometd-users/GXJrNfPCq3A/unsubscribe.
To unsubscribe from this group and all its topics, send an email to cometd-users...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Reply all
Reply to author
Forward
0 new messages