Bonjour et merci pour ces retours sur la problématique initiale.
Quelques remarques en tant qu'auteur de KissCache :
cache HTTPS
La solution proposée implique la réécriture des URL de toutes les ressources demandées. Elle est donc beaucoup plus intrusive et non standard que l'utilisation d'un proxy classique.
[...]
Et il faut donc disposer d'outils spécialement écrits pour être compatibles avec kisscache.
Effectivement c'est un inconvénient de devoir adapter les outils pour qu'ils utilisent KissCache. C'est cependant très rapide à faire puisqu'il suffit de préfixer les urls. Dans l'outil de CI que nous utilisons (LAVA), le support de KissCache représente moins de 10 lignes de code.
L'alternative étant de faire du MITM avec la création d'un certificat racine et de le déployer sur tous les clients ce qui me semble très lourd et limite au niveau sécurité.
KISS
Clairement la gestion d'un cache HTTP(S) n'est pas simple. Le protocole HTTP est compliqué
Le nom de KissCache a pour but de bien indiquer que le fonctionnement de KissCache est simple, voir stupide et qu'il ne prends pas en compte toutes les subtilités du protocole.
nginx
La directive "proxy_cache_lock" permet de n'avoir qu'un client à la fois en train de télécharger une ressource.
D'après la documentation les autres clients vont devoir attendre que la ressource soit entièrement téléchargée avant de pouvoir y accéder.
Si nginx met plusieurs minutes à télécharger la ressource, alors les autres clients vont attendre plusieurs minutes avant de recevoir ne serait-ce que les premier bit de donnée.
KissCache permet à tous les clients, en simultané, de recevoir le fichier en même temps au fur et à mesure de son téléchargement par KissCache. Il n'y a donc qu'une très faible latence (le temps pour le worker celery de démarrer la tache).
De plus nginx ne permet toujours pas de mettre en cache les ressource disponible via https.
Async python
L'implémentation proposée souffre d'une même problème que nginx : les clients vont attendre le téléchargement complet de la ressource avant de recevoir une réponse. Le cache induit donc une latence importante lors du premier téléchargement.
Sinon j'aime bien l'idée de se baser sur async. J'y avais pensé mais je voulais aussi avoir une interface web pour voir l'état du cache, ainsi qu'une interface d'admin permettant de supprimer les urls mises en cache en cas de problème.
Travaillant tous les jours avec Django depuis de nombreuses année, j'ai donc choisi Django.
# Retour d'expérience
Posté par Rémi Duraffort (site web personnel) . En réponse au journal KissCache, kiss qui se cache. Évalué à 3.
Bonjour et merci pour ces retours sur la problématique initiale.
Quelques remarques en tant qu'auteur de KissCache :
Effectivement c'est un inconvénient de devoir adapter les outils pour qu'ils utilisent KissCache. C'est cependant très rapide à faire puisqu'il suffit de préfixer les urls. Dans l'outil de CI que nous utilisons (LAVA), le support de KissCache représente moins de 10 lignes de code.
L'alternative étant de faire du MITM avec la création d'un certificat racine et de le déployer sur tous les clients ce qui me semble très lourd et limite au niveau sécurité.
Le nom de KissCache a pour but de bien indiquer que le fonctionnement de KissCache est simple, voir stupide et qu'il ne prends pas en compte toutes les subtilités du protocole.
D'après la documentation les autres clients vont devoir attendre que la ressource soit entièrement téléchargée avant de pouvoir y accéder.
Si nginx met plusieurs minutes à télécharger la ressource, alors les autres clients vont attendre plusieurs minutes avant de recevoir ne serait-ce que les premier bit de donnée.
KissCache permet à tous les clients, en simultané, de recevoir le fichier en même temps au fur et à mesure de son téléchargement par KissCache. Il n'y a donc qu'une très faible latence (le temps pour le worker celery de démarrer la tache).
De plus nginx ne permet toujours pas de mettre en cache les ressource disponible via https.
L'implémentation proposée souffre d'une même problème que nginx : les clients vont attendre le téléchargement complet de la ressource avant de recevoir une réponse. Le cache induit donc une latence importante lors du premier téléchargement.
Sinon j'aime bien l'idée de se baser sur async. J'y avais pensé mais je voulais aussi avoir une interface web pour voir l'état du cache, ainsi qu'une interface d'admin permettant de supprimer les urls mises en cache en cas de problème.
Travaillant tous les jours avec Django depuis de nombreuses année, j'ai donc choisi Django.