1
0
mirror of https://github.com/sys4-fr/server-nalc.git synced 2024-11-11 04:50:17 +01:00
server-nalc/mods/profnsched/README.txt

78 lines
3.9 KiB
Plaintext
Raw Normal View History

[profnsched] : Profile and schedule mod (fr)
============================================
Buts :
======
* Objectif principal : maintenir le temps d'exécution du pas (step) au plus près du tick rate (dedicated_server_step)
* analyser en temps réel les temps d'execution de certaines fonctions de module
(actuellement uniquement globalstep et minetest.after)
* Décaler, de façon adaptative, l'exécution des modules qui l'autorisent explicitement en cas de surcharge
* (WIP) Indiquer à chaque module le temps dont il dispose pour s'exécuter (utile pour les modules qui adaptent leurs calculs)
Concepts :
==========
* Les travaux en attentes sont placés dans des files d'executions priorisées
* La première file est toujours exécutée, même en cas de surcharge
* Les autres files sont traitées tant qu'il reste du temps (< tick rate)
* En cas d'arrêt prématuré (surcharge), chaque classe de priorité est transférée dans la précédente (ainsi en cas de surcharge on est certain que le travail sera executé)
* Il peut y avoir autant de files que souhaités (rester raisonnable cependant)
* Concrêtement :
- Dans l'idéal, toutes les files sont exécutées à chaque pas (step) !
- En cas de surcharge, on a la garantie que les travaux de la file n seront exécutés au pas (step) n ou n+1
- Mais on a aucune garantie de temps (à cause de la surcharge, les pas (step) dépassent le tick rate, parfois de plusieurs secondes...)
- Ne pas oublier que de toute façon en cas de surcharge, ni globalstep.after ni minetest.after ne peuvent garantir le temps écoulé
* En cas de surcharge une trace des travaux exécutés est transcrite dans le log du serveur (pour analyse des goulots d'étranglement)
Fonctions utiles :
==================
* Pour programmer :
* scheduler.add(class, job) -- ajoute le travail 'job' dans la file n° 'class' (job = {mod_name, func_id, func_code[, args]})
* scheduler.asap(class, func_code) -- ajoute une fonction à exécuter dans la file n° 'class'
* Pour profiler (commande chat) :
/profnsched (génère un dump de stats au bout du nombre de secondes définies dans minetest.conf)
/profnsched n (génère un dump de stats au bout de n secondes)
/profnsched 0 (dump les stats en temps réel en cas de surcharge)
* Pour profiler (minetest.conf)
profnsched_activate = true/false
profnsched_dump_delay = n (dump des stats au bout de n secondes (si activé))
Comparaisons :
==============
* minetest.globalstep
- Pour les traitements qui *nécessitent* une exécution à chaque pas (step)
- Peut être remplacé par minetest.after(0, *) ou scheduler.asap(0, *) mais cela ajoute du temps de traitement inutile.
* minetest.after
- Pour les traitements qui doivent s'exécuter après un certain temps écoulé
- Dans l'idéal c'est fiable, mais en cas de surcharge le temps peut être largement dépassé (inévitable)
* scheduler.add/asap
- Pour les traitements qui souhaitent être fréquemment exécutés
- mais qui n'ont pas besoin d'une fréquence fixe (tick)
- ni d'une durée précise entre chaque execution
- en bref qui acceptent de sacrifier de leur temps au profit de traitements plus importants qu'eux
Exemples possibles :
====================
* Les calculs capitaux en file 1
* Les traitements d'UI pourraient être en file 2 ou 3
* Les traitements encore moins importants en file supérieure (génération des plantes, ...)
Hack actuel :
=============
* La boucle minetest.after qui vérifie les travaux expirés est classée en faible priorité (file 4)
(dans le meilleur des cas la vérification a lieu à chaque pas (step), sinon on reporte)
* Les travaux eux-mêmes issus de minetest.after sont en file 4
(dans le meilleur des cas ils seront exécutés au prochain pas (step), sinon on reporte)
TODO :
======
* fournir en paramètre au module appelé le temps d'execution souhaité/maximum
* mettre d'autres appels en surveillance (on_step, ...)
* nettoyer/optimiser le code ;)