1. We may simply have an issue with our configuration of DWR or Jetty, and we
may be able bump the speed up to a more satisfactory level without major changes
Maybe I misunderstood something but just by looking at the videos it
seemed to me that DWR is using polling instead of comet style? I think
to have seen that Wookie uses polling as standard configuration with an
interval of 5 seconds. This would explain the long timeout between
updates, but can be configured ...
-Bernhard
2. Running an additional two services is a pain, and shouldn't be done unless
it really is strictly necessary. For example, with the code I've developed you
end up running:
- Node.js
- Redis
- Jetty
- Derby
... with relational data stored in Derby and tuples stored in Redis. Its
certainly a more complex deployment than we have at present.
3. Integrating participants is less trivial than state data, and would not
necessarily have any performance benefit
4. The benefits may be entirely due to websockets vs comet, in which case a
websockets implementation in DWR would be the easiest path. However, I haven't
seen a lot of discussion of websockets on the DWR lists.
Alternatively, Jetty has WebSockets support as of V7.0.1. However, I'm not
aware of any implementation for Tomcat.
Note I'm not suggesting we commit the code now, so close to a release, but
perhaps immediately after the release?
With respect to performance issues, maybe we should make it a priority to do
some profiling for the next release?
Agreed, I'd be wary of jumping to conclusions until we've identified where
performance issues occur.
If we do add profiling we could do the node.js in a branch and compare results
before merge. That might help us see where poor Wookie performance is being
masked by improved node.js performance.
Sounds good to me.
Sent from my mobile device.
On 25 Oct 2010, at 09:07, "Scott Wilson (JIRA)"<[email protected]> wrote:
[
https://issues.apache.org/jira/browse/WOOKIE-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12924490#action_12924490
]
Scott Wilson commented on WOOKIE-155:
-------------------------------------
I built the experimental functionality into a "NodeWave" feature that can be
used instead of the existing DWR-based feature and tried it out with some widgets. I'm
not surprised that using Node.js+Redis+WebSockets was very, very fast (duh!) but am a bit
concerned that DWR+Comet is surprisingly slow.
I wonder which part of Wookie might have a performance issue? It could be any
one of Comet/DWR, Jetty, the Wookie server code itself, JPA or Derby.
Experimental setup for shared data using websockets, node.js and redis
----------------------------------------------------------------------
Key: WOOKIE-155
URL: https://issues.apache.org/jira/browse/WOOKIE-155
Project: Wookie
Issue Type: Improvement
Components: Server
Reporter: Scott Wilson
Priority: Minor
Attachments: chat_dwr_vid.swf, chat_node_vid.swf, wavenoderedis.zip
This is an experimental setup that simulates replacing the DWR-based
functionality of Wookie's Wave API implementation with one using Node.js,
WebSockets, and Redis. The key motivation behind this experiment is to see how
much more responsive Wookie shared state widgets can be using a fast Websockets
implementation instead of Comet on a typical Java server stack.
To try it out, you need to install Node.js and the SocketIO websockets
implementation. You also need to run a Redis server. This file contains the
server-side logic.
To run the example:
1. Start your redis server on the default port using:
./redis-server
2. In the folder you unzipped the code into, type:
node server.js
3. In your browser (Safari and Chrome work well) open each of the testx.html files. Test
and Test2 share the same SharedDataKey whereas Test3.html does not. Type in key:value
pairs in the text boxes to send deltas to the wave state, and see them updated in other
"widget instances".
Note the example is incomplete as it only handles state, not viewer or
participants
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
