xpra icon
Bug tracker and wiki

Opened 6 weeks ago

Closed 5 weeks ago

#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 Antoine Martin)

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)

1000.log (934.5 KB) - added by Mark Knittel 6 weeks ago.
Log files
1001.log (442.8 KB) - added by Mark Knittel 6 weeks ago.
Log files

Download all attachments as: .zip

Change History (7)

Changed 6 weeks ago by Mark Knittel

Attachment: 1000.log added

Log files

Changed 6 weeks ago by Mark Knittel

Attachment: 1001.log added

Log files

comment:1 Changed 6 weeks ago by Antoine Martin

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.

Last edited 6 weeks ago by Antoine Martin (previous) (diff)

comment:2 Changed 5 weeks ago by Mark Knittel

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 5 weeks ago by Antoine Martin

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 5 weeks ago by Mark Knittel

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 5 weeks ago by Antoine Martin

Resolution: invalid
Status: newclosed

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.

Note: See TracTickets for help on using tickets.