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

Discussion dans 'Administration d'un site Web' créé par Ron56, 26 Juin 2008.

  1. Ron56
    Ron56 WRInaute occasionnel
    Inscrit:
    20 Novembre 2005
    Messages:
    461
    J'aime reçus:
    0

    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 :
    Code:
    vim /etc/apache/httpd.conf 
    
    gentoo
    Code:
    vim /etc/httpd/httpd.conf
    
    On change Listen en indiquant l'ip de notre serveur
    Code:
    Listen YY.YY.YY.YY:81
    
    On ne redémarre pas apache tout de suite, on va d'abord paramétrer lighttpd

    Code:
    vim /etc/lighttpd/lighttpd.conf
    
    Les modules activés chez moi:
    Code:
        "mod_redirect",
        "mod_proxy",
        "mod_access",
        "mod_cache",
    
    La partie concernant le cache :
    Code:
    ### 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 :

    Code:
    server.bind  = "XX.XX.XX.XX"
    server.port  = 80
    
    Prêts a passer en prod ? ^^

    On stoppe apache

    Code:
    /etc/init.d/httpd stop
    
    On démarrer apache
    Code:
    /etc/init.d/httpd start
    
    Et on démarrer lighttpd :
    Code:
    /etc/init.d/lighttpd start
    
    Logiquement mieux que ma première proposition non ?
     
  2. moktoipas
    moktoipas WRInaute passionné
    Inscrit:
    29 Juin 2004
    Messages:
    1 522
    J'aime reçus:
    0
    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)
     
  3. Ron56
    Ron56 WRInaute occasionnel
    Inscrit:
    20 Novembre 2005
    Messages:
    461
    J'aime reçus:
    0
    Regarde un fichier de log, tu verra le nombre d'images, favicon, css, xml servis par ton apache :)
     
  4. jcaron
    jcaron WRInaute accro
    Inscrit:
    13 Février 2004
    Messages:
    2 593
    J'aime reçus:
    0
    Rien ne t'empêche de mettre Apache sur un autre port plutôt que de "gâcher" une bonne IP.

    Jacques.
     
  5. Ron56
    Ron56 WRInaute occasionnel
    Inscrit:
    20 Novembre 2005
    Messages:
    461
    J'aime reçus:
    0
    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 ..
     
  6. Bool
    Bool WRInaute passionné
    Inscrit:
    26 Février 2004
    Messages:
    1 546
    J'aime reçus:
    0
    Tout passe par le reverse proxy, tu peux utiliser n'importe quel port en interne que ça ne changera rien.
     
  7. elcantar
    elcantar WRInaute discret
    Inscrit:
    17 Mai 2005
    Messages:
    69
    J'aime reçus:
    0
    Merci pour ce tutoriel,

    Il peut être utile dans certains cas précis

    EDIT : +1 reco
     
  8. Mumuri
    Mumuri WRInaute passionné
    Inscrit:
    3 Novembre 2004
    Messages:
    1 417
    J'aime reçus:
    0
    une question si tu fais un requête vers un fichier zip, c'est lighty ou apache qui va le servir ?
     
  9. Bool
    Bool WRInaute passionné
    Inscrit:
    26 Février 2004
    Messages:
    1 546
    J'aime reçus:
    0
    C'est du cas par cas, à toi de décider.
     
  10. Mumuri
    Mumuri WRInaute passionné
    Inscrit:
    3 Novembre 2004
    Messages:
    1 417
    J'aime reçus:
    0
    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 ?
     
  11. Julia41
    Julia41 WRInaute passionné
    Inscrit:
    31 Août 2007
    Messages:
    1 779
    J'aime reçus:
    0
    Excellent, même si supprimer complètement papache reste la meilleure solution ^^
     
  12. Ron56
    Ron56 WRInaute occasionnel
    Inscrit:
    20 Novembre 2005
    Messages:
    461
    J'aime reçus:
    0

    les zip n'apparaissent pas dans la conf de lighty et la requête sera donc transmise a papache
     
  13. Mumuri
    Mumuri WRInaute passionné
    Inscrit:
    3 Novembre 2004
    Messages:
    1 417
    J'aime reçus:
    0
    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 ...)
    }
     
  14. Bool
    Bool WRInaute passionné
    Inscrit:
    26 Février 2004
    Messages:
    1 546
    J'aime reçus:
    0
    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).
     
  15. Mumuri
    Mumuri WRInaute passionné
    Inscrit:
    3 Novembre 2004
    Messages:
    1 417
    J'aime reçus:
    0
    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 ?
     
  16. Bool
    Bool WRInaute passionné
    Inscrit:
    26 Février 2004
    Messages:
    1 546
    J'aime reçus:
    0
    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.
     
  17. wullon
    wullon WRInaute accro
    Inscrit:
    18 Septembre 2004
    Messages:
    2 811
    J'aime reçus:
    0
    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)
     
  18. Bool
    Bool WRInaute passionné
    Inscrit:
    26 Février 2004
    Messages:
    1 546
    J'aime reçus:
    0
    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.
     
  19. wullon
    wullon WRInaute accro
    Inscrit:
    18 Septembre 2004
    Messages:
    2 811
    J'aime reçus:
    0
  20. Ron56
    Ron56 WRInaute occasionnel
    Inscrit:
    20 Novembre 2005
    Messages:
    461
    J'aime reçus:
    0
    Jferais les modifs du tuto bientot
     
  21. superfc199
    superfc199 Nouveau WRInaute
    Inscrit:
    16 Août 2008
    Messages:
    1
    J'aime reçus:
    0
    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:
    //! 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.
     
  22. Ron56
    Ron56 WRInaute occasionnel
    Inscrit:
    20 Novembre 2005
    Messages:
    461
    J'aime reçus:
    0
    article mis a jour
     
  23. pierre_jean
    pierre_jean WRInaute occasionnel
    Inscrit:
    6 Avril 2005
    Messages:
    296
    J'aime reçus:
    0
    merci excellent je suis entrain de m'intéresser à ce système.

    Petite question : pourquoi un lighttpd patché mod-cache ?
     
  24. Ron56
    Ron56 WRInaute occasionnel
    Inscrit:
    20 Novembre 2005
    Messages:
    461
    J'aime reçus:
    0
    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 :D)
    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 :)
     
  25. pierre_jean
    pierre_jean WRInaute occasionnel
    Inscrit:
    6 Avril 2005
    Messages:
    296
    J'aime reçus:
    0
    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
     
  26. Ron56
    Ron56 WRInaute occasionnel
    Inscrit:
    20 Novembre 2005
    Messages:
    461
    J'aime reçus:
    0
    Oui tout a fait :)
     
  27. pierre_jean
    pierre_jean WRInaute occasionnel
    Inscrit:
    6 Avril 2005
    Messages:
    296
    J'aime reçus:
    0
    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, ...) ?
     
  28. Ron56
    Ron56 WRInaute occasionnel
    Inscrit:
    20 Novembre 2005
    Messages:
    461
    J'aime reçus:
    0
    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
     
  29. Stellvia
    Stellvia WRInaute impliqué
    Inscrit:
    28 Décembre 2004
    Messages:
    553
    J'aime reçus:
    4
    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 . :oops:
     
  30. Bool
    Bool WRInaute passionné
    Inscrit:
    26 Février 2004
    Messages:
    1 546
    J'aime reçus:
    0
    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.
     
Chargement...
Similar Threads - [Article] Lighttpd apache Forum Date
Google victime d'abus d'incompréhension dominante [Article] Droit du web (juridique, fiscalité...) 17 Septembre 2010