Lighttpd et apache sur le même serveur I

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
    -- en fait il y a bien mieux comme optimisation , nouvel article bientot :) --

    Voir https://www.webrankinfo.com/forum/t/article-lighttpd-et-apache-sur-le-meme-serveur-ii.95826/

    Bonjour,

    Je vais vous expliquer comment alleger la charge de votre serveur en servant les fichiers statiques (.ico, .jpeg, .css...) avec lighttpd et en continuant a utiliser apache pour le dynamique et le frontend (les htacess marcheront toujours avec cette méthode ...)

    J'ai fait la manip sur un serveur Gentoo (release OVH) d'un ami mais je vais vous expliquer la méthode pour debian aussi ...

    Je conseille de quand même maitriser un minimum avant de se lancer dans cette optimisation

    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 ..)

    Déjà pour configurer l'ip failover le vous conseille d'aller visiter ce guide : http://guides.ovh.com/ConfigurerIpSupplementaire

    C'est bon vous avez deux IP qui pointent vers votre serveur ?

    On peut passer a la suite...

    On va forcer apache a écouté sur l'ip classique (ici XX.XX.XX.XX) et lighttpd sur l'ip failover (ici YY.YY.YY.YY)

    Pour ca on va éditer le fichier de configuration d'apache

    debian :
    Code:
    vim /etc/apache/httpd.conf 
    
    gentoo
    Code:
    vim /etc/httpd/httpd.conf
    
    Ensuite dans le virtualhost du site on ajoute
    Code:
            RewriteEngine On
            RewriteRule (.*\.(ico|css|jpg|gif|png))$ http://YY.YY.YY.YY/USER/www/$1 [P,NC]
    
    ATTENTION, nous utilisons le mode proxy ici, il faudra peut etre recompiler apache ou activer le module proxy :)

    Mais il faut aussi indiquer a apache de passer seulement par notre ip principale

    Code:
    Listen XX.XX.XX.XX:80
    
    On sauvegarde mais sans redémarrer httpd (car lighttpd n'est pas en place encore

    On install lighttpd

    debian :
    Code:
    apt-get install lighttpd
    gentoo
    Code:
    emerge -av lighttpd
    Note : on peut enlever toute les option (USE="-ssl..." emerge lighttpd) en laissant juste "pcre)

    On édite le fichier de conf de lighttpd
    Code:
    vim /etc/lighttpd/lighttpd.conf
    on doit ajouter/editer les paramètres suivants :

    Code:
    var.basedir  = "/home/"
    ...
    "mod_redirect",
    ...
    server.bind  = "YY.YY.YY.YY"
    ...
    #si lighttpd recoit une requete autre qu'une image ou un feuille de style on redirige la requete vers le apache
    $HTTP["url"] !~  "\.(ico|css|jpg|gif|png)$" {
        url.redirect = (
          "^/(.*)" => "url.du.domaine"
        )
    }
    
    Si vous avez des question ...
     
  2. moktoipas
    moktoipas WRInaute passionné
    Inscrit:
    29 Juin 2004
    Messages:
    1 522
    J'aime reçus:
    0
    Re: [Article] Apache pour le dynamique, lighty pour le stati

    Ca sert a quoi ?
     
  3. Ron56
    Ron56 WRInaute occasionnel
    Inscrit:
    20 Novembre 2005
    Messages:
    461
    J'aime reçus:
    0
    Re: [Article] Apache pour le dynamique, lighty pour le stati

    A servir les fichier statique avec lighttpd (processus leger) et a ne pas utiliser des processus lourds (apache compilé avec php) pour le faire :)

    Au final tu réduit la RAM utilisée
     
  4. moktoipas
    moktoipas WRInaute passionné
    Inscrit:
    29 Juin 2004
    Messages:
    1 522
    J'aime reçus:
    0
    Je suis pas sur que le gain soit trenscendant...
    d'autant qu'a la place d'utiliser plus de ram ( ce qui est a prouver) , on utilise du cpu..
     
  5. Ron56
    Ron56 WRInaute occasionnel
    Inscrit:
    20 Novembre 2005
    Messages:
    461
    J'aime reçus:
    0
    Je vais voir la charge ce soir durant le pic, jvous dirais ça :)

    Ron
     
  6. moktoipas
    moktoipas WRInaute passionné
    Inscrit:
    29 Juin 2004
    Messages:
    1 522
    J'aime reçus:
    0
    Ouki ^^
    Faudra la comparer a la charge d'avant bien sur :)
     
  7. Bool
    Bool WRInaute passionné
    Inscrit:
    26 Février 2004
    Messages:
    1 546
    J'aime reçus:
    0
    Bah disons que si on a un seul Apache bien lourd en front end, ça sert effectivement à rien : les fichiers servis par lighty transitent malgré tout par la couche "Apache PHP".... et c'est toujours notre Apache lourdingue qui gère le KeepAlive quasi obligatoire des images.

    Le reverse proxy, j'ai adopté il y a quelques mois et je suis vraiment fan. Mais pour moi le but c'est justement de mettre quelque chose de plus efficace en front, pas le contraire.
     
  8. Ron56
    Ron56 WRInaute occasionnel
    Inscrit:
    20 Novembre 2005
    Messages:
    461
    J'aime reçus:
    0
  9. Bool
    Bool WRInaute passionné
    Inscrit:
    26 Février 2004
    Messages:
    1 546
    J'aime reçus:
    0
    Bah il s'agit de faire le contraire : en front end tu mets un reverse-proxy ou serveur web très rapide et léger, qui se contentera de servir le contenu statique et de maintenir la connexion keepalive.
    Du coup Apache quant à lui ne gèrera plus que le dynamique et éventuellement le rewriting.

    Selon le contenu du site, l'économie en CPU et mémoire peut être énorme.
    Mais ça demande une certaine rigueur dans l'organisation du site, les fichiers .htaccess étant généralement ignorés par le serveur web "frontal".
     
  10. Ron56
    Ron56 WRInaute occasionnel
    Inscrit:
    20 Novembre 2005
    Messages:
    461
    J'aime reçus:
    0

    Bon jvais tenté un apache leger devant et un lourd derrière ...
     
  11. Bool
    Bool WRInaute passionné
    Inscrit:
    26 Février 2004
    Messages:
    1 546
    J'aime reçus:
    0
    Pour le coup ça n'engage que moi (la dernière fois j'ai cru comprendre que certains n'étaient pas d'accord...) mais si c'est pour avoir deux Apache je trouve que ça ne sert à rien non plus.
    Un seul Apache2 avec le MPM event et un PHP en FastCGI consommera encore moins de ressources et sera plus performant.
     
  12. Ron56
    Ron56 WRInaute occasionnel
    Inscrit:
    20 Novembre 2005
    Messages:
    461
    J'aime reçus:
    0
    Et un apache hyper allégé en front qui forward tout a un lighttpd ?

    Juste pour que le htacess marche ...

    edit : que penser de http://www.linux.com.cn/modcache/ ?
     
  13. Bool
    Bool WRInaute passionné
    Inscrit:
    26 Février 2004
    Messages:
    1 546
    J'aime reçus:
    0
    Bah et ton PHP tu le mets où ? Tu fais tourner un troisième serveur web ?
    Et si ton Apache en front est si léger, en quoi est-ce génant qu'il desserve lui même les fichiers statiques ?
     
  14. Ron56
    Ron56 WRInaute occasionnel
    Inscrit:
    20 Novembre 2005
    Messages:
    461
    J'aime reçus:
    0
    Jvais essayer modcache
     
  15. Bool
    Bool WRInaute passionné
    Inscrit:
    26 Février 2004
    Messages:
    1 546
    J'aime reçus:
    0
    Il ne faut pas déballer du lighty juste par effet de mode, il faut aussi s'en servir.

    Il faut voir ce qui te pose problème à la base. Pour moi un Apache classique a ces soucis :
    - avec des modules gourmands (PHP) il consomme beaucoup de mémoire
    - dans ses versions prefork et worker sa gestion du keepalive est très consommatrice de mémoire également (ce sont les mêmes threads/processus qui gèrent une connexion active et une connexion "endormie")
    - c'est sûrement dû à toutes ses fonctions, mais il n'est pas très rapide même pour du statique. Une version "légère" et threadée reste d'après mes (maigres) tests 2 fois moins rapide qu'NginX.
    - il gère assez mal les grand nombre de connexions simultanées


    Pour le premier point, l'idéal à mon avis est d'isoler PHP grâce à FastCGI. En plus on y gagne en sécurité. Mais de manière générale il faut évidement virer tout ce qu'on utilise pas.
    D'un autre coté si il y a un reverse-proxy en front qui traite tout ce qui est statique, et donc que notre Apache ne serve plus que pour les pages dynamiques, ce n'est pas bien grave que PHP soit embarqué avec chaque connexion.

    Pour le deuxième point je vois deux solutions : utiliser la version "event" d'Apache2 qui est la seule à gérer de manière spécifique le keepalive, ou bien mettre en place un reverse-proxy qui lui gèrera ça correctement.

    Le troisième point n'est pas forcément génant selon le site. Pour le régler l'idéal à mon avis est de mettre directement les images sur un serveur/cdn dédié à cela en utilisant un ou des sous demaines spécifiques.
    L'autre solution est là encore le reverse proxy en front, qui se chargera de ça de manière très rapide.

    Pour le dernier point, mis a part la mise en cluster le fait de déléguer le keepalived et les fichiers statiques à un autre serveur web améliore grandement les choses. Sans oublier que seules les requêtes valides et complètent arriveront jusqu'à Apache, ce qui évite également les problèmes avec les internautes aillant des connexions lentes.

    ====

    En considérant ces points, j'ai deux solutions de prédilection :
    - l'utilisation d'Apache MPM event + PHP en FastCGI. C'est sans doute le plus simple à mettre en place et on ne perd pas ses petites habitudes (les fichiers .htaccess sont traités comme d'habitude quoi, pas de modification d'IP, pas de configuration supplémentaire).
    - la mise en place d'un reverse proxy (j'ai opté pour NginX) devant Apache, qui se charge donc du keepalived, de la compression à la volée et des fichiers statiques. Pour les quelques rares dossiers qui auraient besoin d'être traitées par Apache (à cause d'un .htaccess vraiment tordu) je mets simplement en place une exception pour indiquer à NginX de transmettre à Apache.

    ====

    Pour ce qui est des caches (via Apache, Lighty, ou des softs spécialisés tels que varnish), le but est de rendre complètement statiques certaines pages du site. Ce sera toujours plus rapide que des pages traitées par PHP, mais ça ne règle pas les soucis enoncés ci dessus.
    Pour ma part je ne suis pas fan, j'aurais tendance à procéder autrement mais pourquoi pas.

    Après chacun a ses petites habitudes, mais perso je ne vois pas l'intérêt de mettre Apache en reverse proxy.
     
  16. Ron56
    Ron56 WRInaute occasionnel
    Inscrit:
    20 Novembre 2005
    Messages:
    461
    J'aime reçus:
    0
    finalement j'ai opté pour un lighttpd compilé avec mod_cache en frontal qui si il ne peut pas servir la page de son cache transmet la requête a apache

    Ron
     
Chargement...
Similar Threads - Lighttpd apache même Forum Date
monitoring apache2 ? Développement d'un site Web ou d'une appli mobile 28 Octobre 2019
Incohérences stats de crawl et logs apache Crawl et indexation Google, sitemaps 25 Juillet 2019
Renewal letsencrypt plante Apache Administration d'un site Web 12 Avril 2019
Coupure intempestive apache Développement d'un site Web ou d'une appli mobile 14 Mars 2019
Apache et QUIC (http/3) Administration d'un site Web 14 Novembre 2018
Tracer le fonctionnement d'Apache (2.2.15) Administration d'un site Web 23 Avril 2018
Tuto http->https pour apache Administration d'un site Web 9 Mars 2018
Redirection de page avec virtualhost d'apache Développement d'un site Web ou d'une appli mobile 6 Février 2017
Charset apache / php ? Administration d'un site Web 6 Juin 2016
Apache => Ngnix - Réécriture RewriteCond URL Rewriting et .htaccess 1 Février 2016