last mini maj - bravo à reg et billux pour le taf!!

support/2J-Debian-LAMP-VarnishRedisMemcache.2012.tex

@@ -102,7 +102,7 @@
 \headheight=2.5cm
 \usepackage{fancyhdr}
 \pagestyle{fancy}
-\lhead{\textcolor{gris50}{\scriptsize{Administration Linux Apache PHP MySQL et Varnish/Redis/Memcache}}}
+\lhead{\textcolor{gris50}{\scriptsize{Administration Linux Apache PHP MySQL et Redis/Memcached/Varnish}}}
 \rhead{\textcolor{gris50}{\scriptsize{Formation Evolix}}}
 
 \lfoot{\scriptsize{\thepage}}
@@ -116,7 +116,7 @@
 % TITRE, AUTEUR, SUJET et DATE
 
 \author{Evolix}
-\title{Administration Linux Apache PHP MySQL et Varnish/Redis/Memcache}
+\title{Administration Linux Apache PHP MySQL et Redis/Memcached/Varnish}
 \date{Mai 2012}
 
 %% debut du document
@@ -128,7 +128,7 @@
 \vspace*{3 cm}
 \Huge{{\bfseries Formation Evolix Administration Linux }} \\
 ~\\
-Focus sur Apache, PHP, MySQL et Varnish/Redis/Memcache\\
+Focus sur Apache, PHP, MySQL et Redis/Memcached/Varnish\\
 ~\\
 \normalsize{Evolix - Mai 2012}\\
 

support/memcached.tex

@@ -17,15 +17,15 @@ applications (web ou non) afin de stocker des r
 ou base de données dont les appels sont couteux en ressources et temps
 d'exécution.
 
-Le cas d'utilisation typique est sa mise en place dans une infra ayant un
+Le cas d'utilisation typique est sa mise en place dans une infrastructure ayant un
 serveur de base de donnée et N serveurs applicatifs. Memcached est fait pour
 gérer les accès réseau concurrents, et peux être interrogé par chaque serveur
 applicatif. Le premier serveur fait sa requête à la base de données ou API
 distante, puis stocke le résultat dans Memcached. Les autres serveurs pourront
-alors directement utiliser les données misent en cache dans Memcached, en
+alors directement utiliser les données mises en cache dans Memcached, en
 bénéficiant d'un accès beaucoup plus rapide.
 
-Memcached supporte également la mise la répartition de sa base sur plusieurs
+Memcached supporte également la répartition de sa base sur plusieurs
 serveurs mis en cluster.
 
 Au contraire de Redis, Memcached ne dispose d'aucun moyen de sauvegarde
@@ -71,10 +71,10 @@ en mode d
 À noter la taille mémoire utilisée par Memcached pourra être légèrement
 supérieure à la limite fixée dans la configuration.
 On peut également fixer une limite maximum pour le nombre de connexions
-concurrente à la base via l'option \texttt{-c} (par défaut, limité à 1024). À
+concurrentes à la base via l'option \texttt{-c} (par défaut, limité à 1024). À
 noter que Memcached est capable de gérer un nombre très élevé de connexions,
 d'autant plus que chaque connexion ouverte consomme une quantité de mémoire
-négligeable, il est donc conseillé de définir une cette limite assez haute.
+négligeable, il est donc conseillé de définir une limite assez haute.
 
 Comme pour Redis, on peut également vouloir désactiver l'écoute sur un socket
 réseau pour privilégier un socket unix, pour des raisons de sécurité. L'option à
@@ -86,7 +86,7 @@ Voici quelques commandes basiques pour interagir avec la base de donn
 \begin{itemize}
   \item Connexion au serveur: on utilise \texttt{telnet}:
     \begin{verbatim}$ telnet localhost 11211\end{verbatim}
-  \item Stocke une valeur:
+  \item Stocker une valeur:
     \begin{verbatim}set greeting 1 0 11
 Hello world
 STORED\end{verbatim}

support/varnish.tex

@@ -40,7 +40,7 @@ Installation du paquet:
 \section{Configuration}
 
 Les possibilités offertes pour la configuration de Varnish sont assez vastes,
-elles seront abordés par grands thèmes.
+elles seront abordées par grands thèmes.
 
 \subsection{Paramétrage de base}
 
@@ -86,7 +86,7 @@ Et voici quelques explications sur les param
     \url{https://www.varnish-cache.org/docs/2.1/reference/varnishd.html}.
 
     \texttt{thread\_pools} indique le nombre de groupe de threads à lancer. Cette
-    valeur ne devrait pas dépasser le nombre de c\oe{}ur disponible sur le système
+    valeur ne devrait pas dépasser le nombre de c\oe{}ur disponibles sur le système
     (pour des raisons de performance). Pour \texttt{threa\_poo\_ad\_delay}, il
     s'agit du temps en milisecondes à attendre avant la création d'un nouveau
     thread. Et enfin \texttt{threa\_poo\_max} représente le nombre total de
@@ -110,7 +110,7 @@ Concr
   \item \texttt{vcl\_recv} est appelé AVANT le début de la requête au backend.
     On peut donc choisir vers quel backend renvoyer la requête. On peut aussi
     de modifier la requête (modifier des entêtes HTTP, supprimer des demandes
-    de cookies, etc\dots). Seul les actions \texttt{set req.} sont possibles.
+    de cookies, etc\dots). Seules les actions \texttt{set req.} sont possibles.
   \item \texttt{vcl\_fetch} est appelé APRÈS la réception de la réponse du
     backend. Les actions \texttt{set req.} sont possibles, mais aussi \texttt{set
     beresp.} (pour \emph{backend response}).
@@ -203,12 +203,12 @@ return (restart);
 
 En se positionnant entre le client et le serveur applicatif, Varnish permet de
 lire et surcharger si besoin les entêtes HTTP de contrôle du cache. Par défaut,
-celle ci sont lues et pris en compte, mais on peut redéfinir le comportement
+ceux ci sont lus et pris en compte, mais on peut redéfinir le comportement
 dans la configuration.
 
 Voici quelques exemples d'utilisation typique:
 
-\paragraph{Forcer le TTL pour certains contenu}
+\paragraph{Forcer le TTL pour certains contenus}
 \begin{verbatim}
 sub vcl_fetch {
     if (req.url ~ "\.(png|gif|jpg)$") {
@@ -303,7 +303,7 @@ director baz random {
   \item Une directive importante est \texttt{.max\_connections}. Elle permet de
     limiter le nombre de connexions concurrentes envoyées sur un backend. En en
     positionnant une sur chacun des backends, Varnish saura qu'il devra ignorer
-    le backend saturé et en choisir un autre, afin de ne pas le surchargé.
+    le backend saturé et en choisir un autre, afin de ne pas le surcharger.
     \begin{verbatim}
 backend www00 {
     .host = "192.0.2.8";
@@ -342,7 +342,7 @@ son comportement: utiliser un autre backend, ou renvoyer ces fichiers en cache.
 
 \subsubsection{Détection lors de la requête}
 
-Il est possible d'ajuster différent paramètres indiquant le temps d'attente
+Il est possible d'ajuster différents paramètres indiquant le temps d'attente
 maximum toléré par Varnish lors de l'interrogation d'un backend:
 \begin{verbatim}
 backend www00 {
@@ -391,10 +391,10 @@ il sera consid
 
 Dans l'exemple ci-dessus, les checks sont fait sur un intervalle de 5 secondes,
 et s'attend à avoir une réponse en moins d'une seconde. Les directives
-\texttt{.window} et \texttt{.threshold} permet de définir un cycle d'hystérésis:
+\texttt{.window} et \texttt{.threshold} permettent de définir un cycle d'hystérésis:
 pour que le backend soit vu comme étant «down», il faut que, sur une quantité de
-8, 6 checks ont échoué. Et inversement, pour qu'il repasse «up», il faut que 6
-checks sur les 8 ont réussi.
+8, 6 checks aient échoué. Et inversement, pour qu'il repasse «up», il faut que 6
+checks sur les 8 aient réussi.
 
 \subsubsection{Saint mode}
 
@@ -413,13 +413,13 @@ sub vcl_fetch {
 \end{verbatim}
 Le \texttt{beresp.saintmode} spécifie de ne plus retenter d'interroger le
 backend en cas d'erreur 500 avant un certain temps (ici 10 semonces). En effet,
-autant laisser le backend tranquille, une erreur 500 ne se résolvant rarement
+autant laisser le backend tranquille, une erreur 500 se résolvant rarement
 «magiquement» sans untervention manuelle.
 
 \subsubsection{Backend de spare}
 
 Il est également possible de déclarer un backend de spare, qui sera utilisé
-automatiquement (et seulement) si plus aucun backend ne sont disponibles:
+automatiquement (et seulement) si plus aucun backend n'est disponible:
 \begin{verbatim}
 backend wwwspare {
     .host = "192.0.2.32";
@@ -473,14 +473,14 @@ chargement de nouvelles r
 \section{Gestion des logs}
 
 Varnish permet de loguer de nombreuses informations, notamment très utiles pour
-analyser sont fonctionnement.
+analyser son fonctionnement.
 
 Par défaut, Varnish n'écrit pas ses logs dans un fichier, mais dans un segment
 mémoire, ce qui permet d'augmenter grandement les performances. Quand l'espace
 est plein, Varnish réécrit par dessus en repartant de l'origine, ce qui fait
 que la mémoire allouée pour les logs n'augmente pas.
 
-Plusieurs outils permet ensuite de récupérer les lignes de log en mémoire, et
+Plusieurs outils permettent ensuite de récupérer les lignes de log en mémoire, et
 de les exploiter, soit pour les visualiser en direct, soit pour les écrire dans
 un fichier de log.
 
@@ -492,7 +492,7 @@ L'outil \texttt{varnishtop} permet d'afficher les logs en temps r
 \texttt{varnishlog} et \texttt{varnishncsa} permettent également de lire le
 segment mémoire dans lequel varnish écrit ces logs, mais ils peuvent également
 écrire ce contenu dans des fichiers, afin d'en conserver une trace. Ils peuvent
-donc être utilisé manuellement, mais des scripts d'init sont fourni pour
+donc être utilisés manuellement, mais des scripts d'init sont fournis pour
 permettre de les lancer au démarrage en mode démon.\\
 \texttt{varnishncsa}, comme son nom l'indique, permet d'avoir les logs d'accès
 HTTP au format NCSA (comme ceux générés par les serveurs web tel que Apache).