Skip to main content

Rust server tuning

How to improve Rust server performance

Server performance is what stops players losing fights to lag and rubber-banding off cliffs. Most of it comes down to three things: the clock speed of the CPU, the plugins you are running, and about five convars.

  • Rust guides
  • Updated
  • 9 min read
  • CPU clock speed
  • Plugin overhead
  • 5 key convars
KEY CONVARSserver.cfgbatching.colliders "0" # re-enable above 265k entitiesnav_disable "true" # animals and NPCs stop movingserver.saveinterval "600"ai.think 0fps.max 30 # 30 to 100 is the useful range

The short answer

Remove badly optimised plugins first, because they cost more than everything else combined. Then set batching.colliders "0", cap fps.max between 30 and 100, raise server.saveinterval "600", and consider nav_disable "true" and ai.think 0 if you can live without animal movement.

Key points

  • Rust needs clock speed, not core count. Unity's core functions are single threaded.
  • One badly coded plugin can undo every other optimisation on this page.
  • Server FPS is not player FPS. They are different numbers measuring different things.
  • Measure with the Performance Monitor plugin, then remove it. It costs performance too.
  • Every convar here is a trade. Know what you are giving up before you set it.

What actually affects performance

Consistent performance is what reassures your players that they have a safe place to play, where they will not lose a fight to lag or rubber-band off a cliff edge. It is worth being precise about where it comes from, because time spent on the wrong thing is wasted.

Roughly in order of impact:

  1. Plugins. A single poorly written one can dominate every server tick.
  2. CPU clock speed. The ceiling everything else operates under.
  3. Entity count. Late in a wipe cycle, this is what changes underneath you.
  4. Save operations. On a large world, noticeable every time they run.

Hardware: clock speed over core count

You will see dramatically better server performance from providers using faster CPUs clocked upwards of 3GHz. The reason is architectural rather than incidental: Unity core functions are single threaded, so they run on one core and cannot be spread across others. A 32 core CPU at 2.2GHz will run a Rust server worse than an 8 core at 4GHz.

Core count is not irrelevant. Things like NPC and animal AI, and other map-related objects, can be spread across multiple cores, which is why higher population servers genuinely benefit from extra cores. A good host should offer the option of more cores for a bigger server, and should be hosting Rust on high frequency CPUs in the first place.

This is the single most useful thing to check before you buy. If a host advertises core count and RAM but not clock speed, that is usually because the clock speed is not the selling point.

Plugins: the biggest single factor

uMod is a Rust modding addon that lets servers run plugins developed mostly by the community. Server performance will not be impacted by well written, actively maintained plugins.

It will be destroyed by a bad one. Without your awareness, a small piece of code in any of your plugins could severely degrade your server's performance, and there is nothing about a plugin's size or apparent simplicity that tells you which. Even the smallest, lightest looking plugin can cause chaos, as any experienced Rust server owner or plugin developer will confirm.

Avoid running too many plugins. The count itself has a cost, quite apart from the quality of any individual one, and the answer to a problem is more often removing a plugin than adding one.

Optimising the plugins you keep

Some plugins expose performance-tuning settings such as timers and intervals. These are usually off by default or set conservatively. Look in the plugin's configuration file and enable them, because a plugin polling every tick when it could poll every thirty seconds is doing thirty times more work than it needs to.

Measuring before you change anything

Guessing at performance problems wastes time. There are two measurements worth taking.

Server FPS

This is the frame rate the server is operating at. It has no direct influence on your players' frame rates, though high entity counts in one area will affect both. Monitor it over RCON with the FPS command.

The Performance Monitor plugin

The Performance Monitor for uMod reports real-time information on memory usage, plugin hook time and other timings that affect server performance. It will show you which plugin is consuming the most time on a single hook, which turns "the server feels bad" into a name.

Do not leave the Performance Monitor running indefinitely. The monitoring itself consumes resources and will worsen the performance you are trying to measure. Install it, take your readings, act on them, then unload it.

The convars that matter

Each of these is a trade rather than free performance. The gains are real, and so are the things you give up.

batching.colliders "0"

Removes the need for the server to batch entities. This is a large performance gain: with batching enabled, every time someone builds, the server has to unbatch and then rebatch all related entities.

The caveat: if your server goes over 265,000 entities you will need to re-enable it to work around the Unity entity limit. Late in a long wipe cycle on a busy server, that is a real number rather than a theoretical one, so it is worth keeping an eye on.

nav_disable "true"

Disables the NAV mesh on your server. The performance gain is large. The cost is that animals and NPCs stop moving entirely.

Whether that is acceptable depends on your server. On a heavily PvP-focused server where nobody is hunting deer, it is close to free. On a PvE or roleplay server, it removes a meaningful part of the game.

ai.think 0

You may have noticed on large servers that animals do not react or fight back. That is ai.think set to 0. It has a significant positive effect on performance, particularly when player numbers are high and players are frequently close to animals.

server.saveinterval "600"

You may see server-side FPS drops when the server saves on a high entity server. Increasing the duration between saves keeps that to a minimum.

The trade here is risk: a longer interval means more progress lost if the server crashes between saves. 600 seconds is a reasonable balance, but if your server is unstable for other reasons, do not fix the symptom by making the crashes more expensive.

fps.max

Controlling your server's FPS is a good idea generally, to stop the server working harder than it needs to at no benefit to your players. Facepunch have said players would not notice a server limited to 30 frames per second. Setting fps.max to a number between 30 and 100 is strongly advised.

Restarts

Daily restarts can help performance on modded servers. Long-running processes accumulate memory pressure, and plugins that leak slowly are common enough that a scheduled restart is a reasonable insurance policy.

Schedule them at a quiet hour and announce them. global.restart gives players a 300 second warning at 5 second intervals, which is enough time to get somewhere safe. A silent restart mid-raid will lose you more players than the performance gain wins you.

What to do, in order

  1. Measure first

    Check server FPS over RCON and run the Performance Monitor briefly. Without a baseline you cannot tell whether anything you did helped.

  2. Remove the worst plugin

    Whatever the monitor named. This is almost always the single biggest win available, and it is free.

  3. Tune the plugins you keep

    Timers and intervals in their config files, where they exist.

  4. Apply the convars

    Start with batching.colliders "0", fps.max and server.saveinterval, which cost you nothing your players will notice. Consider nav_disable and ai.think only if you can accept static wildlife.

  5. Measure again

    Same tools, same conditions, ideally at a similar player count. Then unload the monitor.

  6. Look at the hardware

    If you have done all of the above and performance is still poor, the ceiling is the CPU, and no amount of configuration gets past it.

If you are at that last step, our guide on what to look for when buying a Rust server covers what to ask a host before you move.

More guides for people running their own Rust server.

Rust

uMod and Oxide basic usage

Loading, reloading and permissioning plugins without breaking the server.

Read the guide Rust

Rust server admin commands

The full console reference, including server.save and the FPS command.

Read the guide Rust

What to look for when buying a Rust server

Hardware, DDoS protection, support and location, and how to weigh them.

Read the guide
Quick answers

Common questions

In order of impact: a badly written plugin consuming hook time, a CPU with a low clock speed, a very high entity count, and save operations on a large world. Plugins are the usual culprit because a single poorly coded one can dominate every tick regardless of how good the hardware is.

Clock speed matters more than core count. Unity core functions are single threaded, so a CPU clocked above 3GHz makes a dramatic difference. Additional cores do help with AI and map-related work, which is why higher population servers benefit from having them, but a many-core CPU with a low clock is the wrong shape for Rust.

Somewhere between 30 and 100. Facepunch have said that players will not notice a server limited to 30 frames per second, and letting the server run harder than it needs to gains your players nothing. Capping it frees capacity for the work that does affect gameplay.

Yes, significantly, but at a cost. Setting nav_disable "true" disables the NAV mesh, which gives a large performance gain and stops animals and NPCs moving at all. Whether that trade is acceptable depends entirely on what kind of server you run.

It removes the need for the server to batch entities. That is a large performance gain, because with batching enabled the server has to unbatch and rebatch all related entities every time someone builds. The caveat is real: above 265,000 entities you need to re-enable it to work around the Unity entity limit.

Use the Performance Monitor plugin for uMod, which reports memory usage and plugin hook times and will show you which plugin is consuming the most time on a single hook. Do not leave it running permanently, because the monitoring itself costs performance.

Rust hosting on high clock speed hardware

Rust is single threaded where it counts, which is why we run it on high frequency CPUs in our own UK data centre rather than on whatever has the most cores.

Rust server hosting
  • UK data centre
  • High frequency CPUs
  • Support by ticket and Discord