Подтвердить что ты не робот

Apache или lighttpd

Для разработки я использую локальный стек LAMP, для производства я использую MediaTemple Django Container (который я люблю BTW). Контейнер MT использует lighthttpd. Честно говоря, у меня никогда не было другого опыта. Я всегда использовал Apache. Я читал:

Вот вопросы:

  • Каковы сильные стороны друг друга?
  • Пригодится ли мне использовать lighthttpd в моей настройке dev?
  • Что с использованием обоих? В статье Linux.com говорится об использовании lighttpd с Apache.
4b9b3361

Ответ 1

Способ взаимодействия между веб-сервером и Django может иметь даже большее влияние на производительность, чем выбор программного обеспечения веб-сервера. Например, mod_python, как известно, тяжел в ОЗУ.

Этот вопрос и его ответы обсуждают другие варианты веб-сервера.

Я не буду беспокоиться о проблемах совместимости с клиентским программным обеспечением (см. комментарий MarkR). У меня не было таких проблем при обслуживании Django с использованием lighttpd и FastCGI. Я бы хотел увидеть разнообразную экосистему как серверного, так и клиентского программного обеспечения. Наличие хорошего стандарта лучше, чем де-факто продукт от одного поставщика.

Ответ 2

Для чисто статических веб-страниц (.gif,.css и т.д.) с n HTTP-запросами с разных IP-адресов: 1. Apache: запускает n процессов (с mod_perl, mod_php в памяти) 2. lighttpd: запускает 1 процесс и 1 поток (вы можете назначить m потоков перед его запуском)

Для чисто динамических веб-страниц (.php,.pl) с n HTTP-запросами с разных IP-адресов: 1. Apache: запускает n процессов (с mod_perl, mod_php в памяти) 2. lighttpd: Выполняет 1 процесс lighttpd благодаря асинхронному вводу/выводу и запускает быстрые процессы cgi для каждого языка script.

Lighttpd потребляет гораздо меньше памяти. YouTube был большим пользователем lighttpd, пока он не был приобретен Google. Перейдите на домашнюю страницу для получения дополнительной информации.

P.S. В моей предыдущей компании мы использовали оба с балансировщиком нагрузки для распространения http-трафика в соответствии с его суффиксами url. Почему не полностью lighttpd? По старым причинам.

Ответ 3

Преимущество обоих: Apache более мощный и расширяемый (бесполезный, если вам не нужна эта мощность, но в любом случае...), а lighttpd быстрее при статическом контенте. Идея состоит в том, чтобы разбивать ваш сайт на статический контент (css, js, images и т.д.) И динамический код, который протекает через Apache.

Я не говорю, что вы не можете много сделать с помощью lighttpd самостоятельно. Вы можете и люди.

Если вы используете lighttpd исключительно на своем производственном сервере, я бы серьезно подумал о том, чтобы отразить это на ваших серверах разработки и промежуточного уровня, чтобы вы точно знали, чего ожидать перед развертыванием.

Ответ 4

Ответ зависит от целей ваших проектов. Если это будет крупномасштабный сайт, где время безотказной работы имеет решающее значение, а нагрузка - с помощью lighttpd; он потрясает удивительно. Единственным недостатком является то, что изначально вы должны быть в большей степени. Большинство хостов не поддержат это, и он действительно платит, чтобы узнать, что вы делаете с помощью lighttpd.

Если это сайт для вашей матери, который получит несколько тысяч посетителей в месяц, apache будет работать лучше. Она сможет переместиться на новый хост намного проще и легче найти поддержку.

Ответ 5

Использовать стандартный веб-сервер. Apache используется на 50% веб-сайтов (Netcraft), поэтому, если вы используете Apache, веб-браузеры людей, пауки, прокси-серверы и т.д., в значительной степени гарантированно работают с вашим сайтом (его веб-сервер в любом случае).

Lighthttpd используется на 1,5% веб-сайтов (Netcraft), поэтому гораздо менее вероятно, что люди будут тестировать свои приложения с помощью он.

Любая разница в производительности может не иметь значения при производстве; сервер Apache, вероятно, может обслуживать статические запросы с гораздо большей пропускной способностью, чем у вас, на самом медленном оборудовании, которое вы, вероятно, будете развертывать в процессе производства.