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

[Ron56]

Ce tuto a été modifié le 24 aout 2008, il n'utilise plus une ipfailover mais le port 81 pour apache (pas gênant car en interne)

Je vais vous expliquer ici comment mettre un lighttpd en frontal tout en gardant un apache qui tourne derrière avec les htaccess fonctionnels


En fait lightpd va mettre en cache certains fichiers (images, css...) et les servir, si il n'as pas ce fichier en cache ou si c'est un fichier php qui est demandé il transmet ça a apache sur le port 81 ...

Pour ca on va installer un lighttpd qui a été patché avec modcache, on le trouve ici :

http://www.linux.com.cn/modcache/

J'ai pris celui la : "v1.4.3 source tarball lighttpd 1.4.18 with mod_cache v1.4.3 patched"

il faut après le compiler et l'installer

Maintenant la seule modif a faire sur la configuration d'apache est de le faire écouter sur le port 81 :

debian :

vim /etc/apache/httpd.conf

gentoo

vim /etc/httpd/httpd.conf

On change Listen en indiquant l'ip de notre serveur

Listen YY.YY.YY.YY:81

On ne redémarre pas apache tout de suite, on va d'abord paramétrer lighttpd

vim /etc/lighttpd/lighttpd.conf

Les modules activés chez moi:

    "mod_redirect",
    "mod_proxy",
    "mod_access",
    "mod_cache",

La partie concernant le cache :

### CACHE ###
cache.support-queries = "enable" #ignore '?' in url
 cache.refresh-pattern = (
     "\.(?i)(js|css|swf)$" => "240", # *.js, *.css, toutes les 4h
     "\.(?i)(jpg|bmp|jpeg|gif|png)$" => "2880", # images misent en cache 2jours
     "." => "nocache" # pas de cache pour le reste
 )

cache.bases = ("/home/lighttpd") # write cached files in /data/cache directory
cache.enable = "enable"
proxy.server  = ( "/" =>
  (
          ( "host" => "YY.YY.YY.YY", "port" => 80 ) # vers apache si jamais lighty ne peut servir le fichier
  )
)

proxy.worked-with-mod-cache = "enable" # que le mod_cache marchent avec mod_proxy

et enfin on dit a lighty d'écouter sur l'ip principale :

server.bind  = "XX.XX.XX.XX"
server.port  = 80

Prêts a passer en prod ? ^^

On stoppe apache

/etc/init.d/httpd stop

On démarrer apache

/etc/init.d/httpd start

Et on démarrer lighttpd :

/etc/init.d/lighttpd start

Logiquement mieux que ma première proposition non ?

 

[moktoipas]

ca me parrait logique, meme si je suis peux convaincu de l'utilité (a part eventuellement sur des sites dont le principal contenu est des fichier images)

 

[Ron56]

ca me parrait logique, meme si je suis peux convaincu de l'utilité (a part eventuellement sur des sites dont le principal contenu est des fichier images)

Regarde un fichier de log, tu verra le nombre d'images, favicon, css, xml servis par ton apache

 

[jcaron]

Pour ce tuto il faut au moins une IP failover (dispo sur tout les serveurs dédiés ovh et même sur les RPS ..)

Rien ne t'empêche de mettre Apache sur un autre port plutôt que de "gâcher" une bonne IP.

Jacques.

 

[Ron56]

Pour ce tuto il faut au moins une IP failover (dispo sur tout les serveurs dédiés ovh et même sur les RPS ..)

Rien ne t'empêche de mettre Apache sur un autre port plutôt que de "gâcher" une bonne IP.

Jacques.

OVH propose 4 ip pour ce dédié, elles sont inutilisées... autant prendre une autre ip et faire passer le traffic par le 80 plutot que sur la même ip sur le port 443 par exemple ...

Et oui certains proxys bloqueront le traffic sur le 81 par exemple

Sinon gain de perf flagrant ce soir ..

 

[Bool]

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

 

[elcantar]

Merci pour ce tutoriel,

Il peut être utile dans certains cas précis

EDIT : +1 reco

 

[Mumuri]

une question si tu fais un requête vers un fichier zip, c'est lighty ou apache qui va le servir ?

 

[Bool]

C'est du cas par cas, à toi de décider.

 

[Mumuri]

je parlais par rapport à la config fourni plus haut, les .zip ne semble pas être traiter par la partie gestion de cache,

donc est ce que dans ces cas là c'est lighty ou apache qui va le servir ?

 

[Julia41]

Excellent, même si supprimer complètement papache reste la meilleure solution ^^

 

[Ron56]

je parlais par rapport à la config fourni plus haut, les .zip ne semble pas être traiter par la partie gestion de cache,

donc est ce que dans ces cas là c'est lighty ou apache qui va le servir ?

les zip n'apparaissent pas dans la conf de lighty et la requête sera donc transmise a papache

 

[Mumuri]

ok dans ce cas y'aurai pas moyen de filtrer le traffic vers apache pour que lighty serve le plus de fichiers possibles ?

un truc dans ce genre là
$HTTP["url"] =~ "\.php$" {
// traffic apache (proxy ...)
}

 

[Bool]

Mumuri : il faut aussi faire gaffe aux règles de rewriting en fait. Du coup les dossiers, fichiers .php, .php3, .html et autres joyeusetées utilisées en rewriting doivent être traitées par Apache (sinon autant dégager Apache complètement).

 

[Mumuri]

Bool , pour ma part apache il a déjà dégagé

ce que je demande c'est que en admettant que les règles de rewrite ne touche que des .php est ce que y'aurai pas moyen de faire un

$HTTP["url"] =~ "\.php$" {
// traffic apache (proxy ...)
}

et encore mieux, est ce que quelqu'un aurai déjà testé ici ?

 

[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) :

//! 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.