mirror of
https://github.com/sys4-fr/server-nalc.git
synced 2024-11-14 14:30:34 +01:00
78 lines
3.9 KiB
Plaintext
78 lines
3.9 KiB
Plaintext
[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 ;)
|
|
|