Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [rap-dev] RAP & CometD for real time web (Ralf Sternberg)

hi Ralf,
I'd like to stress this point:

> I don't know much about RAP, but the kind of communication seems very
> much client -> server -> client oriented.
> CometD supports this case but also others (client -> server ->
> broadcast to many clients), and of course also server -> client.

server-->client 

This is the key for financial applications, ticking market data is what all City types want.
And CometD does that very well, especially through WebSockets.


Michele :)


On 22 May 2013 14:27, Simone Bordet <simone.bordet@xxxxxxxxx> wrote:
Ralf,

On Tue, May 21, 2013 at 10:47 PM, Ralf Sternberg
<rsternberg@xxxxxxxxxxxxxxxxx> wrote:
> Hi Michele, Simone,
>
> could you explain how CometD could improve the performance in RAP?

With CometD we have experienced that a big part of the overhead is the
HTTP protocol itself.
Long polling techniques scale up to a certain point.
Look at the benchmark results we obtained:
http://webtide.intalio.com/2011/09/cometd-2-4-0-websocket-benchmarks/
The only difference was using WebSocket instead of HTTP.

> What are the preconditions for employing CometD? For example, can
> CometD work with an existing servlet, or would it require that we use
> a servlet that comes with CometD?

You will have to deploy the CometD servlet instead of your current RAP
servlet that manages the RAP Protocol.

I think the change could be quite simple for you: you can keep your
RAP Protocol as it is, only it will be carried by CometD's Bayeux
protocol.
Now, it is true that wrapping RAP messages inside Bayeux messages is
an overhead, but you get WebSocket for free :)
Our experience however, was that JSON parsing was never an bottleneck,
so parsing a couple more fields should be irrelevant.

All the rest of the RAP message processing could be the same.
I am imagining that now you have something like:

JS (client) -- RAPMessage --> RAPServlet --> RAPService

With CometD you will have:

JS (client) -- BayeuxMessage(RAPMessage) --> CometDServlet --> RAPService

I never tried to expose the CometD servlet via OSGi, but I know people
have done that, so it's not a problem.

I don't know much about RAP, but the kind of communication seems very
much client -> server -> client oriented.
CometD supports this case but also others (client -> server ->
broadcast to many clients), and of course also server -> client.

CometD offers you APIs for authentication & authorization,
disconnection detection, message batching, page reload, JSON library
pluggability, Spring integration, multiple sessions handling (two tabs
with same application), lazy messages (non-urgent messages delivered
on first occasion), server-to-client message acknowledgement,
automatic disconnection of inactive clients, a scalability clustering
solution to scale on multiple nodes called Oort, and much more, with
rich documentation and tutorials at http://docs.cometd.org.

Note that CometD is a project based on Jetty, which also is under the
Eclipse umbrella (http://eclipse.org/jetty).

Let me know if you have more questions (not subscribed to rap-dev).

Thanks !

--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz


Back to the top