Measurements

Our own servers and our own scripts: each chart says how it was measured, and the failed attempts are in the tables of the repository.

figures and methods

Our own servers: Hetzner cloud with no GPU for the charts, a dedicated Core i7-7700 with its integrated GPU for the GPU figures. Each chart says how it was measured; all tables and the failed attempts are in docs/MEASUREMENTS.md.

Two questions, two kinds of test

How many users fit in memory: the first chart. Each user logs in and opens Chromium, Calc with 300,000 rows and VS Code, and the applications are left idle; on an 8 GB, 4-vCPU server 8 fit on Debian 13 and 7 on Ubuntu 26.04. How a server behaves under active users: the table with and without a GPU, further down: the users scroll, type and watch video, on a 64 GB machine (21 and 24 users) and, earlier, on a 23 GB server that held 12 before it refused the 13th, at about 1.6 GB a user. Active users on an 8 GB server were not measured: it would hold fewer than the idle 7 to 8, about five if the 23 GB figure scaled, and that is arithmetic, not a measurement.

430 to 600 MB
an idle session with the shell
7 to 8
users with Chromium, Calc and VS Code open (idle) on an 8 GB server
4.5 : 1
compressed swap, zstd
60 s
a frozen client is cut off
4.8 % vs 15 %
CPU of the capture and encoding with 20 active heavy users, GPU or CPU

Where the memory goes

Available memory as heavy users log in, 8 GB server On Debian 13 the available memory falls from 5.4 GB with one user to 1.1 GB with eight; the ninth login is refused. On Ubuntu 26.04 it falls from 5.2 GB to 0.8 GB with seven users; the eighth is refused. A new login is refused when less than about 1.2 GB is available. 0123456123456789 refused below 1.2 GB Debian 13 Ubuntu 26.04 heavy users logged in available memory, GB
Available memory (free) after each user logged in over RDP and opened Chromium, LibreOffice Calc with a 300,000-row sheet and VS Code, one at a time, left idle. 4 vCPU, 7.6 GB.

A slow, lossy link

TCP BBR against CUBIC on a link with 4 % packet lossThroughput rose from about 0.3 Mbit/s with CUBIC to 2 to 4 Mbit/s with BBR, and the data waiting unsent on the server fell from 50 to 120 kB to 1 to 13 kB. carried, Mbit/sCUBIC0.3BBR2 to 4waiting unsent, kBCUBIC50 to 120BBR1 to 13
One distant link with about 4 % packet loss, the connection inside WireGuard, ss -ti before and after switching CUBIC to BBR. One afternoon.

H.264 for screens

H.264 screen-content mode against camera modeFor a full-screen 720p30 test pattern the screen-content mode needed 6.4 Mbit/s and 43 % of a core; the camera mode needed 12.7 Mbit/s and 15 % of a core. bandwidth, Mbit/sscreen6.4camera12.7CPU, % of one corescreen43camera15
A full-screen 720p30 test pattern, software OpenH264 on 2 vCPUs. Screen mode costs a near-constant share of a core, so a mostly still desktop costs more CPU in screen mode than in camera mode.

With and without a GPU

Active users, not idle ones: Chromium and a terminal that scroll and type, Calc on 300,000 rows and VS Code with keystrokes, GIMP for one in four, a looping video for one in four. One at a time on a Core i7-7700 (8 threads, 64 GB, integrated HD 630), each with its own RDP client on another machine. The CPU is of the whole machine.

Active heavy usersCPU, GPU onCPU, GPU offCapture and encoding, GPU on / off
1047 %45 %4.2 % / 8.7 %
1549 %60 %4.6 % / 11.7 %
2050 %69 %4.8 % / 15.4 %
24refused at 22 (memory)94 %– / 21.1 %
  • The GPU flattens the CPU (about 50 % from 15 users on, against 3 to 4 points more for each user without it), but on this machine it did not add users: 21 fit with it, 24 without, because an integrated GPU takes system memory (2.24 GB a user against 1.95 GB). Memory ended both runs.
  • Full-screen WebGL on the HD 630: 60 fps each for two users, 47 for three, 20 for six, 13 for ten; the card is the limit, the CPU stays under 40 %. Without the GPU the page does not animate.
  • When a GPU cannot encode, the session falls back to OpenH264 and keeps working: the worker takes 12 % of the machine instead of 3 %. waydesk-admin status shows it.
  • An NVIDIA RTX 4000 SFF Ada (driver 615 or newer) runs the desktop and a NVENC encoder: 61 fps on the WebGL page, the encoder engine 4 % busy.

Not measured: active users on an 8 GB server, a build or a recalculation, the delay between a click and the screen changing, AMD, a card with its own memory under many users, runs longer than 45 minutes. Raw tables and the scripts: docs/measure-data. Setting it up and reading it: using a GPU.

This page is a file in the repository: corrections are welcome.