Ответы пользователя по тегу Apache HTTP Server
  • Как ускорить apache в связке nginx?

    @hell
    В общем случае таких тормозов быть не должно на вашем железе.
    Попробуйте собрать статистику запросов и попрогонять их по одному через siedge с конкуренцией 2000.
    И врядли fpm даст значительную прибавку - на реальных приложениях обе связки работают примерно одинаково, разумеется, если апач настроен правильно.
    Правильно, в данном случае, без лишних модулей, без .htaccess, AllowOverride None и т.д.
    Посмотрите, что творится с пользовательскими сессиями - они могут чрезмерно плодиться.
    Ну и коннекты к БД - возможно там стоит какое-то ограничение.

    То есть в принципе, вам надо проделать примерно следующее:
    1) Почистить апач от всего лишнего.
    2) Сделать тестовую страничку, перекинув данные из БД в масссив и попробовать прогнать ее через siedge (ab в данном случае не катит)
    3) Если страничка будет отрабатывать без тормозов, пустить ее же, но уже в динамике с данными из СУБД. Сравнить результаты
    4) Если и тут все пойдет без тормозов, собрать в логах нгинкс реальные запросы и попробовать попрогонять их по отдельности через siedge - возможно удастся найти конкретные страницы, на которых все ломается.
    5) Смотреть и профилировать код
    Ответ написан
  • Nginx + php5-fpm VS Nginx + Apache; Что выбрать?

    @hell
    По первому пункту:
    Правильнее будет протестировать на актуальном железе и в актуальной конфигурации. Кроме того, ответ на ваш вопрос будет зависеть еще и от вашей возможности корректировать параметры ядра. На виртуалках у вас такой возможности может и не оказаться.

    Полтора года назад я делал такие тесты для своего сервера.
    Тестировались три варианта - nginx+php-fpm, nginx+apache+mod_php, nginx+nginx+php-fpm. результаты тестов на боевых сайтах показали:

    при правильной настройке apache - nginx+php-fpm - наименее производительное решение
    nginx+apache+mod_php и nginx+nginx+php-fpm выдерживают примерно одинаковую нагрузку, но второе решение чуть менее надежное (то есть именно чуть - в среднем, на 1000 натравливаний siege на боевой сервер, php-fpm слетел раз 7, а апач - раза 2)

    Софт с тех пор поменялся, железка у вас заведомо другая (та, на которой я тестировал, погорела), у меня был debian без виртуалок, у вас - Centos, посему актуальные результаты тестов в вашем случае могут оказаться другими.

    По второму - позволю процитировать себя же - "при правильной настройке apache". Правильная настройка апача на производительность включает полный отказ от .htaccess. Часть переносится в nginx, часть - напрямую в конфиги конкретного веб-сервера. Ну и из апача вообще выбрасываетс много-много-много всего. Нужно помнить, что правила рерайта в нгинксе огтличаются от апачевских - на хабре была пара правильных (особенно с учетом комментов) статей, ну и на самом сайте нгинкса примеров хороших более чем достаточно.

    По третьему - если вы проведете тесты и убедителсь, что с надежностью у связки nginx+nginx+php-fpm все нормально на ваших сайтах, я бы перешел.
    Поясню суть такой связки:
    внешний nginx отдает статику, зипует на лету, частично рерайтит запросы, а также проксирует запросы к php на внутренний нгинкс. Кроме того, по необходимости и возможности, он может кешировать часть запросов. У внешнего нгинкса keepalive_timeout установлен в достаточно большое значение (то есть тоже стоит подбирать).
    Внутренний нгинкс стоит с keepalive_timeout=0, и работает с php-fpm.

    Прекрасной плюшкой такой связки является возможность кеширования страниц с одновременным, простым и наитивным отключением кеширования интерактивной части (то есть, к примеру, вы кешируете весь сайт кроме блока комментариев и блока каких-нить прикольных фишечек, которые выводятся по рандому).

    Минусом - принципиальные отличия в логике рерайтов на nginx и в apache. Врочем, если потратить разок 2-3 рабочих дня на то, чтобы в этих разлиичях разобраться, дальше все будет проще.
    Ответ написан
    3 комментария
  • Отказ от apache в связке nginx + httpd + php?

    @hell
    Боюсь, что огребу за свой совет кучу минусов, но тем не менее:

    Месяца три назад, я 2 недели посвятил тестам — что лучше. Правда — у меня стоял PHP 5.4, nginx 1.2 и все это на Debian
    Тестировал (и, разумеется, в процессе тестов тюнил ОС и все прочие настройки) четыре варианта — nginx+PHP, nginx+ahache+PHP, nginx+nginx+PHP (в последнем случае есть внешний нгинкс, работающий со статикой и отправляющий запросы к PHP на внутренний нгинкс) и nginx+apache+PHP-FPM.

    Внутренние нгинкс и апач запускаются в режиме keepAlive off
    У апача отрублено все лишнее (в моем случае оставлены dir, auth, mime, rpaf). ,haccess не используется (если че-то нужно органичить — ставим напрямую в конфигах сайта, все перенаправления — через внешний нгинкс)
    У внешнего нгинкса включен gzip, отключено кеширование
    Внутренние сервера логируют только ошибки php

    Во всех случаях на реальные сайты натравливался siege с увеличенным таймаутом и с 1000 конкурентных запросов.

    Да — и машинка — Хетзнеровская с 24 GB памяти.

    Результаты получились следующие:

    nginx + php — не котируется вообще. выводит память в свап, нагрузка в top — 140 — 150 примерно через минуту после начала осады. Манипуляции с системой и настройками не помогли.

    nginx+apache+php-fpm — жрет память и залезает в свап, процессор особо не грузит. Есть проблемы со стабильностью (siege стабильно отрабатывал с параметром не более -c 500)

    nginx+apache+php и nginx+nginx+php — примерно одинаковые результаты — средняя нагрузка в top — 3, среднее потребление памяти — 14 — 16 Gb. Количество транзакций также примерно одинаково (apache показывал результаты примерно на 3-4 транзакции в секунду лучше)

    nginx+nginx+php работал чуть менее стабильно, чем nginx+apache+php (не чуть, даже — чуть-чуть — то есть пару тройку раз сокет все-таки падал, а в случае apache тaкого не было)

    Пришлось остановиться на классике (хотя очень хотелось ограничиться nginxом)

    Впрочем — это все — лирика. Я бы рекомендовал провести серию тестов с вашим софтом (и с вашим админом) — возможно вы получите другие результаты. Впрочем — и это почти наверняка — вариант с реверс-прокси будет заведомо более производительным.
    Ответ написан
    2 комментария