10-06-2010, 09:36 PM
(10-06-2010, 09:24 PM)oxman a écrit : Car ça peut toujours partir en vrille, plus tu ajoutes de complexité, ici de cache, un moment tu vas oublier un cas ou faire correctement expirer le cache, ou alors un cas ou le cache va être mal utilisé et donc inutile.
Et ça sans compter les problèmes indépendant de ton code qui peuvent survenir, par exemple pour ton cas, tu fais un système de cache clean, qui marche du tonnerre. Pouf tu as 100000 utilisateurs un jour et tu te rends compte que ton application est devenue super lente parce que tu as 100000 petits fichiers dans un répertoire ce qui ne facilite pas le système de cache à chercher les fichiers qui l'intéresse alors qu'avec un système de sous-dossier pour partitionner les fichiers il n'y aurait pas le problème.
Ca n'est qu'un exemple, il peut y en avoir des tonnes et pas que pour le cache, pour tout et n'importe quoi.
Ça fait partie du cycle de vie de l'application : il faut être cohérent selon les besoins qu'on a.
Tu parles de mise à l'échelle de l'application. Si j'attends les 100 000 utilisateurs, j'aurais de toute manière besoin d'un cache : donc je m'exposerais aux problèmes que tu cites. La différence, c'est que si j'attends ce moment, je devrais mettre en place le cache dans un environnement probablement plus complexe : au pied du mur, j'oublierai probablement des cas d'utilisation.
En m'y prenant plus tôt, je vois le système se complexifier et je peux ajuster ma politique d'expiration des caches au gré de l'évolution de l'application.
Tu n'es pas d'accord ? (Si non, pourquoi ?)
Ensuite, tu parles des limites du système de fichiers : c'est vrai, c'est un risque. Un risque qui a une contremesure toute trouvée : le passage à Memcached, qui est éprouvé face à ce genre de situations (d'ailleurs, le problème des accès disques ne se pose pas avec celui-ci). Ce changement de moteur de cache est trivial dans Rails.
Sephi-Chan