PHP FastCGI и APC|Xcache

123
bsyomov
На сайте с 25.01.2012
Offline
31
#11
mvolgin:
Угу а 502 от святого духа :))) Поставите нормальный апач всего этого треша и все будет работать как часы.

Не будет.

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

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

madoff
На сайте с 01.12.2009
Offline
235
#12

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

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

Администратор Linux,Freebsd. (/ru/forum/494299) построения крупных проектов. ICQ#: 241606.
M
На сайте с 19.01.2011
Offline
65
#13
bsyomov:

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

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

________________________ я больше не хостер ....
Lord_Leon
На сайте с 04.03.2010
Offline
63
#14

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

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

Промышленный дизайн (https://aicogroup.ru/portfolio/industrial-design) корпуса для рэа | Крипозащита данных, создание сайтов (https://aicogroup.ru/portfolio/sozdanie-saytov).
bsyomov
На сайте с 25.01.2012
Offline
31
#15
mvolgin:
В чем проблема посмотреть какие процессы долго висят что они делают и почему?

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

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

AS
На сайте с 23.06.2010
Offline
31
#16

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

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

forest25
На сайте с 12.09.2009
Offline
67
#17

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

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

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

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

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

Около 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 столь же полезным как и в первом?

VPS 512MB 20GB SSD KVM - 5$ (http://u.hmdw.me/digitalocean) | ИМХО о хостингах (http://u.hmdw.me/hosting)
Mik Foxi
На сайте с 02.03.2011
Offline
925
#18
forest25:

Вот к примеру:
1) Apache + mod_php + APC|XCache
2) Apache + mod_fcgid + APC|XCache

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

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

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

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

Антибот защита сайта от накрутки поведенческих, от спама, взлома и поиска xss, от хит и клик ботов, от парсинга и кражи контента, снижение нагрузки на сервер - https://antibot.cloud/ Вам все еще конкуренты генерят отказы?
bsyomov
На сайте с 25.01.2012
Offline
31
#19
foxi:
Лучше ограничиться Apache + mod_php + nginx
APC|XCache больше глюков добавят, чем принесут заметной пользы.

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

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

forest25:
Вот к примеру:
1) Apache + mod_php + APC|XCache

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

forest25:

2) Apache + mod_fcgid + APC|XCache

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

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

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

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

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

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

forest25
На сайте с 12.09.2009
Offline
67
#20

bsyomov

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

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

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

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

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

123

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий