Tout d’abord, parlons des pièges que j’ai rencontrés, des problèmes rencontrés en production, je planifie l’exécution du script Python et surveille le processus, le temps d’exécution du script Python est bien plus long que le temps d’exécution du programme que je compte dans le script Python.
Le temps de surveillance de l’exécution des scripts Python est de 36 heures, tandis que le temps d’auto-exécution dans les scripts Python est d’environ 4 heures.
La première chose qui me vient à l’esprit après ce problème, c’est qu’il y a un souci avec Linux, et je n’ai trouvé aucune anomalie dans divers journaux.
Ensuite, je pense au py2neo utilisé en python pour écrire des données de façon asynchrone, bloquant l’exécution du processus.
Enfin, le problème a été trouvé : la façon dont le script python utilise time.clock() pour compter le temps d’exécution du CPU, et non celui du programme.
Ensuite, comparons plusieurs statistiques temporelles en Python :
Méthode 1 :
datetime.datetime.now() obtient la date actuelle, et après la fin de l’exécution du programme, la valeur temporelle obtenue par cette méthode correspond au temps d’exécution du programme.
Méthode 2 :
temps.temps() pour obtenir le temps courant depuis l’époque (En quelques secondes）。 Si l’horloge du système les fournit, il peut y avoir une fraction de seconde. Donc cet endroit renvoie un type de virgule flottante. Ce qui est obtenu ici, c’est aussi le temps d’exécution du programme.
Méthode 3 :
time.clock() renvoie l’heure CPU depuis le début ou l’appel du programme. Cela a autant de précision que l’enregistrement système. Le retour est également de type virgule flottante. Ce que vous obtenez ici, c’est le temps d’exécution du CPU.
Note : Temps d’exécution du programme = temps CPU + temps d’entrée en orbite + temps d’hibernation ou d’attente
Voici comment je teste le temps d’exécution de la fonction en utilisant la méthode 2 :
|
Publié sur 23/04/2018 15:54:36
|
|
|
|
