Lighttpd et apache sur le même serveur I

Ron56 · 26 Juin 2008

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

moktoipas · 26 Juin 2008

Re: [Article] Apache pour le dynamique, lighty pour le stati

Ron56 a dit:
Si vous avez des question ...

Ca sert a quoi ?

Ron56 · 26 Juin 2008

Re: [Article] Apache pour le dynamique, lighty pour le stati

moktoipas a dit:
Ron56 a dit:

Si vous avez des question ...

Cliquez pour agrandir...

Ca sert a quoi ?

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

moktoipas · 26 Juin 2008

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

Ron56 · 26 Juin 2008

Je vais voir la charge ce soir durant le pic, jvous dirais ça

Ron

moktoipas · 26 Juin 2008

Ouki ^^
Faudra la comparer a la charge d'avant bien sur

Bool · 26 Juin 2008

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.

Ron56 · 26 Juin 2008

Et a propos de ca : http://www.linux.com.cn/modcache/

Bool tu peux expliquer un peu plus en détail ta solution ?

Bool · 26 Juin 2008

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

Ron56 · 26 Juin 2008

Bool a dit:
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".

Bon jvais tenté un apache leger devant et un lourd derrière ...

Bool · 26 Juin 2008

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.

Ron56 · 26 Juin 2008

Bool a dit:
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.

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/ ?

Bool · 26 Juin 2008

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 ?

Ron56 · 26 Juin 2008

Bool a dit:
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 ?

Jvais essayer modcache

Bool · 26 Juin 2008

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.

Ron56 · 26 Juin 2008

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