From dde8f03192b8ccefe354ca4751ca6d79527123b5 Mon Sep 17 00:00:00 2001 From: Quentin Dufour Date: Wed, 31 Jul 2024 18:22:59 +0200 Subject: [PATCH] =?UTF-8?q?conclusion=20amend=C3=A9e?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- _posts/2024-07-31-img-processor.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2024-07-31-img-processor.md b/_posts/2024-07-31-img-processor.md index 9bfa1f1..8029e89 100644 --- a/_posts/2024-07-31-img-processor.md +++ b/_posts/2024-07-31-img-processor.md @@ -98,5 +98,5 @@ Dans ce billet de blog, on a vu que la conversion et redimensionnement des image De ce fait, c'est un défi à mettre en oeuvre dans un environnement contraint en ressources (computing within limits). En s'autorisant un *failure mode*, on peut cependant s'assurer d'une certaine résilience du système face à des pics de charge trop importants, et donc assurer la viabilité d'un tel service. La théorie des fil d'attentes et l'exemple de CoDel est un exemple de comment & quand basculer entre le *normal mode* et le *failure mode*. Enfin, un système de cache bien conçu permettrait une réduction significative de l'utilisation CPU+RAM pour un coût supplémentaire en stockage modique. -Idéalement, le coût supplémentaire en stockage serait imputé à l'utilisateur ; on peut aussi envisager utiliser le cache pour un traitement asynchrone des images, comme la génération d'un grand nombre de miniatures. +Idéalement, le coût supplémentaire en stockage serait imputé à l'utilisateur ; on peut aussi envisager utiliser le cache pour un traitement asynchrone des images, comme la génération d'un grand nombre de miniatures qui ne peut pas être fait de manière synchrone en environnement contraint.