Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Xpra proxy performance issue #2859

Closed
totaam opened this issue Aug 10, 2020 · 7 comments
Closed

Xpra proxy performance issue #2859

totaam opened this issue Aug 10, 2020 · 7 comments
Labels

Comments

@totaam
Copy link
Collaborator

totaam commented Aug 10, 2020

Issue migrated from trac ticket # 2859

component: server | priority: major | resolution: invalid | keywords: proxy performance

2020-08-10 06:35:09: markknit created the issue


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-26625.

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
@totaam
Copy link
Collaborator Author

totaam commented Aug 10, 2020

2020-08-10 06:38:12: markknit uploaded file 1000.log (934.5 KiB)

Log files

@totaam
Copy link
Collaborator Author

totaam commented Aug 10, 2020

2020-08-10 06:38:48: markknit uploaded file 1001.log (442.8 KiB)

Log files

@totaam
Copy link
Collaborator Author

totaam commented Aug 10, 2020

Key events from your first log:

07:28:24,912 xpra proxy version 4.0.2-26625 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.

@totaam
Copy link
Collaborator Author

totaam commented Aug 12, 2020

2020-08-12 19:14:56: markknit commented


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.

@totaam
Copy link
Collaborator Author

totaam commented Aug 13, 2020

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

@totaam
Copy link
Collaborator Author

totaam commented Aug 17, 2020

2020-08-17 05:35:14: markknit commented


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

@totaam
Copy link
Collaborator Author

totaam commented Aug 17, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant