4 Экспериментальное исследование пак

Для экспериментальной оценки эффективности разработанного ПАК было проведено сравнение предложенного решения Varnish + lighttpd + PHP-FPM с наиболее распростарнённым практическим решением для Web-серверов малых компаний Apache2 Prefork + mod_php.

Для тестирования использовался сервер AMD Athlon X2 5600+ 4 GB DDR2 2×400 GB HDD с Linux Debian в минимальной установке. Весё ПО устанавливалось стандартным образом - через apt-get, PHP и Apache ставились в минимальном режиме. Для обоих веб-серверов был установлен таймаут в 300 секунд. Сетевые настройки в sysctl.conf были изменены так же, как показано в листинге 3.2. В качестве ресурса использовался блог Moscquito, который работает без MySQL.

Количество открытых файлов увеличиваем следующим образом:

• ulimit -s unlimited;

• ulimit -n 1024000.

Процессы в PHP-FPM были привязаны к TCP-сокету, создано два пула по 4 процесса в каждом в статичном режиме.

Для lighttpd ввели ограничение по 10240 коннектов на каждый сервер, php подключен как upstream:

Для Apache отключен Keepalive, а MaxClients и ServerLimit установлены в 10240.

Была воссоздана ситуация сайта под DDOS-атакой, когда сайт обслуживал 5000 легальных пользователей, а 20000 ботов постоянно обращались к главной странице сайта.

Импровизированную DDOS-атаку легко можно при помощи Apache Bench (далее ab) и Siege - утилит для нагрузочного тестирования веб-серверов.

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

Siege – это утилита для нагрузочного тестирования веб-серверов. Она была создана для того чтоб дать разработчикам возможность проверить ресурсоёмкость своего кода в условиях, максимально приближенных к реальным. Так же Siege может имитировать обращения к сайту сразу нескольких пользователей. Это позволяет держать сервер как бы «под осадой» долгое время. Количество запросов, произведённых при «осаде», рассчитывается из общего количества пользователей и количества их обращений к серверу. Например 20 пользователей, обратившись по 50 раз, создают в общей сложности 1000 запросов. Результат, выводимый программой после тестирования, включает в себя время затраченное на проверку, общее количество переданной информации ( включая заголовки ), среднее время ответа сервера, его пропускную способность и число запросов на которые пришёл ответ с кодом 200. Эти данные формируются и выдаются при каждой проверке. Подробно они описываются ниже. Siege имеет 3 основных модели работы – режим регрессионного тестирования, режим имитации Интернета и режим грубой силы. Программа считывает порцию ссылок из конфигурационного файла и обращается к ним по очереди ( режим регрессионного тестирования ) или случайно ( имитация интернета ). Или же пользователь может указать один единственный адрес к которому будут производиться все обращения – режим грубой силы.

Тестирование заняло один час и запись о доступности сайта логгировалась с помощью ab. Были запущены две команды:

• while true; do ab -r -t 300 -n 20000 -c 20000 192.168.0.2/ >> lighttpd.log; sleep 5; done;

• while true; do siege -i -f urllist.txt -c 5000 -b -t1M ; sleep 5; done.

Далее представлены графики числа процессов, использования памяти, переключений между процессами, утилизации CPU.

Рисунок 4.1 - График числа процессов

Как видно число процессов изменялось только во время работы Apache, а lighttpd и PHP-FPM статичны. На графике памяти видно, что памяти Apache потребляет больше. График утилизации CPU также говорит о преимуществе lighttpd.

Рисунок 4.2 - График использования памяти

Рисунок 4.3 - График переключений между процессами

Рисунок 4.4 - График утилизации CPU

Анализ логов показывает, что связка Varnish + lighttpd +PHP-FPM работает стабильнее, что видно в листинге 4.1.

# grep -c Failed lighttpd.log

38

# grep Failed lighttpd.log | grep -v 'Failed requests: 0'

Failed requests: 10629

Листинг 4.1 – Лог-файл lighttpd

То есть, за час работы связка Varnish + lighttpd +PHP-FPM успела пройти 38 итераций и завалить только одну из них с 10629 ошибочных запросов. Это было связано с недоступностью PHP в результате всплеска запросов siege к одной странице.

Анализ логов Apache представлен в листинге 4.2.

# grep -c Failed apache.log

23

# grep Failed apache.log | grep -v 'Failed requests: 0'

Failed requests: 8730

Failed requests: 2124

Failed requests: 10539

Failed requests: 7599

Failed requests: 6027

Failed requests: 1986

Failed requests: 7578

Failed requests: 270

Failed requests: 9819

Failed requests: 60

Failed requests: 9369

Failed requests: 8193

Failed requests: 10248

Failed requests: 684

Failed requests: 7968

Листинг 4.2 – Лог-файл Apache

Результаты Apache, даже если вычеркнуть 2 «удачных» попадания siege, оказались гораздо хуже (13 заваленных итераций), причём за отведенное время было выполнено меньше запросов (только 23 итерации).

Таким образом, по результатам тестирования связка Varnish + lighttpd +PHP-FPM показала свою эффективность и преимущество перед основными конкурентами.