#2859 closed defect (invalid)
Xpra proxy performance issue
Reported by: | Mark Knittel | Owned by: | Mark Knittel |
---|---|---|---|
Priority: | major | Milestone: | 4.1 |
Component: | server | Version: | 4.0.x |
Keywords: | proxy performance | Cc: |
Description (last modified by )
When launching an application on a Ubuntu server from a client browser using an XPRA proxy session the application always takes 30 - 40 seconds to load. The same application launches in less that one second from a local desktop user session.
The Ubuntu server is 18.04.
Xpra is version 4.0.2-r26625.
I'm submitting logs for 2 application launch sessions:
Application 1:
- File: 10000.log
- Command to start proxy session:
xpra proxy --bind-tcp=0.0.0.0:10000 --tcp-auth=allow --debug=all
- URL to launch application:
http://192.168.2.13:10000/?username=ares&password=ares&exit_with_children=1&exit_with_client=1&start=kgeography&action=start-desktop
Application 2:
- File: 10001.log
- Command to start proxy session:
xpra proxy --bind-tcp=0.0.0.0:10001 --tcp-auth=allow --debug=all
- URL to launch application:
http://192.168.2.13:10001/?username=ares&password=ares&exit_with_children=1&exit_with_client=1&start=atomix&action=start-desktop
Attachments (2)
Change History (8)
Changed 7 months ago by
comment:1 Changed 7 months ago by
Description: | modified (diff) |
---|---|
Owner: | changed from Antoine Martin to Mark Knittel |
Key events from your first log:
07:28:24,912 xpra proxy version 4.0.2-r26625 64-bit 07:28:24,913 uid=1000 (ares), gid=1000 (ares) 07:28:24,913 running with pid 15820 on Linux Ubuntu 18.04 bionic .. 07:31:57,914 io_in_cb(<socket.socket fd=3, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('0.0.0.0', 10000)>, <flags G_IO_IN of type GLib.IOCondition>) .. 07:32:02,648 start_new_session('ares', '..', 1000, 1000, {b'mode': b'start-desktop', b'exit-with-children': 1, b'start-child': [b'kgeography'], b'exit-with-client': 1}, []) .. 07:32:02,683 start_server_subprocess: command='/usr/bin/xpra', 'start', '--attach=no', '--exit-with-children=yes', '--exit-with-client=yes', '--start-child=kgeography', '--env=XPRA_PROXY_START_UUID=3cf8701b96c24e8eb20e4988d6477ab7', '--daemon=yes', '--systemd-run=no', '--displayfd=10' .. 07:32:02,700 read_displayfd(9, 20, None) 07:32:11,999 displayfd=:1 .. 07:32:16,833 identify_new_socket new_sockets=('/run/user/1000/xpra/ares-desktop-1',) 07:32:18,673 starting proxy instance pid 15820 from pid=15820 .. 07:32:18,697 received proxy server message: socket-handover-complete .. 07:32:19,854 sending to client: hello (queue size=0)
So, unless I am missing something, it isn't the proxy that is introducing the delays.
The time between the browser connecting to the proxy (io_in_cb
) and starting the session is only 5 seconds, and this time is spent mostly in the browser loading the HTML5 client. You may be able to speed this up by serving the HTML5 client using a proper web server rather than relying on the proxy's builtin web server.
Then the actual xpra server instance takes 14 seconds to start (from start_server_subprocess
to identify_new_socket
), most of which is the X11 vfb starting up (between read_displayfd
and displayfd=
).
The proxy then takes just 2 seconds to hand over the client connection to this new server instance.
If you want to make your server startup faster (14 seconds is a bit long), see #2341. There are options you can turn off to speed things up, most importantly: switch to Xvfb
instead of Xdummy
if you don't mind minor DPI issues.
If that's still too slow for you, please open a new ticket, one that does not involve the proxy, since the proxy is not the problem here.
I will probably close this ticket as invalid
.
comment:2 Changed 7 months ago by
Antoine: thanks for the feedback. I'm happy to reopen this as a non-proxy issue, but I'm not 100% sure that's the case. Let me add a little more data:
- I went back to check on starting the same apps as a non-proxy. When I did that using --tcp-auth=allow enabled I get a message telling me that VFB failed to load, so exiting. (Note: the latest version of xvfb is installed.)
- When I start the same apps as a non-proxy without --tcp-auth=allow included, the apps start in less than 1 second (which is great).
- I have tried to find some app commands that would allow the proxy to work in the same manner as above (without using tcp-auth), but have not found anything that works. Is there something else I can try? Note - this is an offline education server, so I am NOT concerned about security or user validation.
Thanks.
comment:3 Changed 7 months ago by
When I did that using
--tcp-auth=allow
enabled I get a message telling me that VFB failed to load, so exiting.
Please always include the exact command lines and messages. If the vfb fails to load, then you should not be able to start new servers.
without
--tcp-auth=allow
included, the apps start in less than 1 second
That's impossible. Maybe you mean "attach" instead of "start"?
It's difficult for me to diagnose without the command lines or output.
But it sounds like you are talking about the time it takes to attach
, not start
.
In the case of the proxy, for the log you have given, the proxy starts your new server instance - which takes time.
Whereas when you connect directly to a server, obviously it has to be running already.
So, connecting via the proxy is slower because:
- the proxy starts the real server (
start_new_session
... in the log) - though it doesn't have to be this way, you can start a session in advance and the proxy should then use it (if there is only one, if there are more then your connection string will need to tell the proxy which one you want to connect to) - the proxy links up the client with the real server (socket handover, etc) - not that long
comment:4 Changed 6 months ago by
Antoine: I agree that this is not a proxy issue. I tested the application load time with a proxy and non-proxy attach (via browser) - it is very close to the same. So, it makes sense to close it. However, I would like some advice on what I can do to speed up the session creation process. You mentioned some possibilities in your original note, including:
Use a real webserver, instead of the proxy built-in server. How do I set that up? I have Apache installed, or can switch to Nginx if needed.
Use XVFB instead if XDummy. I have XVFB installed. How do I call XVFB specifically rather than XDummy?
Is it possible to set the proxy to pre-start a small number of desktop server sessions and keep it at that minimum level if they are used or closed?
Any other ideas?
This server is being used by students to access education apps. It's impossible to keep a student's attention with a 30-40 second session start time. Thanks for your help.
Thanks, Mark K
comment:5 Changed 6 months ago by
Resolution: | → invalid |
---|---|
Status: | new → closed |
Use a real webserver, instead of the proxy built-in server.
How do I set that up? I have Apache installed, or can switch to Nginx if needed.
That's not going to save you much, but worth a try.
Just use your webserver to serve up /usr/share/xpra/www
.
How do I call XVFB specifically rather than XDummy?
See /etc/xpra/conf.d/55_server_x11.conf
Is it possible to set the proxy to pre-start a small number of desktop server sessions and keep it at that minimum level if they are used or closed?
Not at present.
Any other ideas?
Disable every feature you're not using.
See #2341.
comment:6 Changed 5 weeks ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2859
Log files