Как обустроить веб?
Добрый день.
Долгое время я использовал связку nginx + apache2-mpm-itk + ldap +
libapache2-mod-php.
nginx раздает статику и собирает сайт из набора веб-приложений
apache2 занимается интерпретацией .htaccess и запуском всякого рода
скриптов на интерпретируемых языках.
mpm-itk обеспечивал запуск каждого виртуального хоста под отдельным
пользователем
ldap служил источником авторизации для апача
На днях запускал сайн написаный на PHP/Zend - JSON API с бэкендом в
виде маленькой mongodb-базы. К сайту были написаны нагрузочные тесты.
Наилучшая производительность достигается с mpm-prefork и php5-xcache с
минимальным количеством апачевых воркеров. Производительность
mpm-prefork без xcache и mpm-itk с xcache примерно одинакова и
отличается от связки "prefork+xcache" в разы. Тест получился почти
синтетическим, т.к. производительность БД была высока (чтение-запись
по ключу), меряли по сути PHP.
Проблема неработоспособности PHP-акселераторов с mpm-itk и suphp
подтвеждается гуглом.
Теперь я ищу альтернативу mpm-itk, которая бы позволила мне
использовать xcache ибо другой улучшатель PHP.
Дабы не плодить лишний флейм, очерчу круг плохих для меня решений:
1) Полный отказ от apache2 в пользу php-fpm. Его фичи используются
почти везде, ресурсов на миграцию мне не дадут. Ну и кроме того - есть
масса не-php сайтов, а апач позволяет запускать весь мой зоопарк
примерно одинаковым образом, что хорошо стыкуется с системой
управления конфигурациями и здравым смыслом.
2) Запуск всего хозяйства под mpm-prefork (т.е. с правами пользователя
www-data) - это потребует пересмотра системы безопасности, фаерволов,
прав на файловой системе - см. выше про ресурсы.
Хорошее решение: запуск разных вирутальных хостов apache2 под разными
пользователями, но с поддержкой php-акселераторов
Промежуточное решение - оставить старые приложения работать как есть,
проведя миграцию на php-fpm только там, где производительность PHP
имеет какой-то коммерческий смысл. Такое решение очевидно.
С радостью приму разумные советы по сабжу.
Спасибо!
--
WBR, Bogdan B. Rudas
Reply to: