zestedesavoir / zds-site / 9228

89%

push

travis-ci

Met un cache d’une heure sur get_git_version()

Depuis la version 2 de GitPython, à chaque fois qu’un objet Repo est
détruit par le ramasse-miettes, deux nouveaux ramassages de miettes
sont forcés :

https://github.com/gitpython-developers/GitPython/blob/2.1.7/git/repo/base.py#L203-L214

Étant donné que la fonction `get_git_version()` est appellée à chaque
requête une fois (pour le numéro de version dans le pied de page) et
que chaque appel à `get_git_version()` crée un objet `Repo` de
GitPython, il y a de quoi s’inquiéter d’avoir des problèmes de GC qui
se déclenche trop fréquemment et que ça dégrade les performances (en
tout cas, ça avait l’air d’être le cas chez moi).

J’ai donc mis un cache tout simple d’une heure sur la fonction
`get_git_version()`. Ça a l’inconvénient d’avoir des informations de
version erronées pendant jusqu’à une heure, mais bon.

Aussi, je n’ai pas d’instance de memcached chez moi et je ne pense
vraiment pas que se soit nécéssaire pendant le développement. J’ai
donc modifié les réglages pour utiliser le backend de cache de Django
écrit en Python (à éviter en production car pas très économique en
RAM).

=== Contrôle qualité ================================================

Commencez par logger tous les lancements du GC en mettant ça quelque
part dans le code :

```python
import gc
gc.set_debug(gc.DEBUG_STATS)
```

Désactivez les lancements automatiques du GC en rajoutant ça juste en
dessous :

```
gc.set_threshold(0)
```

Maintenant, seul les lancements forcés du GC (avec `gc.collect()`)
seront affichés sur la console. Avant ce commit, vous en verrez
exactement deux par requête (qui fait un rendu des templates, les
requêtes vers l’API ne comptent pas) à cause de `Repo.__del__`. Avec
ce commit, vous n’en verrez aucun.

2822 of 3812 branches covered (74.03%)

8 of 8 new or added lines in 1 file covered. (100.0%)

14566 of 16218 relevant lines covered (89.81%)

1.7 hits per line