The biggest performance win from ReHLDS is the rewritten engine itself — more accurate frame timing and a faster network path than Valve's original. On top of that it exposes a set of sv_rehlds_* cvars that do not exist on stock HLDS. Most of them are correctness or hardening switches rather than raw speed knobs, but several directly affect how the server behaves under load and under attack, which is what "performance" means once real players show up. This guide covers the ones worth setting and, just as important, how to introduce them safely.

This assumes you already run ReHLDS. If not, do the install first — none of these commands exist on the Valve engine, and setting them there is a silent no-op.

1. Confirm you are actually on ReHLDS

version

ReHLDS prints a line starting ReHLDS version: with its version number. Stock HLDS prints only the Protocol version, Exe version and Exe build lines. If there is no ReHLDS version: line, the engine was not replaced and nothing below applies.

2. Timing and tick rate

ReHLDS holds a high sys_ticrate far more reliably than stock HLDS, which is the whole reason people chase it for FPS. Set the target as usual on the launch line:

./hlds_run -game cstrike -pingboost 1 +sys_ticrate 1000 \
  +map de_dust2 +maxplayers 20 +sv_lan 0

Then measure under load with stats as described in the stable-FPS guide. On ReHLDS a 1000 target is realistic where stock HLDS would jitter.

3. Anti-flood cvars protect FPS under attack

A server does not only slow down from too many honest players — it slows down, or dies, when someone floods it with movement or string commands. ReHLDS ships rate limiters for exactly this. Add them to server.cfg:

// limit per-client command flooding (the compiled defaults)
sv_rehlds_stringcmdrate_max_avg 250
sv_rehlds_stringcmdrate_max_burst 500
// limit connections from a single address
sv_rehlds_maxclients_from_single_ip 5

These keep one abusive client from consuming a disproportionate share of the single server thread. 250 and 500 are the defaults compiled into current builds; the ReHLDS developers raised them several times in 2015 and 2016, and going lower again makes it more likely that real players get kicked or IP-banned, see crash or kicks after enabling ReHLDS security cvars. Read your ReHLDS build's own cvar list — exact names and defaults change between releases, and inventing a cvar just gets you a silent no-op.

4. Network and download behaviour

// full 1024-byte download fragments for in-game clients, ignoring their cl_dlmax
sv_rehlds_force_dlmax 1

// do not push the mapcycle to clients
sv_rehlds_send_mapcycle 0
// per-client game clock (reduces lag when one map runs a long time)
sv_rehlds_local_gametime 1

sv_rehlds_force_dlmax 1 sets the fragment size, not a download rate: data the server sends in pieces to a client that is already in the game (other players' sprays, for example) goes out in full 1024-byte fragments instead of the size the client's cl_dlmax asks for. Downloads while a player connects already use that maximum, so the cvar does not fix "stuck at connecting"; for slow map downloads use a proper FastDL setup. sv_rehlds_local_gametime 1 is a correctness fix worth having on.

5. Introduce them one batch at a time

This is the part people skip and regret. Some hardening cvars interact badly with old plugins that build raw network messages by hand. Turn on one small group, restart, and watch the log through a map change and a few connects:

rcon sv_rehlds_local_gametime 1
// restart, play a map, watch the console
rcon sv_rehlds_force_dlmax 1
// restart, watch again

If the server starts crashing right after you enable a batch, you have found the culprit without a bisect. A plugin that dies under a new security cvar usually needs updating, not the cvar disabling forever.

6. What ReHLDS cvars will not do

No sv_rehlds_* cvar turns a saturated core into a fast one. If stats shows the core at 100%, the answer is a faster CPU, fewer or lighter plugins, or a lower sys_ticrate — not another cvar. Likewise, the rate window that players actually experience is governed by sv_maxrate and sv_maxupdaterate, which are engine-agnostic and matter regardless of ReHLDS.

Common errors

• unknown command "sv_rehlds_..." (printed only when sv_echo_unknown_cmd 1 is set) — the cvar name is wrong, or your build does not have it. Verify with version and read the shipped cvar list.
• Server crashes right after enabling a hardening cvar — usually it is not a crash: the flood limits are kicking or banning players (look for Reason: lines in the console), or a cvar such as sv_rehlds_local_gametime changed what clients receive and broke a plugin that builds its own messages. On 3.15.0.896, turning on speedhack punishment (sv_rehlds_movecmdtime_max_warnings 0 or higher) can really crash the server. Enable in small batches to find it, then see crash after enabling ReHLDS security cvars.
• Set a cvar, nothing changed — a misspelled cvar is a silent no-op unless sv_echo_unknown_cmd 1 is set. Copy the exact name from the release notes.
• FPS unchanged after tuning — you were CPU-bound all along. Measure first; the fix is hardware or plugin load, per the 100% CPU guide.

Verification

After each batch, confirm version still shows the ReHLDS version: line, the server reaches a map, and meta list (if Metamod is loaded) still shows every plugin as RUN. Load the server and re-measure FPS with stats to prove the timing held. The goal is a server that is not just fast when empty but stays fast and stable when someone tries to abuse it.