Лекция
Привет, Вы узнаете о том , что такое варианты настройки mpm для apache, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое варианты настройки mpm для apache, mpm-prefork, mpm-worker, mod_php, php-fpm, nginx reverse proxy, php настройка , настоятельно рекомендую прочитать все из категории Выполнение скриптов на стороне сервера PHP (LAMP) NodeJS (Backend) .
Мне не доводилось пока участвовать в высоконагруженных проектах, поэтому было проведено небольшое исследование материалов в сети. Из блога в блог кочует утверждение, что необходимо отказаться от использования Apache в пользу Nginx. Это утверждение мне показалось странным, учитывая историю проекта Apache и сообщество разработчиков вокруг него. Неужели разработчики Apache не могут решить проблему ругаемого везде режима prefork? Так ли это на самом деле я и решил выяснить. О результатах читайте под катом.
Подготовка
Изучив тему более детально, выяснялось, что помимо MPM (Multi-Processing Module) prefork у апача также существуют модули
mpm-worker и mpm-event, которые в одном программном потоке обрабатывают запросы от нескольких пользователей. Модули mpm-event и
mpm-prefork связываются с php через fastcgi. Сравнить их работу c nginx и было решено.
Первым делом я решил посмотреть как поведет себя Apache в режиме prefork при большом количестве запросов. Была запущена утилита siege с 40 потоками. Apache создал множество процессов и логи заполнились сообщениями о переполнении памяти. После чего сервер стал недоступен и пришлось делать terminate для данного инстанса, так как на reboot дождаться реакции в течении 5 минут так и не удалось. Был создан новый инстанс, к которому был подключен старый ebs. В итоге опытным путем было установлено, что на EC2 MicroInstance с ее объемом памяти в 630МБ оптимальными являются следующие настройки:
StartServers 3
MinSpareServers 3
MaxSpareServers 7
MaxClients 27
MaxRequestsPerChild 3000
Теперь можно было нагружать сервер, не боясь потерять его управление.
Было решено протестировать следующие конфигурации:
В процессе тестирования пришла мысль, что ничто не мешает apache в режиме mpm-prefork работать с php-fpm и данная конфигурация также была добавлена в тесты.
О том, как установить используемые в этой статье конфигурации я рассказывать не буду, вы без труда можете найти данную информацию на просторах интеренета. Отмечу лишь, что во многих howto дублируется одна и та же ошибка для связки mpm-worker или mpm-event с php, а именно: в командах пакетного менеджера указано устанавливать пакет php5, на самом деле необходимо устанавливать пакет php5-cgi.
Меня интересовало прежде всего, какое количество запросов сможет выдержать вэбсервер. Поэтому я решил использовать для тестов утилиту siege. Поэксперементировав с JMeter, я пришел к выводу, что он больше подходит для выяснения времени реакции на те или иные события. Таким образом, основной интересующий меня параметр из вывода результатов утилиты siege был Availablility. Исходя из этого, были подобраны параметры утилиты siege, чтобы Availability была менее 100%, но не слишком мала. На всех тестах использовалось количество потоков 20 (-c) количество повторений 20 (-r) режим benchmark (-b).
Для обработки результатов тестов был создан Excel файл, в таблицы которого вводились результаты выводимые утилитой siege. По результатам пяти тестов находится среднее арифметическое и среднеквадратичная погрешность среднего арифметического. Строится диаграмма Availability для разных конфигураций.
Был написан простенький скрипт, который выполняет необходимое количество тестов и обрабатывает результаты вывода siege для копипасты в Excel:
#!/bin/bash
n=1
touch tmp.out
while [ $n -le $2 ]
do
siege -b -q -c 20 -r 20 -i -f $1 >> tmp.out 2>&1
sleep 60
n=$(( n+1 ))
done
cat tmp.out | sed -nE '/Transactions/,/Shortest/p' | awk -F":" '{print $2}' | awk -F" " '{print $1}'| sed 's/\./,/g' | xargs -L12 | sed 's/ /;/g'
rm tmp.out
Параметрами скрипта являются файл URL'ов, который генерировался из sitemap, и количество итераций в случае данных тестов всегда было равно 5. sleep 60 необходим для завершения всех очередей от предыдущей итерации.
По ходу было решено прицепить к сайту CDN CloudFlare, и, заодно посмотреть, как данный сервис влияет на нагрузочную способность вэбсервера. Для этого в DNS CloudFlare был добавлен субдомен с прямым адресом сайта и добавлен алиас в настройках виртуального хоста. Также был создан еще один файл URL'ов для прямого доступа к сайту.
Результаты
Подробные результаты теста вы можете посмотреть в этом файле. Здесь я приведу только диаграммы.
Не понятно почему выделяется из общей тенденции apache mpm-prefork через CloudFlare.
Так как полученные результаты имели большие погрешности из-за значительного разброса значений каждого прохода, было решено провести дополнительный тест на локальной виртуальной машине. Для этого была создана гостевая система Ubuntu 10.04 LTS на VirtualBox, с параметрами идентичными EC2 MicroInstance (1vCPU,630MB,8GB). Чтобы получить похожий процент отказов, я ограничил максимальную загрузку процессора доступную виртуальной машине в 7% (Intel Core i7 2.8 ГГц). Подробные результату этого теста можете посмотреть в этом файле.
Соотношение результатов похоже на тест через CloudFlare.
Выводы
MPM – Multi-Processing Module, можно перевести как “Модуль мультипроцессовой обработки” (не путайте с мультипроцессорной!).
Если быть совсем кратким – MPM используется сервером Apache для обработки нескольких запросов несколькими процессами одновременно.
В настоящее время используется 2 основных варианта MPM – это Worker и PreFork. Также, имеется сравнительно новый модуль – Event, который только недавно перешел из стадии‘experimental‘ в ‘stable‘.
В этой статье постараемся разобраться – в чем разница между этими тремя MPM- Worker, PreFork и Event.
Итак, начнем с модуля PreFork – на данный момент он является наиболее распространенным модулем, и по умолчанию Apache устанавливается именно с ним.
Apache MPM PreFork запускает по отдельному процессу на каждый запрос. Иначе говоря, каждый процесс одновременно обрабатывает только 1 поток (thread) на одно соединение. Т.к.PreFork заранее создает определенное количество процессов, которые не требуют времени на отдельный вызов при поступлении запроса к серверу и не нуждаются в выполнении маршалинга(в технологии ORPC – процесс упаковки запроса, включая параметры, в стандартный формат, пригодный для передачи по сети) во время его обработки, то такой вариант является наиболее быстродействующим, по сравнению с другими MPM. Однако, такой прирост производительности имеется только в случае, когда одновременно поступает некоторое ограниченное количество одновременных запросов, т.к. каждый из них должен ждать, пока процессор сможет их обработать. Кроме того, попытки увеличить количество одновременно запускаемых процессов способно серьезно повлиять на используемую сервером память.
Одним из важнейших преимуществ такого MPM является его большая безопасность, в силу того, что каждый процесс фактически изолирован от других. Его использование оправдано в тех случаях, когда используются модули, которые не поддерживают или плохо поддерживают, например – mod_php.
Apache MPM worker – использует многопоточную систему обработки запросов, что улучшает обработку большого количества соединений. MPM Worker запускает несколько процессов, которые, в свою очередь, запускают несколько потоков (threads). Об этом говорит сайт https://intellect.icu . Эти “дочерние потоки”, по аналогии с процессами MPM PreFork, ожидают входящих клиентских запросов. Такой подход является менее ресурсоемким в плане потребления оперативной памяти сервера, в отличии от процессов PreFork. Так же, улучшается обработка большого количества одновременных запросов, т.к. в отличии от PreFork запросу необходимо только получить свободный поток, который как правило есть, что позволяет сэкономить ресурсы сервера.
К недостаткам MPM Worker относится его относительная нестабильность, по сравнению сPreFork, т.к. проблемы в одном процессе могут затронуть другие соединения.Кроме того, имейте ввиду, что Worker связывает каждое keep-alive соединение с потоком, а не с запросом, и в таком случае каждый поток может выполнятся значительное время, пока соединение не будет окончательно разорвано.
И последний – Apache MPM Event. По принципу работы он очень похож на MPM Worker. Главное отличие Event от Worker в том, что он поддерживает выделенный поток для каждого установленного соединения, и передает дочерним потокам запрос только после того, как он был непосредственно сделан. И сразу же после обработки этого запроса – поток освобождается для выполнения следующего запроса. Такой вариант отлично подходит для клиентов, которые делают не частые запросы, но поддерживают долгие keep-alive соединения с сервером.
Исключением является обработка SSL-соединений, в таких случаях Event ведет себя аналогичноWorker-у.
Что касается сравнения работы Worker и PreFork – то можно увидеть сравнения напримертут>>>. Как видно, разница между ними всего несколько процентов, однако – все зависит от специфики каждого сервера и обрабатываемых им запросов.
Кроме того, многие из сравнительно старых модулей Apache требуют наличия именно MPM PreFork, что следует учитывать при выборе Multi-Processing Module для вашего сервера.
Так же, существуют еще несколько вариантов MPM – mpm-itk, mpm-peruser и другие>>>.
Напоследок – несколько полезных команд.
Узнать, какой тип MPM используется в установленном Apache можно любой из команд:
# apachectl -t -D DUMP_MODULES | grep mpm
mpm_prefork_module (static)
или
# httpd -V | grep mpm
-D APACHE_MPM_DIR=”server/mpm/prefork”
Установить Apache с выбранным MPM можно из соответствующего порта:
/usr/ports/www # ls | grep apache
…
apache22
apache22-event-mpm
apache22-itk-mpm
apache22-peruser-mpm
apache22-worker-mpm
…
Порт apache22 – установит Apache с mpm_prefork.
Интерпретатор PHP может работать в нескольких режимах. В этой статье рассматриваются следующие режимы работы:
Каждый из указанных режимов имеет как преимущества, так и недостатки. Те и другие качества в представляем ниже.
Этот режим предполагает подключение модуля mod_php в настройках веб-сервера Apache. В этом случае каждый процесс веб-сервера будет включать в себя этот модуль. Выбор этого режима особенно подходит для небольших сайтов с малой посещаемостью.
Преимущества:
Недостатки:
По своим свойствам FastCGI является золотой серединой между mod_php и CGI режимами. В нем исключены недостатки CGI и присутствуют его достоинства. При включенном FastCGI, в ОЗУ сервера располагается постоянно запущенный процесс-обработчик. Это избавляет от необходимости при каждом запросе запускать новый процесс, как в случае использования CGI. По быстродействию FastCGI аналогичен mod_php.
FastCGI сочитает в себе преимущества всех приведенных выше режимов. В этом случае php-обработчик запускается на постоянной основе, и теперь на каждый запрос не нужно создавать новый процесс, что было свойственно режиму CGI. FastCGI особенно подходит для высоконагруженных сайтов, нагрузка на которые постоянна.
Преимущества:
Недостатки:
В этом режиме запускается интерпретатор php-cgi для всех скриптов, для которых установлен CGI в качестве обработчика. Если большая часть сайта состоит из статического содержимого, то CGI будет хорошим выбором, т.к. будет обеспечено экономичное использование оперативной памяти за счет того, что интерпретатор будет вызываться в случае необходимости. Но и в то же время такой метод замедляет исполнение, т.к. при каждом запросе понадобится загрузка интерпретатора в память.
Преимущества:
Недостатки:
SuPHP является частным случаем CGI, в котором каждый php скрипт может выполняться с привилегиями разных пользователей.
Преимущества:
Недостатки:
Способ 1. С помощью функции phpinfo()
Способ 2. С помощью функции функции php_sapi_name()
Apache зарекомендовал себя как функциональный и стабильный веб-сервер, однако не стоит забывать о том, что Apache - очень "тяжелое" приложение в плане системных ресурсов сервера. Apache предоставляет возможность использовать разные варианты реализации MPM.
MPM - Multi-Processing Module, дословно "Модуль мультипроцессовой обработки". MPM используется Apache для обработки нескольких запросов одновременно несколькими процессами, то есть, по сути, занимается распаралеливанием обработки запросов.
На данный момент Apache поддерживает множество MPM. Основные из них рассмотрены в таблице.
| MPM | Поддерживаемые OS | Описание | Основное назначение |
| apache-ITK | Linux, FreeBSD | MPM, основанная на модели prefork. Позволяет запуск каждого виртуального хоста под отдельными uid и gid. | Хостинговые серверы, серверы, критичные к изоляции пользователей и учету ресурсов. |
| event | FreeBSD, Linux | MPM, основанная на модели worker. Обрабатывает большее количество запросов за счет освобождения основных потоков для новых запросов. | Высоконагруженные серверы. Использовать только в Apache 2.4 (для apache 2.2 - "This MPM is experimental, so it may or may not work as expected." |
| netware | Novell NetWare | Мультипоточная модель, оптимизированная для работы в среде NetWare. | Серверы Novell NetWare |
| perchild | Linux | Гибридная модель, с фиксированным количеством процессов. | Высоконагруженные серверы, возможность запуска дочерних процессов используя другое имя пользователя для повышения безопасности. |
| peruser | Linux, FreeBSD | Модель, созданная на базе MPM perchild. Позволяет запуск каждого виртуального хоста под отдельными uid и gid. Не использует потоки. | Обеспечение повышенной безопасности, работа с библиотеками, не поддерживающими threads. |
| pre-fork | Linux, FreeBSD | MPM, основанная на предварительном создании отдельных процессов, не использующая механизм threads. | Большая безопасность и стабильность за счет изоляции процессов друг от друга, сохранение совместимости со старыми библиотеками, не поддерживающими threads. |
| winnt | Microsoft Windows | Мультипоточная модель, созданная для операционной системы Microsoft Windows. | Серверы под управлением Windows Server. |
| worker | Linux, FreeBSD | Гибридная мультипроцессная-мультипоточная модель. Сохраняя стабильность мультипроцессных решений, она позволяет обслуживать большое число клиентов с минимальным использованием ресурсов. | Среднезагруженные веб-серверы. |
На FreeBSD по умолчанию Apache использует pre-fork MPM. Более детально о различиях в работе MPM описывать не буду - как всегда, катастрофически не хватает времени. Из собственного опыта:
Узнать текущую версию MPM работающего сервера можно такой командой:
|
# httpd -V | grep mpm -D APACHE_MPM_DIR="server/mpm/prefork" |
Выполнить установку Apache с определенным MPM можно из соответствующего порта:
|
# ls /usr/ports/www | grep mpm apache22-event-mpm |
Внимание!
Этот web-сервер был разработан для помощи в разработке. Он также может быть полезным в тестовых целях или для демонстрации приложения, запускаемого в полностью контролируемом окружении. Он не выполняет функции полноценного web-сервера и не должен использоваться во общедоступных сетях.
Таким образов встроенный веб сервер использовать не безопасно в открытых сетях. и предназначен лишь для локальной разработки.
Часто используется в фремворках, наприер в ларавел
$ php artisan serve --port=8080
Laravel development server started on http://localhost:8000 чтобы остановить нажмите ctl+C
Начиная с версии PHP 5.4.0 модуль CLI SAPI содержит встроенный web-сервер.
Если запрос блокирующий, то PHP приложения будут приостановлены.
URI запросы обслуживаются из текущей директории, в которой был запущен PHP, если не используется опция -t для явного указания корневого документа. Если URI запроса не указывает на определенный файл, то будет возвращен либо index.php либо index.html в указанной директории. Если оба файла отсутствуют, то возвращается 404 код ответа.
Если PHP-файл указывается в командной строке, когда запускается веб-сервер, то он рассматривается как скрипт "маршрутизации". Скрипт выполняется в самом начале после каждого HTTP-запроса. Если этот скрипт возвращает FALSE, то запрашиваемый ресурс возвращается как есть. В противном случае браузеру будет возвращен вывод этого скрипта.
Стандартные MIME-типы возвращаются для файлов со следующими расширениями: .3gp, .apk, .avi, .bmp, .css, .csv, .doc, .docx, .flac, .gif, .gz, .gzip, .htm, .html, .ics, .jpe, .jpeg, .jpg, .js, .kml, .kmz, .m4a, .mov, .mp3, .mp4, .mpeg, .mpg, .odp, .ods, .odt, .oga, .ogg, .ogv, .pdf, .pdf, .png, .pps, .pptx, .qt, .svg, .swf, .tar, .text, .tif, .txt, .wav, .webm, .wmv, .xls, .xlsx, .xml, .xsl, .xsd, и .zip.
| Версия | Описание |
|---|---|
| 5.5.12 | .xml, .xsl, и .xsd |
| 5.5.7 | .3gp, .apk, .avi, .bmp, .csv, .doc, .docx, .flac, .gz, .gzip, .ics, .kml, .kmz, .m4a, .mp3, .mp4, .mpg, .mpeg, .mov, .odp, .ods, .odt, .oga, .pdf, .pptx, .pps, .qt, .swf, .tar, .text, .tif, .wav, .wmv, .xls, .xlsx, и .zip |
| 5.5.5 | |
| 5.4.11 | .ogg, .ogv, и .webm |
| 5.4.4 | .htm и .svg |
Пример #1 Запуск web-сервера
$ cd ~/public_html $ php -S localhost:8000
В консоли выведется:
PHP 5.4.0 Development Server started at Thu Jul 21 10:43:28 2011 Listening on localhost:8000 Document root is /home/me/public_html Press Ctrl-C to quit
После URI запросов http://localhost:8000/ и http://localhost:8000/myscript.html в консоли выведется примерно следующее:
PHP 5.4.0 Development Server started at Thu Jul 21 10:43:28 2011 Listening on localhost:8000 Document root is /home/me/public_html Press Ctrl-C to quit. [Thu Jul 21 10:48:48 2011] ::1:39144 GET /favicon.ico - Request read [Thu Jul 21 10:48:50 2011] ::1:39146 GET / - Request read [Thu Jul 21 10:48:50 2011] ::1:39147 GET /favicon.ico - Request read [Thu Jul 21 10:48:52 2011] ::1:39148 GET /myscript.html - Request read [Thu Jul 21 10:48:52 2011] ::1:39149 GET /favicon.ico - Request read
Пример #2 Запуск с указанием корневой директории
$ cd ~/public_html $ php -S localhost:8000 -t foo/
В консоли выведется:
PHP 5.4.0 Development Server started at Thu Jul 21 10:50:26 2011 Listening on localhost:8000 Document root is /home/me/public_html/foo Press Ctrl-C to quit
Пример #3 Использование скрипта маршрутизации
В этом примере, запросы изображений будут возвращать их, но запросы HTML файлов будут возвращать "Welcome to PHP".
// router.php
if (preg_match('/\.(?:png|jpg|jpeg|gif)$/', $_SERVER["REQUEST_URI"])) {
return false; // сервер возвращает файлы напрямую.
} else {
echo "
Welcome to PHP
";
}
?>
$ php -S localhost:8000 router.php
Пример #4 Проверка использования CLI web-сервера
Для совместного использования скрипта маршрутизации при разработке с CLI web-сервером и в дальнейшем с боевым web-сервером:
// router.php
if (php_sapi_name() == 'cli-server') {
/* Маршрутизация с заданными правилами и выход с возвращением false */
}
/* продолжение с обычными операциями index.php */
?>
$ php -S localhost:8000 router.php
Пример #5 Поддержка неподдерживаемых типов файлов
Если вам нужно обслуживать статические ресурсы с MIME типами неподдерживаемыми CLI web-сервером:
// router.php
$path = pathinfo($_SERVER["SCRIPT_FILENAME"]);
if ($path["extension"] == "el") {
header("Content-Type: text/x-script.elisp");
readfile($_SERVER["SCRIPT_FILENAME"]);
}
else {
return FALSE;
}
?>
$ php -S localhost:8000 router.php
Пример #6 Доступ к CLI web-серверу с удаленных машин
Вы можете сделать web-сервер доступным на 8000 порту для всех сетевых интерфейсов:
$ php -S 0.0.0.0:8000
Проверьте, какие MPM Apache в настоящее время использует:
apachectl -V | grep -i mpm Result: Server MPM: prefork
Список доступных модулей MPM (Убедитесь, что mpm_worker указана)
ls /etc/apache2/mods-available/mpm* Result: /etc/apache2/mods-available/mpm_event.conf /etc/apache2/mods-available/mpm_prefork.conf /etc/apache2/mods-available/mpm_worker.conf /etc/apache2/mods-available/mpm_event.load /etc/apache2/mods-available/mpm_prefork.load /etc/apache2/mods-available/mpm_worker.load
Список разрешенных модули MPM (Если mpm_worker не включен, мы должны включить его и отключить модуль mpm_prefork)
ls -l /etc/apache2/mods-enabled/mpm* Result: /etc/apache2/mods-enabled/mpm_prefork.conf -> ../mods-available/mpm_prefork.conf /etc/apache2/mods-enabled/mpm_prefork.load -> ../mods-available/mpm_prefork.load
Отключить модуль MPM_PREFORK
a2dismod mpm_prefork
Включить модуль MPM_WORKER
a2enmod mpm_worker
Для того, чтобы проверить, если Apache работает на MPM_worker
apachectl -V | grep -i mpm Result: Server MPM: worker обратите внимание что
worker не используется с апачем с php модулем а nginx(proxy)+ mpm_prefork+php-fpm будет проблемым из-за большого колва процессов и большогопотребления памяти, при этом nginx не даст особый эффект оптимальные варианты использования
nginx(fast-cgi)+php-fpm или nginx(proxy)+apahe(php-module,mpm_prefork) или
nginx(proxy)+apahe(php-fpm,mpm_worker)
Выводы из данной статьи про варианты настройки mpm для apache указывают на необходимость использования современных методов для оптимизации любых систем. Надеюсь, что теперь ты понял что такое варианты настройки mpm для apache, mpm-prefork, mpm-worker, mod_php, php-fpm, nginx reverse proxy, php настройка и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Выполнение скриптов на стороне сервера PHP (LAMP) NodeJS (Backend)
Комментарии
Оставить комментарий
Выполнение скриптов на стороне сервера PHP (LAMP) NodeJS (Backend)
Термины: Выполнение скриптов на стороне сервера PHP (LAMP) NodeJS (Backend)