Apache ou lighttpd [fermé]

Question

Pour le développement, j'utilise une pile LAMP locale; pour la production, j'utilise Le conteneur Django de MediaTemple (dont j'aime BTW). Le conteneur de MT utilise lighthttpd. Honnêtement, je n'ai jamais eu d'autre expérience avec ça. J'ai toujours utilisé Apache. Je lis un peu:

• Onlamp
• TextDrive
• Linux.com

Voici des questions:

• Quels sont les points forts de l’un sur l’autre?
• Est-ce que je serais avantagé d'utiliser lighthttpd sur ma configuration de développeur?
• Qu'est-ce qui se passe avec les deux? L'article de Linux.com parle de l'utilisation de lighttpd avec Apache.

Answer 1

La manière dont vous établissez une interface entre le serveur Web et Django peut avoir un impact plus important sur les performances que le choix du logiciel de serveur Web. Par exemple, on sait que mod_python est lourd en RAM.

Cette question et ses réponses traitent également d'autres options de serveur Web.

Les problèmes de compatibilité avec les logiciels clients ne me préoccupent pas (voir le commentaire de MarkR ). . Je n'ai eu aucun problème de ce type lorsque je sers Django avec lighttpd et FastCGI. J'aimerais voir un écosystème diversifié de logiciels serveur et client. Avoir un bon niveau est mieux qu’un produit de facto provenant d’un fournisseur unique.

Answer 2

L'avantage des deux: Apache est plus puissant et plus extensible (inutile si vous n'avez pas besoin de ce pouvoir, mais quand même ...) et lighttpd est plus rapide au contenu statique. L’idée est de diviser votre site en contenu statique (css, js, images, etc.) et en code dynamique passant par Apache.

Je ne dis pas que vous ne pouvez pas faire grand chose avec lighttpd seul. Vous pouvez et les gens le font.

Si vous utilisez lighttpd exclusivement sur votre serveur de production, nous envisagerions sérieusement de le refléter sur vos serveurs de développement et de stockage intermédiaire afin que vous sachiez exactement à quoi vous attendre avant de déployer.

Answer 3

Pour les pages Web purement statiques (.gif, .css, etc.) avec n requêtes http à partir d'adresses IP distinctes: 1. Apache: exécute n processus (avec mod_perl, mod_php en mémoire) 2. lighttpd: exécute 1 processus et 1 threads (vous pouvez assigner m threads avant de le lancer)

Pour les pages Web purement dynamiques (.php, .pl) avec n requêtes http à partir d'adresses IP distinctes: 1. Apache: exécute n processus (avec mod_perl, mod_php en mémoire) 2. lighttpd: exécute un processus lighttpd grâce à une entrée / sortie asynchrone et exécute m processus fast-cgi pour chaque langage de script.

Lighttpd consomme beaucoup moins de mémoire. YouTube était un grand utilisateur de lighttpd jusqu'à son acquisition par Google. Accédez à sa page d'accueil pour plus d'informations.

P.S. Dans mon entreprise précédente, nous utilisions les deux avec un équilibreur de charge pour répartir le trafic http en fonction de ses suffixes url. Pourquoi ne pas complètement lighttpd? Pour des raisons historiques.

Answer 4

La réponse dépend des objectifs de vos projets. S'il s'agit d'un site à grande échelle, la disponibilité est essentielle et la charge élevée avec lighttpd; ça pèse étonnamment. Le seul inconvénient est que vous devez être plus actif au début. La plupart des hôtes ne le supporteront pas et il est très utile de savoir ce que vous faites avec lighttpd.

Si votre site Web contient quelques milliers de visiteurs par mois, Apache fonctionnera mieux. Elle sera en mesure de passer à un nouvel hôte beaucoup plus facilement et le support est plus facile à trouver.

Answer 5

Utilisez un serveur Web standard. Apache est utilisé par 50% des sites Web ( Netcraft ). Par conséquent, si vous utilisez Apache, les navigateurs Web, les araignées, les mandataires, etc., fonctionneront avec votre site (son serveur Web de toute façon).

Lighthttpd est utilisé par 1,5% des sites Web ( Netcraft ), il est donc beaucoup moins probable que les gens testent leurs applications avec.

Toute différence de performance n’aura probablement aucune importance dans la production; un serveur Apache peut probablement traiter des demandes statiques avec une bande passante beaucoup plus grande que celle que vous avez, sur les matériels les plus lents que vous êtes susceptible de déployer en production.