concept de proxy frontal apache + lighttpd

Question

Pour alléger la charge d'Apache, les gens suggèrent souvent d'utiliser lighttpd pour diffuser du contenu statique.

par exemple. http://www.linux.com/feature/51673

Dans cette configuration, Apache transmet les requêtes de contenu statique à lighttpd via mod_proxy, tout en servant les requêtes dynamiques lui-même.

Ma question est la suivante: comment cela réduit-il la charge du serveur? Étant donné que vous avez toujours un processus apache généré pour chaque demande qui arrive, quel en est l'impact sur la charge? D'après ce que je peux voir, la taille du processus Apache qui envoie sa requête par le biais de lighttpd est aussi grande que si elle servait le fichier elle-même.

Answer 1

Exécuter Lighttpd derrière Apache pour servir des fichiers statiques me semble certainement plus malin. Apache doit encore décompresser les paquets HTTP et analyser la requête via son arborescence d'analyse, envoyer des requêtes de proxy, puis Lighttpd doit décompacter à nouveau, décompresser le système de fichiers et renvoyer les fichiers via Apache. Je n'ai jamais entendu parler de personnes utilisant une configuration de ce type en production.

Ce que vous verrez, est-ce que les gens utilisent un serveur Web léger tel que Nginx en tant que interface serveur pour servir des fichiers statiques et des URL dynamiques de proxy à Apache. Ou bien, vous pouvez exécuter Varnish ou Squid comme interface frontale de proxy inverse pour la mise en cache, afin que tous vos fichiers statiques à fort trafic (images, CSS, etc.) et toutes les pages dynamiques que vous souhaitons envoyer des en-têtes respectant le cache pour) sont servies en mémoire.

Apache peut également être optimisé pour servir des fichiers statiques. Ainsi, souvent, lorsque des gens se plaignent d’Apache, ils ne savent vraiment pas comment le configurer. Ils ont uniquement utilisé le MPM prefork (vs thread ou worker) et ont activé toutes sortes de modules (généralement, ils fonctionnent à partir du paquet Apache de la distribution Linux d'une cuisine qui construit tout en tant que modules et qui permet par défaut d'activer 10-20 modules ou plus). Réglez Apache en désactivant les modules inutiles / des fonctionnalités stupides telles que la prise en charge de .htaccess (qui permet à Apache d'analyser le système de fichiers à chaque demande!) En premier. (Vous pouvez également exécuter deux instances d’Apache, avec une interface Apache "légère" qui sert de proxy à un serveur Apache "lourd" pour les requêtes dynamiques ... peut-être que votre interface est threadée, mais que votre backend est préfork car vous devez exécuter des threads. -des modules externes tels que mod_php.)

Re:

  

Depuis que vous avez encore un processus apache   engendré pour chaque demande qui vient   dans, comment cela impact positif   la charge? D'après ce que je peux voir la taille   du processus Apache proxy son   demande via lighttpd est aussi grande   comme ce serait s'il servait la   fichier lui-même.

Si vous créez des processus à chaque demande, cela signifie que vous utilisez le MPM prefork. Gardez à l'esprit que lorsque le système d'exploitation signale l'utilisation de la mémoire pour chacun de ces processus, une grande partie de la mémoire n'est pas câblée, beaucoup de ces processus sont inactifs. Et lorsque vous parlez de rapidité, l'analyse des requêtes et les branches de code interne pour une requête donnée vous préoccupent plus (que le serveur effectue-t-il?), Plutôt que l'utilisation de la mémoire signalée par le système d'exploitation.

Par exemple, si vous activez quelque chose comme mod_php, chacun de ces processus de travail augmentera instantanément d'environ 20 à 40 millions (en fonction de ce qui est activé dans votre interpréteur PHP), mais cela ne signifie pas qu'Apache utilise cette mémoire sur les demandes statiques. Bien sûr, si vous optimisez votre serveur pour obtenir un maximum de simultanéité sur de petits fichiers statiques, l'activation de mod_php serait tout de même très mauvaise, vous ne pourrez donc pas intégrer autant de processus de pré-fork dans la RAM.

Je pourrais probablement proposer une "configuration de cauchemar". pour Apache, cela rendrait le traitement des fichiers statiques plus lent que le traitement proxy de ces demandes vers un serveur Lighttpd, mais impliquerait l'activation de fonctionnalités coûteuses telles que .htaccess dans Apache qui sont désactivées dans Lighttpd. vraiment être juste.

Answer 2

1. Si vous avez toujours le pouvoir de servir du contenu statique et dynamique à partir de la même machine (comme dans votre article cité ), je ne vois vraiment aucun intérêt à cette configuration.
2. Peut-être que cela réduira la charge d’Apache, car il n’aura pas à effectuer d’E / S sur le disque, mais cela augmentera la charge de Lighttpd sur la même machine et réduira ainsi la charge disponible sur apache ...
3. Peut-être que l'accès Lighttpd IO est plus léger que celui d'Apache 1.3, mais pourquoi ne pas basculer complètement vers Apache 2 ou Lighttpd? Et si les performances commencent vraiment à être nul, hébergez les fichiers statiques sur une autre machine (media.votredomaine.com).

La petite introduction à la création d’une installation performante se trouve ici: Déploiement de Django - > faites défiler jusqu'à Mise à l'échelle d'une page avant la fin

Answer 3

Je ne connais pas grand chose au fonctionnement interne d’Apache, mais une explication que j’ai vue concerne la pression sur la mémoire. En bref, Apache tente d'équilibrer la mémoire utilisée pour la mise en cache et pour les pages dynamiques. mais se termine généralement avec trop de cache et trop peu pour les applications. Si vous les séparez en différents processus, chacun optimisera le type de charge.

Actuellement, je me sers de nginx en tant que serveur frontal. C'est vraiment rapide et léger, et spécifiquement conçu comme un proxy frontal; mais sert également des fichiers statiques. En fait, étant donné qu'il peut également appeler des processus FastCGI, vous pouvez vous débarrasser d'Apache tout en bénéficiant des avantages des processus de fichier / application fractionnés. (et il existe une magie mémorisée supplémentaire ça a l'air absolument génial)

(Oui, lighttpd peut également être utilisé comme interface avec Apache et / ou FastCGI)

Answer 4

Vous n'avez pas créé de processus Apache pour chaque requête - les fichiers statiques (images, etc.) sont récupérés directement par lighttpd.

Answer 5

Utilisez Apache MPM Worker fastcgi pour réduire l’utilisation de la mémoire du serveur. MPM worker gère mieux le contenu statique que Prefork et est presque à égalité avec lighttpd en ce qui concerne le contenu statique.