I have very poor performances with html5 client. Not sure it's a regression from 2.0 as I didn't play with XPRA since a while.
My Xapp is remote, connecting to X11 through TCP. My html5 clients connect through xpra proxy. Maybe something doesn't help for performance in this config ?
Looking at the code, I realized h264 and others codecs were commented. Thus I have modified the code as the following:
[root@www www]# diff /usr/share/xpra/www/js/Client.js /usr/share/xpra/www/js/Client.js.bak 55,56c55,56 < this.enabled_encodings = ["jpeg", "png", "rgb", "rgb32", "h264", "vp8+webm", "h264+mp4", "mpeg4+mp4"]; < this.supported_encodings = ["jpeg", "png", "rgb", "rgb32", "h264", "vp8+webm", "h264+mp4", "mpeg4+mp4"]; --- > this.enabled_encodings = []; > this.supported_encodings = ["jpeg", "png", "rgb", "rgb32"]; //"h264", "vp8+webm", "h264+mp4", "mpeg4+mp4"]; [root@www www]# diff /usr/share/xpra/www/connect.html /usr/share/xpra/www/connect.html.bak 96,99d95 < <option value="h264">h264</option> < <option value="vp8+webm">vp8+webm</option> < <option value="h264+mp4">h264+mp4</option> < <option value="mpeg4+mp4">mpeg4+mp4</option>
Whatever value is selected in 'encoding' fields, the logs report:
xappdisp_eric | 2017-07-28 13:25:15,011 HTML5 Posix Firefox client version 2.1 xappdisp_eric | 2017-07-28 13:25:15,012 as 'eric' xappdisp_eric | 2017-07-28 13:25:15,012 via Linux 4.11.10-100.fc24.x86_64 proxy version 2.1 on 'xpra-proxy' xappdisp_eric | 2017-07-28 13:25:15,013 automatic picture encoding enabled xappdisp_eric | 2017-07-28 13:25:15,013 also available: xappdisp_eric | 2017-07-28 13:25:15,013 jpeg, png, rgb32, h264, vp8+webm, h264+mp4, mpeg4+mp4
The version used is 2.1-2.r16525.el7_3.
1/ The server should say in the logs which encoding is selected in automatic
2/ The server shouldn't keep automatic encoding selection when encoding field is filled in connect.html
Thanks.
Eric.
This is a follow up ticket from this question on the mailing list: Stuck with automatic picture encoding while trying to connect with HTML5.
My Xapp is remote, connecting to X11 through TCP
That's usually a performance issue right there. What is this Xapp? Can we test it? Or is there another app that we can use for replicating the problem?
My html5 clients connect through xpra proxy. Maybe something doesn't help for performance in this config ?
Have you tried connecting directly? Does the python client have the same performance problems or is it just the HTML5 client?
1/ The server should say in the logs which encoding is selected in automatic
That's impossible: in automatic mode, the encoding is dynamic and every screen update may be sent using a different encoding. The engine will use whichever one is more appropriate for the size of the screen update, the number of updates being processed, the bandwidth conditions, etc..
xpra info can give you statistics on how many pixels / regions have used a specific encoding.
2/ The server shouldn't keep automatic encoding selection when encoding field is filled in connect.html
We currently don't allow the user to specify the encoding because they're unlikely to find a single option that is going to be better than "auto".
My Xapp is remote, connecting to X11 through TCP
That's usually a performance issue right there. What is this Xapp? Can we test it? Or is there another app that we can use for replicating the problem?
xterm or libreoffice.
My html5 clients connect through xpra proxy. Maybe something doesn't help for performance in this config ?
Have you tried connecting directly? Does the python client have the same performance problems or is it just the HTML5 client?
I'll organise some tests next week and keep you updated through this ticket.
1/ The server should say in the logs which encoding is selected in automatic
That's impossible: in automatic mode, the encoding is dynamic and every screen update may be sent using a different encoding. The engine will use whichever one is more appropriate for the size of the screen update, the number of updates being processed, the bandwidth conditions, etc..
xpra infocan give you statistics on how many pixels / regions have used a specific encoding.
Whaou ! I am impressed !
2/ The server shouldn't keep automatic encoding selection when encoding field is filled in connect.html
We currently don't allow the user to specify the encoding because they're unlikely to find a single option that is going to be better than "auto".
Thus, why the user is able to select the encoding in connect.html ?
I have found where the performance issue is coming from.
Due to my specific environment (I don't manage all the chain...). I have an http server in front which proxies to xpra-proxy. As it's badly perceived to share a port for two protocols (http for xpra-html5 and xpra), we have decided to implement the following:
---------------
|-----> | xpra-server |
| ---------------
-------------------------- -------------- -------------- | ---------------
| http (with xpra-html5) | ------> | websockify | ------> | xpra-proxy | -------> | xpra-server |
-------------------------- -------------- -------------- | ---------------
| ---------------
|-----> | xpra-server |
---------------
Unfortunately, this provides poor performance from html5 client, while connecting with the standard client directly on the xpra-proxy runs very smoothly.
The work around is to launch xpra-proxy with --bind-tcp=0.0.0.0:14500 and with xpra-htlm5 installed (he will launch the http server as with --html=on) and remove the websockify hop:
---------------
|-----> | xpra-server |
| ---------------
--------- ------------------------------- | ---------------
| http | ------> | xpra-proxy (with xpra-html5)|-------> | xpra-server |
--------- ------------------------------- | ---------------
| ---------------
|-----> | xpra-server |
---------------
But again, serving http and xpra protocols with the same port is not well perceived (while I fully understand it's straight forward for users).
Any idea why websockify provides such poor performance in this situation ?
thanks and best regards,
Eric.
Unfortunately, this provides poor performance from html5 client, while connecting with the standard client directly on the xpra-proxy runs very smoothly.
That's why the websockify handler was moved in-process: #1136
As it's badly perceived to share a port for two protocols...
Hmm. Says who? Multiplexing is pretty common.
Any idea why websockify provides such poor performance in this situation ?
Yes, an extra process, extra socket connections, extra latency, extra buffering, etc.. see #1136 for details.
I am closing this ticket as invalid because xpra is working as expected.
FYI: in 2.2, you can use bind-ws to only serve http / ws traffic on a specific port. Add ssl=on to support https / wss upgrades.
You would need to use bind-tcp with html=off to have another socket serving xpra's protocol only (html=off prevents http / ws socket upgrades).
FWIW: I don't see much point in doing that, but it is possible in 2.2, see ticket:1504#comment:2 for details.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1604