Suspend screen rendering for inactive sessions to reduce server CPU usage and network traffic#425
Suspend screen rendering for inactive sessions to reduce server CPU usage and network traffic#425tsz8899 wants to merge 1 commit into
Conversation
Signed-off-by: tsz8899 <tsz8899@outlook.com>
a504617 to
0ef4ffa
Compare
|
The feature is controlled by environment variables and does not rely on adding new [SessionVariables]
XRDP_SCREEN_SLEEP_TIME=15
XRDP_SCREEN_SLEEP_MODE=blackWhere:
The behavior of each mode is as follows:
XRDP_SCREEN_SLEEP_MODE=refresh:5This means that after entering sleep, the latest screen content will be refreshed automatically every 5 minutes. A complete example is as follows: [SessionVariables]
XRDP_SCREEN_SLEEP_TIME=15
XRDP_SCREEN_SLEEP_MODE=refresh:5This means:
If you want the screen to turn black directly after sleep, you can set: [SessionVariables]
XRDP_SCREEN_SLEEP_TIME=15
XRDP_SCREEN_SLEEP_MODE=blackIf you want the lightest-weight mode, you can use: [SessionVariables]
XRDP_SCREEN_SLEEP_TIME=5
XRDP_SCREEN_SLEEP_MODE=last
|
|
The feature has been running in the production environment for three weeks, and users are using it normally. With a 5-minute sleep configuration, a single server can trigger sleep more than 400 times per day, reducing CPU and network usage time by over 7,000 minutes. |
|
Thanks for the confirmation on your production environment. It is very helpful. We've been focused on vulnerability issues, so it will take some time before we can look at this. Hold on. |
Summary
This change adds a screen-sleep mechanism for idle xorgxrdp sessions.
When a session stays idle for a configured amount of time, xorgxrdp stops sending display updates. Once user activity is detected again, display updates resume and a refresh is forced.
Why
In long-lived remote desktop sessions, the server can continue spending CPU time and network bandwidth on screen updates even when the user is idle.
This feature can save a significant amount of server CPU usage and network traffic in long-connection scenarios.
The effect is especially noticeable in these cases:
Behavior
Notes
A companion xrdp PR adds the sesman configuration and passes the configured timeout to xorgxrdp.
xrdp neutrinolabs/xrdp#3775
Is this optimization plan feasible?