[Article] Lighttpd et apache sur le même serveur II

[Bool]

Ce n'est qu'un détail de syntaxe... avec NginX c'est parfaitement faisable par exemple ; pour lighty t'en as pour deux minutes à vérifier dans la doc.
Il n'empèche qu'il reste aussi les dossiers, surtout si on utilise des "index.php".

Pour ce qui est du "test", bah... y a pas grand chose de plus à tester.

[wullon]

Tout passe par le reverse proxy, tu peux utiliser n'importe quel port en interne que ça ne changera rien.

D'ailleurs, on ne peut pas faire écouter apache sur une adresse ip locale tant qu'à faire ? (histoire qu'il ne soit pas accessible de l'extérieur mais uniquement en reverse proxy)

[Bool]

Si si, c'est ce que j'entendais par "port en interne". Mon Apache est en écoute sur 127.0.0.1:80 et le reverse proxy est sur l'IP publique.

[wullon]

Merci .

[Ron56]

Jferais les modifs du tuto bientot

[superfc199]

Bonjour,

C'est intéressant que vous parliez de ça car beaucoup de gens ne voient pas l'intérêt de ce système et pourtant je suis pratiquement sûr que 98% des sites seraient gagnant en l'utilisant. Et je pense qu'on peut l'élargir à tous types de contenu.

L'idée de base c'est que ça permet déjà de soulager les serveurs "intelligents" de toutes les requêtes "idiotes", c'est à dire tous les fichiers statiques. Ensuite, il faut arriver à distinguer ce qui est intelligent de ce qui est idiot dans vos pages fournies.

Bien sur, cela vous demande souvent d'un peu repenser votre architecture (pour en tirer vraiment parti) mais ça vaut le coup. Au dela des images, JS et CSS, vous avez les pages statiques, les images calculées (genre redimensionnement d'image).

Pour les incrédules qui se diraient "Mais qui peut bien faire des pages statiques ?" - Un paquet de monde. Genre allocine.fr, vous voyez "Bonjour <pseudo>", mais si vous regardez leur code vous avez les données utilisateur qui sont chargées depuis :
http://www.allocine.fr/js/monallocine.ws.asp et transmise dans le code à une fonction fillBarre.

Pour ma part, je l'utilise pour un peu tout ça. Et même pour mettre en cache des tuiles de cartographie (issues de OpenStreetMap), histoire de ne pas trop charger leur serveurs. Et ça fonctionne très bien de façon simple :
http://cache-tuiles.mabalise.com/mapnik ... /90207.png
Avec cela, j'ai mis un temps d'expiration d'une semaine pour lorsqu'on est en vue fortement zoomée et 3 semaines sinon.

Vous pouvez même vous amusez à servir des pages statiques à vos non-membres et des pages dynamiques à vos membres. J'ai essayé et ça fonctionne très bien. Dans les pages statiques, on ajoute un petit code javascript qui détecte si la personne est membre (par lecture du cookie) :

Code: Tout sélectionner

//! Fonction de lecture de cookies
//! \source http://www.quirksmode.org/js/cookies.html
function readCookie(name) {
   var nameEQ = name + "=";
   var ca = document.cookie.split(';');
   for(var i=0;i < ca.length;i++) {
      var c = ca[i];
      while (c.charAt(0)==' ') c = c.substring(1,c.length);
      if (c.indexOf(nameEQ) == 0) return c.substring(nameEQ.length,c.length);
   }
   return null;
}

// On prend la valeur du cookie donnant l'identifiant de membre
var cookieValeur = readCookie( 'GPSF_membre' );

// Si c'est bien un membre, on change l'adresse actuelle par une adresse en .mhtml
if ( cookieValeur != null && cookieValeur > 0) {
    var nouvelleURL = document.location.href.replace('.html', '.mhtml')

   if ( nouvelleURL != document.location.href ) {
      document.location.replace( nouvelleURL );
   }
}


Imaginez maintenant que vous serviez des données publiques et temps réel. Vous pouvez très bien fixer le temps d'expiration de ces données à <votre charge serveur> * 60 secondes, si vous avez beaucoup de monde, les données seront rafraichies moins fréquemment mais vos serveurs tiendront toujours le coup.

Tout dépend de vos besoins, mais la mise en cache généralisée offre une seconde dimension à l'optimisation de la fourniture de vos données. Et vous ne perdez pas le contrôle de vos données mise en cache. Si vous choisissez d'afficher les photos des membres dans une adresse http://static.monsite.com/images/membre/photo. Lorsque votre membre change de photo, vous pouvez demander au serveur de cache de balancer sa version actuelle.

Maintenant, je ne prétend pas que MA solution (Squid + Apache) est la meilleure. Ce qui m'intéresse ici c'est plus de défendre le concept de mise en cache en front-end en général. Essayez de prendre une approche plus globale de votre site, et vous devriez voir l'intérêt.

Petite remarque : Désactiver l'accès au port du serveur original (celui qui génère les pages) est un peu dangereux, car lorsque vous faites des tests, si vous vous plantez sur le temps d'expiration de vos pages, vous risquez de vous retrouver coincé.

Petite remarque bis : Comme je souhaite avoir des stats exactes, j'utilise awstats directement sur les logs de Squid.

Petite remarque tier : Bien configurer ses temps d'expiration permet que les membres demandent moins souvent les données et que les proxy de certains FAI gardent les données en mémoire (genre AOL). Mais pour ça, un serveur de Proxy n'est pas nécessaire.

[Ron56]

article mis a jour

[pierre_jean]

article mis a jour

merci excellent je suis entrain de m'intéresser à ce système.

Petite question : pourquoi un lighttpd patché mod-cache ?

[Ron56]

article mis a jour

merci excellent je suis entrain de m'intéresser à ce système.

Petite question : pourquoi un lighttpd patché mod-cache ?

Car en fait le principe c'est :

lighttpd reçoit toutes les requêtes :
soit il a le fichier en cache et il le sert directement (avec sa légèreté légendaire )
soit il n'as pas le fichier en cache, va le chercher en fesant une requete a apache, et garde le fichier en cache au passage

l'intérêt : on peut choisir les fichiers que lighttpd met en cache, le temps du cache, les htaccess sont fonctionnels

Donc il faut modcache a lighty pour que cela fonctionne

[pierre_jean]

merci pour ces précisions !

Donc en pratique on peut associer ce cache lighthttpd (image, css, js, ...) avec un cache php apache traditionnel ?

Ps: car j'utilise déjà un systeme de cache php avec apache

[Ron56]

Oui tout a fait

[pierre_jean]

Oui tout a fait

ok merci ... et je suppose que la mise en place d'un lighthttpd en plus de ton apache économise pas mal de ressource ... ?

tu as assez de recul pour donner approximativement le gain que tu as réalisé (ressources, Bp, ...) ?

[Ron56]

Oui tout a fait

ok merci ... et je suppose que la mise en place d'un lighthttpd en plus de ton apache économise pas mal de ressource ... ?

tu as assez de recul pour donner approximativement le gain que tu as réalisé (ressources, Bp, ...) ?

C'était sur un serveur d'un ami, ca n'économise pas de bande passante mais ca diminue la charge serveurs (load average, mémoire et cpu utilisés ...)


C'est vraiment pas long a mettre en place, si t'as un soucis envoi moi un mail ou un mp

Ron

[Stellvia]

Bonjour,

Je dois être bête , mais je ne comprend pas l'interet de mettre en cache des données statique tel que les css ou les images .

Mettre en cache le résultat d'un script php , je comprends le gain de resource , mettre en cache une image , la j'avoue que c'est très très flou pour moi car au final c'est tjrs le même disque dur qui va chercher la même info à un autre endroit .

[Bool]

Hello,

déjà, justement il ne s'agit pas du même "disque dur", il y a deux raisons majeures à l'utilisation d'un cache de fichier statique :
- le rapprochement géographique (cf : CDN) : plutôt que d'aller chercher les images systématiquement de l'autre coté de l'atlantique on utilise un cache en Europe par exemple.
- alléger la charge du serveur principal. Le serveur principal a parfois bien assez de boulot avec les pages dynamiques pour ne pas en plus devoir se taper le "travail ingrat" Sans oublier que selon le volume de données et le trafic, le cache disque serait bien utile pour servir ces fichiers statiques, chose que n'aura pas forcément le serveur principal.

Après pour ce qui est de l'utilisation du reverse proxy, il ne s'agit pas d'un cache ici mais de "mieux" répartir le travail. Des softs comme varnish, nginx, lighty sont souvent bien plus performants qu'Apache pour servir des fichiers statiques, mais en contrepartie fournissent moins de fonctionnalités que celui ci.
Sans oublier qu'ils permettent eux aussi de répartir simplement le trafic sur plusieurs serveurs.