Оговорюсь сразу, поставленная цель — не узнать максимум возможностей системы, а выяснить принципиальную работоспособность современных микрокомпьютеров в качестве полноценных веб-серверов и помочь оценить конкурентноспособность относительно виртуальных хостингов. Поэтому, в данной статье не рассматриваются вопросы оптимизации и изучения предельно допустимой нагрузки. Вместо этого эксперимент проводится на действующих сайтах с реальными посетителями.
Вступление
Вероятно, многие, кто знаком с микрокомпьютерами съедобных семейств (Raspberry, Banana, Orange...), задумывались о расширении круга их использования. Изначально предназначенные для систем типа «умный дом» и робототехники, они становятся всё более быстрыми при сохранении размеров. Малое энергопотребление с увеличением мощности процессоров делает их привлекательными для потенциального использования в роли веб-серверов. Давайте выберем подходящую для этого модель.
Почему Raspberry Pi 2 model B?
Поскольку самое слабое место таких систем с точки зрения , — это процессор, обладающий очень низкой относительной производительностью (о чём чуть дальше), то мы попробуем организовать веб-сервер на бюджетном варианте, но который, тем не менее, сможет оказаться достаточно мощным для наших задач — это Raspberry Pi 2 model B. Он обладает 4-х ядерным процессором, работающим в штатном режиме без охлаждения на 900 Mhz и возможностью менять эту частоту от 700 до 1200 Mhz. Поднимать тактовую частоту мы не будем, лишь заметим, что для «разгона» понадобится радиатор и, возможно, вентилятор. Раз так сложилось, что на сегодняшний день Raspberry Pi 2 model B обладает самым производительным процессором среди «одноклассников», выбираем его для тестирования.
Технические особенности рассматриваемой платформы
Процессор
Процессор у нас необычный, семейства RISC. Вкратце можно сказать, что набор инструкций у такого процессора существенно меньше, чем у «обычных», зато простые команды он выполняет очень быстро. Но для выполнения сложных инструкций таких простых команд надо очень много. Поэтому и тактов уходит больше. Так что если кому показалось, что 4 ядра по 900 Mhz — это более, чем достаточно для вебсервера, то стоит сделать поправку — Broadcom BCM2836 quad core Cortex A7 для нашей задачи окажется не быстрее старенького Pentium 300-400 Mhz. Правда, в 6 раз обгоняя предыдущую одноядерную модель на Raspberry Pi, и в 1.9 раза опережая двухядерного соклассника на Banana Pi M2 (который хоть и рекламируется наличием SATA и гигабитного ethernet, но для веб-сервера из-за своего процессора подходит в значительной мере меньше). Именно по причине неторопливости центрального процессора мы наблюдаем рекордно низкое потребление микрокомпьютеров. По доступным данным, Raspberry Pi потребляет от 2 до 3-х ватт, 4 ватта при пиковой нагрузке, 1 ватт при простое. Что ж, 2-3 ватта (5V, 0.4-0.6А) в среднем для всей системы, за исключением питания носителей информации — это то, за что стоит побороться на поприще корпоративного или домашнего вебхостинга, то, что может сделать его выгодным с экономической точки зрения.
Память
Память используется не самая быстрая, это DDR2, но зато имеется вполне достаточный объём — 1GB. Надо сказать, что это хороший объём для обычных вебсерверов под управлением Linux.
Сетевой интерфейс
100-мегабитный сетевой интерфейс вполне достаточен для передачи данных. Больше нам и не нужно — подсистема хранения информации и процессор просто не справятся с большей нагрузкой.
Хранение информации
Переходим к очень интересному моменту — встроенный картридер позволяет системе загружаться только с него (если только не перенаправить загрузчик...), а это в штатной ситуации ограничивает выбор основного носителя микро SD картой. Радует то, что сегодня они могут быть уже значительного объёма и работать быстро. Хотя недостатки уже налицо — мы вряд ли захотим держать на ней файлы вебсайтов, базы данных, swap и логи, во избежании медленной работы и преждевременного сокращения срока жизни носителя. Для этого у нас будет ещё один носитель на шине USB. Такой подход не только увеличит производительность системы, но и даст преимущество модульности — легко заменить носитель на запасной и делать бэкапы всего образа. Вопрос в том, что именно мы хотим использовать в качестве внешнего носителя — SSD диск, HDD или быструю карту памяти. Здесь каждый решает сам для себя, многое зависит от характера хостируемых сайтов. Следует помнить, что на Raspberry Pi 2 используется стандарт USB 2.0, ограничивающий нашу файловую подсистему в скорости передачи данных.
В данном примере в качестве внешнего устройства мы рассмотрим относительно медленный вариант для записи — это USB-картридер с подключенной полноформатной SD-картой Lexar Professional, позволяющей записывать данные на скорости всего лишь около 15Mb/s при этом подключении. Хотя (в общем случае) нам будет маловажна скорость носителя выше 100 мегабит как для чтения, так и для записи, так как связь с внешним миром ограничена этой цифрой. При применении дисковых подсистем стоит задуматься об их энергопотреблении. Винчестер 2.5" потребляет ~5 ватт и, вероятно, потребует отдельного источника питания. Следует также помнить про специфичную организацию ввода-вывода на Raspberry через USB, очевидно, у нас есть ещё одно узкое место:
Итак, носители для теста:
«Внутренний»: MicoSD 8Gb class 10
«Внешний»: SD 32Gb class 10+ (UHS)
Установка и состав LAMP
Система должна быть простой, но иметь полноценный функционал. Поэтому одно требование — ничего лишнего, но только Apache спрячем за Nginx, благо память позволяет.
Операционная система
На «внутреннем» носителе ставится Minibian с образа 2015-02-18-wheezy-minibian.img.
Это — Debian 7.8 в минимальной комплектации для Raspberry. Оговоримся, в стандартном репозитарии ждут PHP не выше 5.5 и Apache не выше 2.2. Это никакое не досадное ограничение, но для данной статьи полезно проверить возможность использования самых свежих версий. Для того, чтобы установить не входящие в стандартный репозитарий PHP 5.6.x и Apache 2.4.x, пришлось поменять источник для 8-й версии Raspbian, система после apt-get upgrade стала иметь версию 8.0.
Apache
Версия 2.4.10 (Raspbian). Включен gzip, подключены все наиболее часто используемые модули из стандартной поставки, включая mod_rewrite, mod_cache..., не считая тех, что включены по умолчанию.
PHP
5.6.12-0+deb8u1 (cli). Выполняется в Apache как prefork. Есть php-curl, php-gd и другие популярные библиотеки.
MySQL
5.5.44-0+deb8u1 — (Raspbian).
Nginx
Nginx/1.6.2. Nginx отвечает за статику. Включено сжатие gzip.
Напомню, что все логи пишутся на внешний носитель, база данных MySQL там же, swap не отключен, но пустой на всё время тестирования.
В качестве вспомогательных утилит использую PhpMyAdmin, htop, iostat и webmin. Установлен exim4, но только для отправки сообщений из форм. Как видно, наш сервер вполне современен и функционален. Любителей панели управления VESTA разочарую — к сожалению, производитель не поддерживает ARM процессоры и не собирается этого делать в ближайшее время. Поэтому webmin.
Тестирование
Я сразу не собирался делать никаких синтетических тестов, т. к. они скорее из области очень далёкой теории. На практике же всё сильно зависит от характера хостируемых сайтов, от распределения нагрузки по времени, от канала связи, количества просмотров, времени посетителей на сайте..., а также от настроек. Другими словами, предлагаю посмотреть, что получается на самом деле, на действующих сайтах.
Тестируемые вебсайты не основаны на какой-либо CMS, но используют отображение картинок из базы данных на динамических (PHP) страницах, поэтому может быть довольно интенсивная нагрузка на MySQL. А вот AJAX-соединений нет вовсе. Поскольку наш пока не претендует на профессиональный, то посчитал достаточным для теста размещение на нём 16-ти действующих сайтов с невысокой посещаемостью, из которых около пяти — около 100-200 человек в сутки, остальные — не более 50-ти посетителей за это же время. Всего — около 800-900 человек в день, что сравнимо по допустимой нагрузке с недорогим виртуальным . Половина посетителей приходится на вечер, основные посещения случаются в 20-22 часа (~300 человек за два часа, в среднем 4 просмотра = 10 просмотров в минуту по ~700 кб каждый = 116 килобайт трафика в секунду). Это время обозначим «час пик» и в это же время проведём тестирование. Тестов будет всего два вида — оценка производительности с помощью сторонних сервисов и отчёт утилит htop, iostat по реальной работе.
1. Время генерации и загрузки пользователем страниц в «часы пик»
Используем всего два основных параметра — время генерации страницы и время загрузки страницы, для двух типов страниц — «тяжёлых» (тяжёлой для процессора, т. к. много картинок из MySQL, долгая генерация) и «лёгких» (обычная динамическая страница PHP). Повторим каждый тест 10 раз, чтобы уменьшить вероятность случайного результата, а также будем использовать разные сервисы.
Напомню про географию тестирующих серверов и про их возможную загруженность. Поэтому абсолютные результаты могут разниться сильно, это нормально. Повторные замеры делал с перерывами в 5-10 минут, чтобы попадать в разное время загруженности сервисов. Канал тестируемого Raspberry — гигабитная оптика, география — Сибирь, 150 гарантированных мегабит до Москвы. Для того, чтобы убедиться в способности сервера обслуживать несколько одновременных соединений, тестирование запускал одновременно на следующих сайтах-сервисах:
`Лёгкая` страница (547 кб, без обращений к MySQL)
PingDom.com, Швеция
Время загрузки страницы (46 запросов): минимум — 925 мс, максимум — 1124 мс, средняя — 955 мс.
Google PageSpeed Insights
Нареканий по скорости нет.
Sitespeed.ru
Общее время загрузки страницы 3.9-4.2, среднее 4.0. Время генерации страницы от 139 до 157, среднее 145 мс. Вот почему у Гугла нареканий нет — попадаем в допустимые им 200 мс.
`Тяжёлая` страница (843 кб, включая 38 картинок по 10-15 кб из MySQL)
PingDom.com, Швеция
Время загрузки страницы (85 запросов): минимум — 946 мс, максимум — 1001 мс, средняя — 973 мс.
Google PageSpeed Insights
Нареканий по скорости нет.
Sitespeed.ru
Общее время загрузки страницы 5.3-4.2, среднее 4.0. Время генерации страницы от 158 до 169, среднее 162 мс.
2. Отчёт утилиты htop
Как и ожидалось, Htop показал, что основной потребитель процессорного времени — это процессы mysql. Они «скушали» 98 минут из последних суток процессорного времени. Что неудивительно — частые и «тяжёлые» запросы к базе у нас предполагались изначально. Будь картинки в кэше nginx, мы бы имели прирост в производительности, но тест тем и интересен, что с запасом моделирует повышенную нагрузку на MySQL, характерную, кстати, для большинства CMS.
3. Отчёт утилиты iostat
Эта утилита показала средние скорости чтения и записи на носители:
1. «Внутренний» носитель (система) — 0.87 кб / с чтение в среднем, 15,5 кб / с запись в среднем (скорее всего из-за кеширования nginx, есть что доработать в конфигурации).
2. «Внешний» носитель (сайты, логи, базы данных) — 2.4 кб / с чтение и 3 кб / с запись (тут всё нормально, чтение закешировано, пишутся логи).
4. Распределение ресурсов процессора
Распределение процессорного времени по htop, выборка — ровно двое суток работы (обслужено ~1600 уникальных посетителей по данным Яндекс-метрики):
mysql 6.8%
htop 1.8%
nginx 0.75%
apache2 <0.3%
Почти всё остальное время процессор отдыхал.
Как результат, имеем большой запас по свободному процессорному времени, запас по поднятию частоты процессора, запас по скорости работы носителей информации на запись. Доступно множество оптимизаций в настройке как серверных программ (вынести кеш nginx на отдельный носитель, например), так и самих сайтов. Всё вместе — неплохой потенциал для увеличения общей производительности.
Итог
Нашему виртуальному посетителю понравилась скорость работы вебсервера на микрокомпьютере, несмотря на то, что были другие одновременные визиты. Таким образом, несмотря на узкие места (USB и процессор), имеем вполне очевидный вывод — полноценный вебсервер на Raspberry Pi 2 model B реален. Как по программному обеспечению, так и по техническим параметрам. Исходя из совсем невысокой загруженности в рассматриваемом варианте, предположу, что он сможет оперативно обслуживать как минимум пару-тройку тысяч посетителей среднестатистического сайта (сайтов ?) в сутки.
Многопроцессорность помогает быстрее справиться с запросами, памяти достаточно для кеширования, передача данных через USB удовлетворительная, так что сервер-малыш может не только позволить сэкономить на электричестве, но и осуществлять быструю (плюс недорогую!) замену вышедшего из строя оборудования. Такая система может окупать себя при использовании в сети предприятия в качестве корпоративного сервера (сервер базы данных, веб-сервер, сервер резервного копирования, файлообменник) по сравнению с другими популярными решениями. И уж наверняка быть альтернативой виртуальному в умелых руках. Скажем, на бюджетном источнике бесперебойного питания микрокомпьютер в паре с роутером может работать часами, так что вопрос кратковременного (и не очень) отключения электричества может быть нивелирован в домашних условиях, если на узле провайдера также стоят UPS. А ещё можно управлять электричеством, давать команды различным устройствам, подключить видеокамеру и различные датчики…
Пробуйте, экспериментируйте, микрокомпьютеры — это не только недорого, но и до приятного тихо…
Автор: Dorco
