Сравнение производительности веб-серверов RPi 3: Apache, Nginx и Lighttpd

11

Кто-нибудь проводил реальное сравнение производительности на RPi 3 на популярных веб-серверах:

  1. Apache2 - самый распространенный сервер
  2. Nginx - сервер, который претендует на лучшую производительность
  3. Lighttpd - самый легкий сервер
  4. Или пакет, о котором я не слышал

Что-то вроде этого 4-летнего поста для RPi 2 . Следуя совету в этом посте, я расширил свои исследования в более общем плане и нашел эту статью , но считаю ее несколько подозрительной, поскольку это хостинговая компания, и мне нужен ответ, адаптированный к аппаратному обеспечению RPi 3.

web-server apache-httpd lighttpd Сандор Доса
источник
4
Не по теме: я не понимаю, почему кто-то отказывается голосовать за вопрос, не давая подсказки, что с ним не так.
Джо Платано
2
Я не пассивно агрессивен и не ищу, чтобы вы удалили свой вопрос. Я был слишком занят в то время, чтобы оставить комментарий, объясняющий мое отрицательное мнение. Первая проблема заключается в том, что вы преждевременно оптимизируете. Вы не четко определили вариант использования (какие модули / функциональные возможности будут необходимы и т. Д.). Я мог бы продолжить еще несколько абзацев, но я позволю вашим собственным словам говорить самим за себя: «Если Nginx будет делать то, что мне нужно, то это, кажется, лучше из коробки (или из квартиры) -получить) решение собрать перед началом настройки производительности ».
Стив Робиллард
2
Если Nginx будет делать то, что мне нужно (так что вы можете исключить один или несколько серверов в зависимости от требований; следовательно, ваш вопрос не будет иметь значения. Вы ставите корзину перед лошадью. Получите работающую систему, а потом беспокойтесь о настройка производительности. Во-вторых, ответ на ваш вопрос будет зависеть от конкретной рабочей нагрузки, будет ли использование БД считано тяжелым или интенсивно записано? Будет ли система привязана к БД или к вводу-выводу? Если БД не требует какой-либо настройки вашего веб-сервера чтобы помочь.
Стив Робиллард
2
Снова процитирую, что «возможность обслуживать их всех без огромных задержек очень важна». Сколько слишком много лагов? и, наконец, «я видел другие посты о том, как настроить Apache и Nginx для повышения производительности, но это похоже на большую работу только для создания тестового конфигурации для сравнения параметров». Разве это не то, что вы просите кого-то сделать для вас в этом вопросе? Без пользы реальных данных о трафике или полной спецификации проблемы. Без этих вещей они могут также консультироваться с хрустальным шаром.
Стив Робиллард
Принимая во внимание нехватку памяти и ограничения процессора PI, разве что-то вроде установки на основе узла вместе с Express на неблокирующем сервере событий, управляемых событиями ввода-вывода, будет более полезным? Опять же, зависит от вашего варианта использования. Вы обслуживаете статические файлы или динамические файлы. Это ваша панорама, чтобы иметь веб-приложение или веб-сайт.
CoderX

Ответы:

5

Это должен быть комментарий, но это немного долго.

Хотя я (пока) не тестировал различные веб-серверы на своем Pi, ранее я проводил множество тестов на веб-серверах, работающих на аппаратном обеспечении сервера x86. Что я знаю оттуда:

  1. большинство людей запутываются в разнице между производительностью и емкостью - вы увидите множество сообщений, в которых утверждается, что nginx работает быстрее, чем (pre-fork) apache, но это не так , за исключением случаев высокой нагрузки. Nginx (и лёгкий) оба намного лучше в емкости. И это на самом тривиальном уровне анализа.

  2. Мало кто обслуживает исключительно статический контент с помощью своих веб-серверов (в этом случае tux и G-Wan покидают серверы, о которых вы упомянули в своей пыли). Профиль производительности сильно зависит от технологии логического уровня и ее интеграции с веб-сервером.

  3. Производительность (и емкость) зависит от всего, что работает на устройстве.

Существует множество функций сервера центра обработки данных, без которых очень легко обойтись, если у вас есть надлежащая избыточность на уровне кластера (двойной блок питания, двойная сеть, удаленная консоль ...), однако Raspberry PI не имеет смысла как веб обслуживание платформы из-за медленного дискового ввода-вывода - вам действительно нужно что-то с SATA, [i] SCSI, AOE или бесконечным подключением к вашему хранилищу. Pi не имеет интерфейса SATA, имеет только один порт Ethernet, и я не знаю ни одного интерфейса инфинити и SCSI.

(Существуют небольшие одноплатные компьютеры, которые являются более разумным выбором для наращивания возможностей веб-сервера - и кластер из них может иметь хороший экономический смысл, но в таком сценарии вы рассматриваете несколько узлов с многоуровневой возможностью терминации SSL, HTTP кеширование, веб-обслуживание, логика приложений и управление данными).

Вопрос о самом быстроме трудно определить, он отличается для каждого случая и на него невозможно ответить.

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

symcbean
источник
Хорошие моменты всем. Боюсь, этот проект снова обанкротился.
Сандор Доса
2

Боюсь, вам нужно выяснить это самостоятельно. Когда у меня возник этот вопрос для моего RPi2, я наткнулся на Siege и httperf . Я следовал этому примеру для запуска тестов - просто вместо простых HTML-страниц я запрашивал php-файлы. Там производительность веб-сервера также зависит от модулей CGI, которые вы выберете. Простой ванильный lighttpd может быть быстрее, чем ванильный Apache. Если вы выбираете / настраиваете CGI некорректно, это может измениться, и Apache может превзойти Lighty.

Джо Платано
источник
Боюсь, ты прав. Я начну пытаться разобраться с методом тестирования и доложу.
Сандор Доса
@SandorDosa, держите меня в курсе, пожалуйста
Джо Платано
2

Я выбрал опцию lighttpd по следующим причинам:

  1. легкий
  2. один из самых простых в установке
  3. работает на моем RPi2 в течение последних двух лет без проблем (24x7)
  4. нужен хороший и простой в использовании в качестве моего тестового устройства

Я использую это как:

  1. следить за температурой процессора в моей системе, температурой окружающей среды / комнатной температуры и графиком влажности
  2. FTP-сервер для обмена файлами с моими деловыми партнерами и предотвращения хранения конфиденциальных данных на сторонних бесплатных почтовых серверах
  3. Множество веб-виджетов для проверки индекса рынка, таких как форекс, облигации, акции и т. Д.
  4. проверить HTML-код
  5. запустите скрипт, который я сделал для проверки почты, так как у меня много почтовых учетных записей, избегая блокировок геотегирования
  6. вести простой блог (Nibble blog)
  7. работать как приманка, чтобы обнаружить (и заблокировать) хакеров на моем проводе

просто назвать несколько применений.

JohnBR
источник