How to improve UI responsivness in conference style app

G

Gabriel T

Member
Hello
i'm uysing wcs mainly for my conference app, based on most features from your conference demo. However, while im using the same "mecanism" i was using for the same app when i was still using wowza, the UI is very slow and unresponsive, particularly for everything related to start publishing/play published streams. there is easlily 5 or more seconds delay between the moment a user click to start talking and the moment connected user actually start to see and ear the stream. which make the whole experience pretty painfull, specially in a conference where you will want to allow differents people to talk (not specially at the same time), alternate between speakers etc...is there any way to improve this "time of response". i though about some workaround but which dont seems very optimised (for example each user are actually constantly streaming, and when an admin decide to add speaker, the system dont have to create the publishing the stream then start playing, but it seems pretty heavy workaround and process...). what i cant really understand, and how there can be such difference between the same mode of functionning between flash rtmp and webrtc....
any adivice welcome
thanks
 
Max

Max

Administrator
Staff member
Good day.
Please clarify do you use Flash-based conference (Flash Video Chat example) or WebRTC (Conference example)? Note that Flash support in browsers supposed to be dropped this year.
Also note that WCS RoomAPI is just a wrapper on WebRTC stream publishing and playback functions with text messaging addition. Please check what stream resolution do you publish, and how much participants can join to the conference simultaneously. On every client, you have one stream published and as many streams played as conference participants, so clients channel bandwidth may be not enough. You can check clients channel quality using the method described here.
Please also check if your server has enough Java heap memory allocated. It is recommenede to allocate 1/2 of servers' physical memory. For example, if server RAM is 32 Gb, then it is recommended to allocate 16 Gb with the following settings in wcs-core.properties file:
Code: 
-Xmx16g
-Xms16g
 
G

Gabriel T

Member
im using webrtc example. iwas comparing performance of the previous version of the same app, which was relying on rtmp with wowza. im publishing in 320*240, with max bandwith set to 1000 as specified in the tuning instructions. i have 64gb of ram so my wcs-core look like -Xmx32g -Xms32g. not every client is publishing, but the process of starting publishing then playback is very slow (and not related to internet line speed, the same 5/6 latency occurs even to people on optic fiber with very good connections.
 
G

Gabriel T

Member
by the way there is the following error, not sure when its triggered yet:
08:05:23,627 WARN RestClient - API-ASYNC-pool-12-thread-10 POST request resulted in 500 (Internal Server Error)
08:05:23,627 WARN ManagerApiConnection - API-ASYNC-pool-12-thread-10 Failed to get object from REST with exception:Internal Server Error
08:05:23,629 WARN RestApiRouter - HTTP-pool-2-thread-50 Invalid UTF-8 middle byte 0x20
at [Source: org.jboss.netty.buffer.ChannelBufferInputStream@3ffc7dff; line: 1, column: 374]
org.codehaus.jackson.JsonParseException: Invalid UTF-8 middle byte 0x20
at [Source: org.jboss.netty.buffer.ChannelBufferInputStream@3ffc7dff; line: 1, column: 374]
at org.codehaus.jackson.JsonParser._constructError(JsonParser.java:1433)
at org.codehaus.jackson.impl.JsonParserMinimalBase._reportError(JsonParserMinimalBase.java:521)
at org.codehaus.jackson.impl.Utf8StreamParser._reportInvalidOther(Utf8StreamParser.java:2831)
at org.codehaus.jackson.impl.Utf8StreamParser._reportInvalidOther(Utf8StreamParser.java:2838)
at org.codehaus.jackson.impl.Utf8StreamParser._decodeUtf8_3fast(Utf8StreamParser.java:2660)
at org.codehaus.jackson.impl.Utf8StreamParser._finishString2(Utf8StreamParser.java:1956)
at org.codehaus.jackson.impl.Utf8StreamParser._finishString(Utf8StreamParser.java:1905)
at org.codehaus.jackson.impl.Utf8StreamParser.getText(Utf8StreamParser.java:276)
at org.codehaus.jackson.map.deser.std.UntypedObjectDeserializer.deserialize(UntypedObjectDeserializer.java:59)
at org.codehaus.jackson.map.deser.std.UntypedObjectDeserializer.mapObject(UntypedObjectDeserializer.java:218)
at org.codehaus.jackson.map.deser.std.UntypedObjectDeserializer.deserialize(UntypedObjectDeserializer.java:47)
at org.codehaus.jackson.map.deser.std.UntypedObjectDeserializer.mapObject(UntypedObjectDeserializer.java:204)
at org.codehaus.jackson.map.deser.std.UntypedObjectDeserializer.deserialize(UntypedObjectDeserializer.java:47)
at org.codehaus.jackson.map.deser.std.MapDeserializer._readAndBind(MapDeserializer.java:319)
at org.codehaus.jackson.map.deser.std.MapDeserializer.deserialize(MapDeserializer.java:249)
at org.codehaus.jackson.map.deser.std.MapDeserializer.deserialize(MapDeserializer.java:33)
at org.codehaus.jackson.map.ObjectMapper._readMapAndClose(ObjectMapper.java:2732)
at org.codehaus.jackson.map.ObjectMapper.readValue(ObjectMapper.java:1909)
at com.flashphoner.rest.server.RestApiRouter.processRequest(Unknown Source)
at com.flashphoner.server.http.handlers.RestApiRequestHandler.process(Unknown Source)
at com.flashphoner.server.http.F.messageReceived(Unknown Source)
at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(Unknown Source)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(Unknown Source)
at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(Unknown Source)
at org.jboss.netty.handler.codec.http.HttpChunkAggregator.messageReceived(Unknown Source)
at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(Unknown Source)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(Unknown Source)
at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(Unknown Source)
at org.jboss.netty.channel.Channels.fireMessageReceived(Unknown Source)
at org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(Unknown Source)
at org.jboss.netty.handler.codec.replay.ReplayingDecoder.callDecode(Unknown Source)
at org.jboss.netty.handler.codec.replay.ReplayingDecoder.messageReceived(Unknown Source)
at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(Unknown Source)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(Unknown Source)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(Unknown Source)
at org.jboss.netty.channel.Channels.fireMessageReceived(Unknown Source)
at org.jboss.netty.channel.Channels.fireMessageReceived(Unknown Source)
at org.jboss.netty.channel.socket.nio.NioWorker.read(Unknown Source)
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.processSelectedKeys(Unknown Source)
at org.jboss.netty.channel.socket.nio.DeadlockAwareNioWorker.run(Unknown Source)
at org.jboss.netty.util.ThreadRenamingRunnable.run(Unknown Source)
at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
 
Max

Max

Administrator
Staff member
Please check if WebRTC stream publishing and playback is slow too using Two Way Streaming example. If yes, please collect report as described here, add WCS version you use and send it to support@flashphoner.com, we will check.
If Two Way Streaming works normally, collect report for Conference example out of the box.
Also, please clarify how do you test: testing call flow, what actions you perform, what results do you get for every step. Please provide screenshots if possible.
 
Last edited:
G

Gabriel T

Member
will check. by the way which build is latest version. here is what i had this morning:
service webcallserver update
>>> You have latest version: 5.2.183
 
You must log in or register to reply here.
Top