J'ai déjà parlé à plusieurs reprises sur ce blog de rss2email pour récupérer les flux rss. Avec plus d'une centaine de flux, il est un peu lent et consomme tout de même pas mal de CPU. Je me suis donc lancé dans un profilage du code pour comprendre ce qui consommait le plus.

Deux objectifs à ce billet :

• rapporter ma méthode
• demander à la communauté ce qu'on peut faire pour optimiser ce que j'ai identifié (cf la fin de ce billet)

Mise en place du profilage

On commence par cloner le dépôt de rss2email

git clone https://github.com/wking/rss2email
cd rss2email

ainsi que feedparser, la bibliothèque principale car je pressens qu'on va devoir y jeter un coup d'oeil.

git clone https://github.com/kurtmckee/feedparser.git

Je crée un virtualenv avec pew, comme suggéré par sametmax, c'est bien plus pratique.

pew new profiler

Construction et déploiement du code avec la méthode develop. Elle fait un lien symbolique, ce qui permet de ne pas avoir à faire une installation à chaque modification de code, ce qui est très intéressant lorsqu'on avance à petit pas dans le profilage.

cd feedparser
python setup.py develop
cd ..
# rss2email
python setup.py develop

On vérifie que ça tourne comme on l'attend. J'ai importé mes fichiers de conf et de base de données du serveur de prod pour être en condition de données réelles. L'option -n permet de faire un dry-run, c'est-à-dire de ne pas envoyer le courriel.

r2e -c rss2email.cfg  run 30 -n

J'installe la bibliothèque qui permet de profiler le CPU. Voir cette référence que j'ai trouvé utile pour les différentes méthodes de profilage en python.

pip install line_profiler

Pour activer le profilage sur une fonction, il suffit d'utiliser un décorateur.

@profile
def func(var):
    ...

On lance ensuite kernprof

kernprof -l -v r2e -c rss2email.cfg  run 30 -n

De manière récursive, je descend dans le code en répérant les fonctions qui prennent le plus de temps CPU.

Résultats

Le résultat est que le temps CPU est principalement utilisé par feedparser, que la moitié du temps sert à récupérer des données à travers le réseau (urllib) et l'autre moitié à faire du parsage de date. Ce parsage est traité en interne par feedparser.

Ces résultats sont rapportés dans ce ticket.

Regardons plus en détails. Il existe plusieurs formats à gérer. Pour mes flux, c'est principalement rfc822.

Le code commence par ceci

timezonenames = {
    'ut': 0, 'gmt': 0, 'z': 0,
    'adt': -3, 'ast': -4, 'at': -4,
    'edt': -4, 'est': -5, 'et': -5,
    'cdt': -5, 'cst': -6, 'ct': -6,
    'mdt': -6, 'mst': -7, 'mt': -7,
    'pdt': -7, 'pst': -8, 'pt': -8,
    'a': -1, 'n': 1,
    'm': -12, 'y': 12,
    'met': 1, 'mest': 2,
}

def _parse_date_rfc822(date):
    """Parse RFC 822 dates and times
    http://tools.ietf.org/html/rfc822#section-5
    There are some formatting differences that are accounted for:
    1. Years may be two or four digits.
    2. The month and day can be swapped.
    3. Additional timezone names are supported.
    4. A default time and timezone are assumed if only a date is present.
    """

    daynames = set(['mon', 'tue', 'wed', 'thu', 'fri', 'sat', 'sun'])
    months = {
        'jan': 1, 'feb': 2, 'mar': 3, 'apr': 4, 'may': 5, 'jun': 6,
        'jul': 7, 'aug': 8, 'sep': 9, 'oct': 10, 'nov': 11, 'dec': 12,
    }

    parts = date.lower().split()

Avec le profilage, j'ai vu que 10% du temps était utilisé à construire le set(). Les avantages de set sont de garantir l'unicité et d'avoir des opérations de type union ou intersection (comme le dit la doc). Ici, daynames n'est pas modifié, on n'a pas donc besoin de fabriquer l'unicité sur quelque chose qu'on définit. Seule une itération est faite sur cet élément. Le set() ne me semble donc pas justifié.

J'ai ouvert un pull request pour corriger le set en tuple, et passer la déclaration en variable globale.

Si vous avez des suggestions pour améliorer les performances, n'hésitez pas à les partager sur github ou par email. Merci !

Note : email.utils.parsedate_tz semble être plus lent que l'implémentation de feedparser, en terme CPU, c'est relativement comparable.