Linux est généralement le meilleur choix de serveur FiveM pour un opérateur déjà à l'aise avec l'automatisation sous Linux ; Windows est souvent le choix le plus sûr lorsqu'un outil, une ressource ou un flux de travail de support requis dépend de Windows. Il n'y a aucune affirmation universelle défendable selon laquelle l'un utilise un pourcentage fixe de CPU ou de RAM en moins. Testez le même artefact FXServer, les mêmes ressources, la même base de données et la même charge de travail sur le matériel que vous pourriez réellement déployer.
Correction : l'article précédent faisait état de différences de 23 % pour le CPU et de 40 % pour la RAM, basées sur un test non divulgué de « 168 heures/200 joueurs ». Aucun environnement reproductible ni aucune donnée brute n'existaient, ces chiffres et l'affirmation du test ont donc été supprimés.
Commencez par le support et les dépendances
Cfx.re publie des procédures de configuration de FXServer distinctes pour Windows et Linux. Consultez cette page pour les instructions actuelles concernant les artifacts, l’environnement d’exécution et le lancement. Inventoriez ensuite toutes les dépendances de votre serveur : base de données, outils de sauvegarde, surveillance, voix, anticheat, outils d’administration et ressources comportant des binaires natifs.
Une ressource écrite en Lua ou JavaScript peut être portable, tandis qu'un composant natif inclus ou un script d'installation ne l'est pas. Vérifiez la version réelle et la documentation du fournisseur ; ne présumez pas de la compatibilité à partir du nom du framework.
Tableau de décision
| Facteur | Linux | Windows |
|---|---|---|
| Expérience de l'opérateur | Excellente adéquation pour les compétences en shell, service système et automatisation d'infrastructure | Convient parfaitement aux équipes qui administrent via des outils Windows et le bureau à distance |
| Dépendance de ressource/native | Confirmer les binaires Linux, les autorisations et les chemins sensibles à la casse | Confirmer le runtime Windows pris en charge et les autorisations du compte de service |
| Automatisation | Flux de travail courants CLI/gestionnaire de services | PowerShell, Planificateur de tâches ou outils de service Windows |
| Comportement du système de fichiers | Les chemins sensibles à la casse révèlent souvent des noms de ressources incohérents | Les systèmes de fichiers par défaut masquent souvent les différences de casse jusqu'à la migration |
| Dépannage | Les journaux et les outils de processus/réseau s'intègrent aux flux de travail orientés serveur | Les outils d'interface graphique et d'événements/processus Windows peuvent être plus familiers à l'équipe |
| Performances | Mesurez la charge de travail complète ; la seule étiquette du système d'exploitation ne prédit pas le résultat. | |
Quand choisir Linux
- L'opérateur peut gérer les utilisateurs, les autorisations, les services, les journaux, les règles de pare-feu et les sauvegardes sans copier de commandes inexpliquées.
- Toutes les ressources requises et les dépendances natives prennent en charge la distribution et l'architecture choisies.
- Les flux de déploiement, de surveillance et de restauration sont déjà automatisés pour Linux.
- Un test propre détecte les chemins de ressources sensibles à la casse avant la production.
Quand choisir Windows
- Une dépendance prise en charge requise ou un flux de travail du fournisseur est spécifique à Windows.
- L'équipe peut sécuriser et maintenir Windows de manière plus fiable que Linux.
- Les outils existants de sauvegarde, de surveillance et de réponse aux incidents sont conçus pour Windows.
- L'avantage opérationnel l'emporte sur les exigences de licence et d'administration à distance pour l'hôte choisi.
Comment évaluer le choix
Utilisez la même classe de matériel physique ou virtuel, le même artefact FXServer, la même version du jeu, server.cfg, les mêmes révisions de ressources, le même jeu de données de base de données et les mêmes conditions réseau. Ne comparez pas une nouvelle installation Linux avec un serveur Windows de production utilisant des ressources différentes.
- Enregistrez l'artefact, l'OS/build, l'allocation CPU, la mémoire, le stockage, la base de données et chaque révision de ressource.
- Préparez les deux systèmes et rejouez la même charge de travail contrôlée pendant la même durée.
- Mesurez la distribution du temps d'image du serveur, la saturation du CPU, la mémoire résidente, la latence de la base de données, la perte réseau et les avertissements de ressources — pas seulement une moyenne.
- Exécutez plusieurs échantillons et conservez la série chronologique brute ainsi que le script de test.
- Testez le redémarrage, la récupération après un crash, la sauvegarde et le temps de restauration ; la fiabilité opérationnelle fait partie du choix.
- Publiez l'environnement avec le pourcentage que vous indiquez. Sans cela, présentez le résultat uniquement comme une observation de ce serveur.
Liste de contrôle de la migration
- Sauvegardez la base de données, la configuration, les secrets et les données des ressources avant de copier les fichiers.
- Normalisez la casse des noms de fichiers et des noms de ressources avant de passer sous Linux.
- Recréez des comptes de service/base de données avec le moins de privilèges possible plutôt que de copier des autorisations étendues.
- Vérifiez l'ordre de démarrage et toutes les dépendances natives.
- Testez txAdmin, les sauvegardes planifiées, la surveillance et la restauration sur le système d'exploitation cible.
- Gardez l'hôte précédent intact jusqu'à ce qu'un client réel, les écritures de base de données et la récupération après redémarrage réussissent.
Choisissez le système d’exploitation selon les dépendances du serveur et les compétences opérationnelles démontrées. Pour la procédure complète de création, consultez Comment créer un serveur FiveM.