Optimiser les UPS d’un serveur Factorio : diagnostic et solutions (2.0 / Space Age)
Tout le monde a connu ce moment : l’usine grossit, la troisième planète est colonisée, et soudain le jeu ralentit pour tout le monde. Les tapis avancent au ralenti, l’horloge du jeu dérive, les trains semblent rouler dans la mélasse. Ce n’est pas un problème de connexion : c’est l’UPS qui s’effondre.
Ce guide suit la méthode du tutoriel officiel de diagnostic des performances du wiki Factorio, adaptée à un serveur dédié. L’idée est simple : mesurer d’abord, optimiser ensuite. Remplacer des tapis au hasard en espérant gagner des UPS fait perdre des heures pour rien.
⚡ CPU haute fréquence
Serveur Factorio sur Ryzen 9 5950X
Notre offre hébergeur Factorio : Starter 6,90 €/mois (4 Go RAM) ou Pro 11,90 €/mois (8 Go RAM) pour les méga-usines. Anti-DDoS 5 Tbps, SSD NVMe, support FR 24/7.
UPS ou FPS : identifier le vrai problème
| Mesure | Ce qu’elle représente | Qui la calcule |
|---|---|---|
| FPS (images par seconde) | Le rendu graphique sur votre écran | Votre carte graphique |
| UPS (mises à jour par seconde) | La simulation du monde : machines, tapis, trains, biters | Le CPU du serveur et de chaque client |
Factorio vise 60 UPS, soit 16,667 ms pour calculer chaque tick. Si un tick prend plus longtemps, le jeu entier ralentit. Et comme les FPS ne peuvent pas dépasser les UPS, une chute d’UPS se voit aussi à l’écran.
Le wiki officiel donne la règle de lecture :
- FPS bas, UPS à 60 → problème graphique chez le joueur, rien à faire côté serveur ;
- FPS bas et UPS bas → la simulation est trop lourde : c’est le sujet de ce guide.
Point clé en multijoueur : Factorio fonctionne en lock-step. Le serveur et chaque client simulent la même usine. Si l’usine coûte 20 ms par tick, elle sera lente partout, même sur le meilleur serveur du monde. Le CPU du serveur compte, mais la conception de l’usine compte autant.
Étape 1 — Afficher les compteurs (côté joueur)
- En jeu, appuyez sur F4 pour ouvrir les options de débogage.
- Cochez
show-fps(compteur FPS/UPS en haut à droite). - Cochez
show-time-usage(le détail du temps de calcul). - Cochez
hide-mod-guissi des interfaces de mods masquent les chiffres. - Appuyez à nouveau sur F4 pour fermer.
Chaque ligne suit le format :
Nom du système : moyenne ms / minimum ms / maximum msLes valeurs portent sur les 100 derniers ticks (moins de 2 secondes). Pour lisser la mesure, tapez dans la console :
/perf-avg-frames 1000Comment lire les chiffres
- UPS constamment bas → regardez la 1ʳᵉ colonne (moyenne).
- Saccades et micro-freezes → regardez la 3ᵉ colonne (maximum).
- Repère du wiki : 1 ms ≈ 3,5 UPS. Au-dessus de 1 ms, une ligne mérite l’attention. Au-dessus de 5 ms, c’est significatif.
Étape 2 — Mesurer sur le serveur avec —benchmark
Un serveur headless n’a pas d’écran, donc pas de F4. Mais le binaire intègre un benchmark officiel qui rejoue une sauvegarde sans graphismes et mesure le temps par tick. Arrêtez le serveur (ou travaillez sur une copie de la sauvegarde), puis :
cd /opt/factorio
./bin/x64/factorio --benchmark ./saves/mon-usine.zip \
--benchmark-ticks 1000 --benchmark-runs 3 --disable-audio| Option | Rôle |
|---|---|
--benchmark FICHIER | Charge la sauvegarde et lance le benchmark |
--benchmark-ticks N | Nombre de ticks simulés (1000 par défaut) |
--benchmark-runs N | Nombre de répétitions, la carte est rechargée à chaque fois |
--benchmark-verbose all | Détail par système à chaque tick (en nanosecondes) |
--benchmark-sanitize | N’affiche que les résultats finaux |
Le benchmark donne le temps moyen par tick. Moins de 16,667 ms = 60 UPS tenus. C’est l’outil idéal pour comparer deux machines, ou mesurer l’effet d’une modification sur la même sauvegarde.
--benchmark-verboseaccepte les mêmes noms que les lignes deshow-time-usage(section Update). Pratique pour isoler un système précis sur le serveur.
Étape 3 — Trouver le coupable
Le tableau ci-dessous reprend les lignes du tableau officiel du wiki et les solutions qu’il recommande :
Ligne show-time-usage | Cause | Solution officielle |
|---|---|---|
| Entity manager | Les entités (machines, inserteurs, biters…) — souvent la plus grosse ligne | Creuser avec show-entity-time-usage (voir plus bas) |
| Transport lines | Les tapis roulants | Optimisation avancée, souvent pas prioritaire |
| Fluid manager | Les tuyaux et fluides | Moins de tuyaux, tuyaux souterrains (2 entités au lieu de 3 ou plus), solaire au lieu du nucléaire |
| Heat manager | Tuyaux de chaleur, réacteurs | Moins d’entités de chaleur, par exemple solaire au lieu du nucléaire |
| Electric networks | Le nombre de réseaux électriques, pas leur taille | Supprimer les poteaux isolés : un poteau seul = un réseau |
| Trains | Logique des trains | Moins de trains, mais plus longs |
| Chart update | Rafraîchissement de la carte par les radars | Réduire le nombre de radars |
| Circuit networks | Combinateurs et connexions | Moins de combinateurs |
| Script update | Les scripts Lua des mods, une ligne mod-XXX par mod | Retirer le mod fautif ou le signaler à son auteur |
Descendre dans l’Entity manager
Activez show-entity-time-usage dans le menu F4. Les classes les plus fréquentes :
- AssemblingMachine : toutes les machines à recette (assembleurs, usines chimiques, raffineries — pas les fours). Le nombre de machines compte, pas leur vitesse. Moins de machines plus rapides, avec balises et modules, coûtent moins cher que beaucoup de machines lentes.
- Inserter : moins d’inserteurs, qui travaillent moins souvent (technique du inserter clocking).
- Unit : les biters et spitters. Les supprimer supprime ce coût.
Attention aux mods : la ligne
Script updated’un mod n’est pas forcément son coût total. Un mod qui recalcule sans cesse les trajets des trains alourdit la ligne Trains ; un mod qui crée beaucoup de réseaux électriques alourdit Electric networks. Retirez le mod sur une copie de la sauvegarde et relancez le benchmark pour connaître son vrai coût.
Les optimisations qui rapportent le plus
Classées de la plus simple à la plus lourde à mettre en place :
- Nettoyer les poteaux orphelins : chaque poteau non relié est un réseau électrique à part entière. Sur une vieille base, ça s’accumule vite.
- Réduire les radars : gardez-en quelques-uns pour la surveillance, pas un par avant-poste si ce n’est pas nécessaire.
- Balises + modules de productivité et de vitesse : même production avec beaucoup moins de machines et d’inserteurs.
- Remplacer le nucléaire par du solaire sur une grosse base : le wiki le cite pour le Fluid manager et le Heat manager.
- Tuyaux souterrains partout où ils remplacent 3 tuyaux ou plus.
- Moins de trains, plus longs plutôt qu’une nuée de petits trains.
- Gérer les biters : la ligne Unit disparaît sans eux. Sur une partie existante, réduisez au moins leur expansion.
- Auditer les mods avec la ligne Script update.
Biters, pollution et nouvelles parties
Les paramètres d’ennemis, d’expansion, d’évolution et de diffusion de la pollution se règlent à la création de la carte via le fichier map-settings (et map-gen-settings pour la présence des bases ennemies). Si vous prévoyez une méga-usine en multijoueur, décidez-le avant de lancer --create. Voir installer un serveur Factorio headless pour la création de carte avec ces fichiers.
Réglages serveur qui influencent les performances
Ces clés de server-settings.json ne font pas gagner d’UPS sur la simulation elle-même, mais elles évitent des gels ressentis par les joueurs :
| Clé | Effet | Conseil |
|---|---|---|
autosave_interval | Minutes entre deux autosaves (10 par défaut) | Sur une énorme carte, chaque sauvegarde fige la partie quelques secondes : 15-20 min est un bon compromis |
autosave_only_on_server | Autosave uniquement côté serveur (true par défaut) | Laissez à true : les clients n’écrivent pas de fichier |
non_blocking_saving | Sous Linux, le serveur se fork pour sauvegarder sans bloquer | Expérimental selon Wube, « risque de perdre vos sauvegardes » : backups externes obligatoires si vous l’activez |
auto_pause | Pause quand personne n’est connecté | true pour ne pas faire tourner une usine vide |
max_upload_in_kilobytes_per_second | Limite la bande passante montante (0 = illimité) | 0 sur un serveur hébergé |
Sur un serveur existant, l’intervalle d’autosave se change à chaud :
/config set autosave-interval 15Tout sur les sauvegardes dans sauvegarder et restaurer un serveur Factorio.
Le choix du CPU
L’essentiel de la simulation tourne sur un seul fil d’exécution et doit tenir dans 16,667 ms. Conséquences pratiques :
- fréquence et performance par cœur d’abord : 32 cœurs lents n’aideront pas une usine qui sature un cœur ;
- cache et latence mémoire comptent aussi, car la simulation lit énormément de données à chaque tick ;
- le seul juge objectif, c’est votre sauvegarde : lancez
--benchmarksur l’ancienne machine et la nouvelle, avec les mêmes options.
Et rappelez-vous que chaque client simule aussi l’usine : un joueur avec un vieux PC sera à la traîne (il « rattrape » le serveur) même si le serveur tient ses 60 UPS.
FAQ
Mon serveur a 60 UPS mais un joueur lague, pourquoi ?
En lock-step, chaque client recalcule la simulation. Si son CPU n’arrive pas à suivre, il prend du retard sur le serveur et doit le rattraper. Le problème vient de sa machine ou de sa connexion, pas du serveur.
Plus de RAM augmente-t-elle les UPS ?
Non. La RAM doit être suffisante pour contenir la carte et les mods (4 à 8 Go selon la taille), mais au-delà elle ne fait rien pour les UPS. C’est le CPU et la conception de l’usine qui décident.
Les robots logistiques sont-ils meilleurs que les tapis pour les UPS ?
Le wiki officiel ne tranche pas et qualifie l’optimisation des tapis d’« art obscur ». La seule réponse fiable vient de la mesure : testez les deux designs avec --benchmark sur une copie de votre sauvegarde.
Space Age est-il plus lourd que le jeu de base ?
Une partie Space Age fait tourner plusieurs surfaces en même temps (planètes, plateformes spatiales). À taille d’usine égale sur chaque planète, la charge s’additionne. Le diagnostic reste le même : show-time-usage et --benchmark.
/perf-avg-frames change-t-il les performances ?
Non, il change seulement le nombre de ticks utilisés pour calculer les moyennes affichées (100 par défaut).
Conclusion
Pour optimiser les UPS d’un serveur Factorio : mesurez avec show-time-usage et --benchmark, ciblez la ligne la plus lourde, puis appliquez les solutions officielles (moins de machines grâce aux balises, moins de réseaux électriques, moins de radars, trains plus longs, audit des mods). Côté matériel, un CPU à forte performance par cœur fait la différence sur les grosses usines.
Louez un serveur Factorio sur Ryzen 9 5950X →
Pour aller plus loin
- Meilleur hébergeur Factorio 2026 : comment choisir
- Installer des mods sur un serveur Factorio
- Sauvegarder et restaurer un serveur Factorio
- Installer un serveur Factorio headless sous Linux
Sources : wiki Factorio — Diagnosing performance issues, wiki Factorio — Command line parameters, wiki Factorio — Console, server-settings.example.json (wube/factorio-data).
