PHP FastCGI и APC|Xcache

Не будет.

502 апач не выдаст, верно. Но вместо этого, будут подвисшие на длительный срок детки апача. Т.е. проблемы как таковой это не решит. Мало того, будет даже хуже, т.к. при большой нагрузке тормозящие скрипты либо будут выедать весь запас деток апача, и сервер просто перестанет отвечать, либо, если апач настроен неправильно, сервер уйдёт в своп. В итоге 502 от nginx меньшая проблема.

Проблема не в связке - проблема в том, что какой-то скрипт выполняется слишком долго.

Да чё вы не слушаете mvolgin ! :)

Поставьте вы наконец-то! нормальный АПАЧИ :)

В чем проблема посмотреть какие процессы долго висят что они делают и почему?

forest25, добрый день. Я так понял, что интернет-магазин на системе битрикс.

А сколько товаров на сайте? (Недавно был пост про то какую лучше связку ставить для интернет-магазина) - Люди пишут, что если товаров свыше 1000 то битрикс очень сильно сервер грузит. А канал хороший от сервера идет?

Так не в чём. Собственно, ТС этим сейчас и занимается, т.е. профилированием и оптимизацией скрипта. И совершенно правильно.

Вопрос был в том, что проблема-то совершенно не в Nginx, и даже не в fastcgi. И ваш совет перейти на Apache, проблему кривых скриптов ни коем образом не решит.

apc, xcache и т.д. это системы кэширования байткода. Они не кешируют страницы или файлы.

На связке nginx + php_fpm хорошо повышает производительность xcache.

Прошу прощения, запамятовал про данную тему =)

Вообще нашел в init.php (скрипт который подгружается в Битриксе при открытии любой странички) функцию какого-то горе-кодера делавшего правки в магазе до меня. Так вот эта самопальная функция при открытия каталога товаров генерировала совершенно дикие запросы с кучей JOIN'ов по 500-600 таких запросов на страницу.

Естественно MySQL конечно первое время мужественно держался, а потом уходил в глобальный такой зависон.

Переписал функцию - тормоза ушли.

Около 13000 товаров и около 1000 посетителей в сутки которые делают до 10000 просмотров. Крутится на выделенном сервере (Hetzner, NHS-1 у крупнейшего ресселлера). LA в пределах 0.2-.025

А вопрос у меня так и остается открытым =)

Дабы не разжигать жаркие споры и священные воины вопросы будут только по apache

Вот к примеру:

1) Apache + mod_php + APC|XCache

2) Apache + mod_fcgid + APC|XCache

Будет ли во втором случае APC|XCache столь же полезным как и в первом?

Лучше ограничиться Apache + mod_php + nginx

APC|XCache больше глюков добавят, чем принесут заметной пользы.

настроить базу, больше в память кешировать и будет счастье.

Кто вам такую глупость сказал?

Кеширование опкода заметно прибавляет производительность. На скриптах без сложных запросов к БД, файлового ввода/вывода, интенсивных вычислений разница может быть даже на порядок. И в любом случае она будет.

В этом случае будет один общий кеш.

Будет отдельный кеш у каждого процесса php.

Это конечно бОльшие накладные расходы, но всё равно может быть полезно, при разумном размере кеша конечно.

Есть ещё модуль mod_fastcgi, который порождает один или более процессов php(maxClassProcesses за это отвечает), и его дочерние процессы в нужном количестве(PHP_FCGI_CHILDREN). Вот тут у всех дочерних процессов будет общий кеш, и количество отдельных кешей будет задано количеством мастер процессов(например по одному на сайт или пользователя), и если всё правильно настроить не будет оверхеда по потреблению памяти, просто вместо одного общего кеша будет несколько отдельных такого же суммарного размера.

Ещё есть php-fpm, который нынче официальный fastcgi менеджер php. И там тоже проблемы с кешерами опкода нет.

Собственно именно его и надо бы использовать - он наиболее функционален... Для работы с ним Apache нужен будет proxy_fcgi_module.

Кстати, apache + mod_php, при прочих равных, несколько более производительное решение - там нет необходимости во взаимодействии по fastcgi, и соответственно немного меньше оверхед. И если нет необходимости разделения прав, то это наилучший вариант если смотреть с точки зрения времени выполнения скриптов.

bsyomov

Большое спасибо за развернутый ответ, но хотелось бы еще кое что уточнить.

Как будут себя вести кешеры в случае с вариантом 2, но apache в режиме mpm-itk?

И насчет первого варианта: я так понимаю в данном случае порождается дополнительный процесс php, кешер сохарняет опкод, затем скрипт отрабатывает и процесс завершается.

Кому в таком случае будет нужен кешированный опкод? И куда он девается?

Может я чего то не так понял, но просто хотелось бы досконально разобраться.