On 25 Oct 2010, at 12:19, Bernhard Hoisl wrote: >> 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
It *should* use Comet as the wave.js file calls:
dwr.engine.setActiveReverseAjax(true);
... which should tell DWR to use Comet rather than polling.
Plus DWR is configured in web.xml with:
<init-param>
<param-name>activeReverseAjaxEnabled</param-name>
<param-value>true</param-value>
</init-param>
More info at: http://directwebremoting.org/dwr/reverse-ajax/configuration.html
However there is clearly something wrong with performance here.
>
>
>>
>> 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.
>>>>
>>
smime.p7s
Description: S/MIME cryptographic signature
