Сравнение производительности веб-серверов 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
источник
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.