Wiki » Historique » Version 12
Version 11 (Benjamin Bohard, 17/04/2015 17:25) → Version 12/14 (Benjamin Bohard, 17/04/2015 17:30)
h1. Wiki
h2. Configuration du proxy-cache
Livrer une configuration ubuquiste pour squid n'est pas possible et il est fréquent de devoir ajuster les paramètres du proxy cache dans la phase d'administration.
L'approche qui sera mise en place proposera des profils orientant dans le choix de jeux de valeurs pour les paramètres de squid.
h3. Profils d'utilisation
Les profils d'utilisation d'un proxy-cache sont déterminés par le type de fichiers demandés, leur variété, leur fréquence de consultation.
Ces facteurs déterminants peuvent évoluer au cours de l'utilisation du serveur, aussi il ne faut pas compter sur la pérennité du choix fait à l'instanciation du serveur.
h3. Efficacité du proxy-cache
Le rôle de la fonction cache du proxy est d'alléger la charge sur la connexion à Internet et de fluidifier l'obtention de ressources en en stockant une partie en local.
On peut mesurer l'efficacité du proxy-cache avec trois marqueurs :
* hit rate : le rapport du nombre de fichiers distribués depuis le cache sur le nombre total de fichiers demandés ;
* byte hit rate : le rapport du volume des fichiers distribués depuis le cache sur le volume total des fichiers demandés ;
* temps de réponse : le temps nécessaire pour distribuer les fichiers demandés (depuis le cache ou non).
Selon les configurations, le temps de réponse peut-être plus long dans le cas d'une distribution depuis le cache.
h3. Paramètres d'optimisation
h4. Algorithmes de suppression des objets du cache
Les différents algorithmes privilégient un aspect du cache : hit rate, byte hit rate, etc.
Ces algorithmes doivent être en phase avec d'autres paramètres (taille maximale d'objets à mettre en cache par exemple).
h5. lru
least recently used
h5. lfuda
least frequently used dynamic aging
h5. gdsf
greedy dual size frequence
h4. Cache
h5. Taille
Relation forte avec la mémoire vive disponible : l'index du cache est gardé en mémoire vive
h5. FS sous-jacent
* un filesystem voire un disque propre (notamment pour permettre de remettre le cache à zéro plus rapidement et pour limiter la cohérence;
* journalisation ;
* option noatime.
h5. Structure du cache
h6. ufs
Le cache est géré dans une arborescence à deux niveaux.
L'accès et la création des fichiers sont gérés par le processus squid. Certaines fonctions sont bloquantes et participent au ralentissement du service.
h6. aufs
Le cache est géré dans une arborescence à deux niveaux (idem ufs).
Un nombre de threads par cache_dir est en charge d'accéder et de créer les fichiers dans le cache. Le nombre de fichiers ouvrables (file descriptors) est mutualisé. Selon la version de squid, tout ou partie des opérations sur le cache sont asynchrones.
h6. diskd
Le cache est géré dans une arborescence à deux niveaux (idem ufs).
Un processus indépendant est en charge du cache.
h6. rock (pour Trusty)
Un fichier
h2. Étude de cas
h3. Paramètres par défaut dans le module Amon
LRU avec une taille d'objets à 32768
UFS
h3. Adaptation expérimentée à Nouméa
LFUDA avec une taille d'objets à 32768
UFS
délai d'abandon à 0 pour répondre aux requêtes superflues répétitives
h3. Profilage du proxy-cache
h4. squidclient
h4. web polygraph
http://squidbook.org/extras/pm4-pf2.pg.txt
h2. Configuration du proxy-cache
Livrer une configuration ubuquiste pour squid n'est pas possible et il est fréquent de devoir ajuster les paramètres du proxy cache dans la phase d'administration.
L'approche qui sera mise en place proposera des profils orientant dans le choix de jeux de valeurs pour les paramètres de squid.
h3. Profils d'utilisation
Les profils d'utilisation d'un proxy-cache sont déterminés par le type de fichiers demandés, leur variété, leur fréquence de consultation.
Ces facteurs déterminants peuvent évoluer au cours de l'utilisation du serveur, aussi il ne faut pas compter sur la pérennité du choix fait à l'instanciation du serveur.
h3. Efficacité du proxy-cache
Le rôle de la fonction cache du proxy est d'alléger la charge sur la connexion à Internet et de fluidifier l'obtention de ressources en en stockant une partie en local.
On peut mesurer l'efficacité du proxy-cache avec trois marqueurs :
* hit rate : le rapport du nombre de fichiers distribués depuis le cache sur le nombre total de fichiers demandés ;
* byte hit rate : le rapport du volume des fichiers distribués depuis le cache sur le volume total des fichiers demandés ;
* temps de réponse : le temps nécessaire pour distribuer les fichiers demandés (depuis le cache ou non).
Selon les configurations, le temps de réponse peut-être plus long dans le cas d'une distribution depuis le cache.
h3. Paramètres d'optimisation
h4. Algorithmes de suppression des objets du cache
Les différents algorithmes privilégient un aspect du cache : hit rate, byte hit rate, etc.
Ces algorithmes doivent être en phase avec d'autres paramètres (taille maximale d'objets à mettre en cache par exemple).
h5. lru
least recently used
h5. lfuda
least frequently used dynamic aging
h5. gdsf
greedy dual size frequence
h4. Cache
h5. Taille
Relation forte avec la mémoire vive disponible : l'index du cache est gardé en mémoire vive
h5. FS sous-jacent
* un filesystem voire un disque propre (notamment pour permettre de remettre le cache à zéro plus rapidement et pour limiter la cohérence;
* journalisation ;
* option noatime.
h5. Structure du cache
h6. ufs
Le cache est géré dans une arborescence à deux niveaux.
L'accès et la création des fichiers sont gérés par le processus squid. Certaines fonctions sont bloquantes et participent au ralentissement du service.
h6. aufs
Le cache est géré dans une arborescence à deux niveaux (idem ufs).
Un nombre de threads par cache_dir est en charge d'accéder et de créer les fichiers dans le cache. Le nombre de fichiers ouvrables (file descriptors) est mutualisé. Selon la version de squid, tout ou partie des opérations sur le cache sont asynchrones.
h6. diskd
Le cache est géré dans une arborescence à deux niveaux (idem ufs).
Un processus indépendant est en charge du cache.
h6. rock (pour Trusty)
Un fichier
h2. Étude de cas
h3. Paramètres par défaut dans le module Amon
LRU avec une taille d'objets à 32768
UFS
h3. Adaptation expérimentée à Nouméa
LFUDA avec une taille d'objets à 32768
UFS
délai d'abandon à 0 pour répondre aux requêtes superflues répétitives
h3. Profilage du proxy-cache
h4. squidclient
h4. web polygraph
http://squidbook.org/extras/pm4-pf2.pg.txt