perf(cloud): keep one standby display running per desktop VM

Merged
AU
10d ago
+676-275

Every extra display had to be started while the user waited. VMs boot with only display 1, so each New Display paid the guest's Xvnc, desktop session and websockify startup (about 0.7s) on top of the Cloud exec round trip.

The guest helper now keeps one standby display running outside the catalog. Create hands it over and starts the next one in the background. Measured on a live VM, guest-side creation went from about 0.73s to 0.11s (two consecutive creates, each handing over the warm display while the next started).

  • The standby is invisible to list, does not count against the 16-display capacity, and can use the last free slot, becoming that display when requested.
  • A retried create with the same request ID still returns its recorded display and leaves the standby alone.
  • A restarted helper adopts the running standby instead of leaking it and starting another.
  • Opening a machine's Displays tab, or restoring it already selected, runs guest discovery once, so the standby is warm before the first click. Opening Displays previously ran only port discovery.

Cost: one idle display per desktop VM, about 115 MB RSS measured (Xvnc 35 MB, openbox 20 MB, tint2 18 MB, websockify 38 MB, vncconfig 5 MB) on an 8 GB machine.

Stacked on https://github.com/manaflow-ai/cmux/pull/17236.

Verification: python3 -m unittest tests.test_cloud_display_catalog 24/24; the four new tests fail against the previous helper. swift test --filter CloudGuestDisplayScriptTests passes; scoped checks 16/16. Live: after a list, Xvnc :9 ran outside the catalog; two creates returned display:9 and display:10 in 0.11 s each and :10, :11 started as the next standby.

Not covered: the Cloud exec round trip itself (1.3 to 2.9 s) is unchanged.

Changelog

Changed: New Cloud displays open faster; a standby display is kept ready on each desktop machine.

unregistered

🤖 Generated with Claude Code


View with [code]smith Autofix with [code]smith
Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.


Summary by cubic

Keeps one standby display running per desktop VM so New Cloud displays open faster, and stops Xvnc black-listing every viewer of additional displays.

Each New Display previously started Xvnc, the desktop session, and websockify on the guest while the user waited (~0.7 s); create now hands over the warm display in ~0.11 s and starts the next standby in the background. Helper requests also run in a plain shell instead of a login shell, cutting ~0.7 s per call.

  • The standby is hidden from list, doesn't count toward the 16-display capacity, and becomes the requested display on create.
  • Create takes the standby under one lock and reserves launching numbers, so concurrent requests can't misassign them, and a display can never also become the standby.
  • A failed standby is retired and replaced rather than handed over or retried; a retried create returns its recorded display and leaves the standby alone.
  • A restarted helper adopts the running standby instead of leaking it.
  • Opening a machine's Displays tab, or restoring it already selected, runs guest discovery once; failures retry up to three times per shown machine, a sleeping machine redisovers when it wakes, and a completion from a tab that closed and reopened is ignored.
  • Additional displays start with -UseBlacklist=0, and the helper's health check completes the handshake instead of hanging up, so viewers are no longer locked out after repeated "Too many security failures".
  • Tests align with merged sidebar behavior: a connecting machine keeps only the Resources tab, and every visible machine row requests a cached port scan once.

Cost: one idle display per desktop VM, about 115 MB RSS measured on an 8 GB machine. The Cloud exec round trip is unchanged.

Summary by CodeRabbit

  • New Features

    • Opening a machine’s Displays tab starts display discovery, including for restored selections. Failed discoveries retry up to three times.
    • Display listings can prepare a standby display for a later request.
  • Improvements

    • Display creation can reuse a ready standby, helping displays become available sooner.
    • Running displays can be reused after a service restart; unavailable standbys are retired.
  • Bug Fixes

    • Port discovery now runs for every visible machine row, including rows whose Ports tab is closed.