Sauvegarder moins, sauvegarder mieux

Le serveur, lui, sert tous les joueurs à la fois. Une boucle serveur qui travaille pour chaque joueur, chaque seconde, se multiplie par le nombre de joueurs connectés.

La sauvegarde à l'aveugle

CreateThread(function()
    while true do
        Wait(1000)
        for _, id in ipairs(GetPlayers()) do
            MySQL.update.await('UPDATE comptes SET argent = ? WHERE id = ?', { ... })
        end
    end
end)

Avec 64 joueurs : 64 requêtes par seconde, même quand rien n'a changé. C'est la base de données qui sature la première, et avec elle tout ce qui l'attend : connexions, inventaires, achats.

Trois idées qui changent tout

1. Marquer ce qui a changé. Une table modifie[id] = true, remplie quand l'argent bouge. On ne sauvegarde que ces joueurs-là.
2. Grouper. Une sauvegarde par minute plutôt qu'à chaque gain : dix gains en une minute, une seule requête.
3. Réagir aux événements. À la déconnexion, FXServer déclenche l'événement playerDropped, avec source qui désigne le joueur qui part. C'est le moment de sauvegarder ce qui ne l'a pas encore été :

AddEventHandler('playerDropped', function(raison)
    local src = source
    -- sauvegarder src s'il a des modifications en attente
end)

playerDropped est un événement du serveur lui-même : AddEventHandler suffit, pas besoin de RegisterNetEvent -- ce qui évite en prime qu'un client puisse le déclencher.

Le principe dépasse FiveM : on ne demande pas « est-ce que quelque chose a changé ? » toutes les secondes, on réagit quand quelque chose change.