Виснет апач

[sitecreator]

9 минут назад, Yoda сказал:

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

 

Честно говоря, даже не знаю на чем построена эта ваша личная глубокая если мы, например, с вами лично не встречались и почти не общались. По отношению к вам я никогда не позволял себе переход на личности. Ну Бог вам судья.

 

Некоторые ваши утверждения в технических аспектах порождают вопросы и сомнения, поскольку далеко не всегда вы даете обоснование им. В ваших словах же можно иногда сомневаться?

 

16 минут назад, Yoda сказал:

Opencart заточен все-таки под работу в связке apache + mysql а не nginx+phpfpm + mysql

 

Пожалуйста, просто можете объяснить на конкретном примере чем же принципиально отличаются эти две связки?  В чем конкретная опасность?

 

И в чем принципиальные отличия связок апаче+php (модуль) + mysql   и апаче+php (CGI) + mysql ?  Что предпочтительнее?

 

19 минут назад, Yoda сказал:

Во вторых по сути вопроса на 99% проектов прирост производительности настолько ничтожный, что это экономия на спичках. 

 

Возможно. вы это как-то измеряли или?  Если из связки apache + nginx убрать апаче,  разве не высвободится дополнительная память?

 

У меня по поводу nginx нет никаких иллюзий.  Просто интересно исследовать вопрос, сделать мониторинг и всевозможные измерения.

 

С другой стороны  если nginx не привносит никаких минусов, то почему бы его не использовать?  Перечень минусов (неустранимых и т. д.)  хотелось бы увидеть.

Могу в чем то заблуждаться из-за недостатка опыта, так для приобретения оного и есть желание учиться и ставить эксперименты.

 

[Dotrox]

20 минут назад, Yoda сказал:

И в силу того что нативно Opencart заточен все-таки под работу в связке apache + mysql а не nginx+phpfpm + mysql, делать в такой конфигурации магазины я крайне не рекомендую никому!

 

Каким местом он под эту конфигурацию заточен? Вопрос не риторический и требует в ответ конкретных примеров! Хотя, уверен, вы отпишетесь пафосными фразами о том, что вы слишком круты, чтоб отвечать на такие вопросы.

 

Кстати, при чём там вообще mysql?

 

Я уже где-то полтора года перевожу магазины на связку nginx+php-fpm и за это время ещё ни разу не сталкивался с проблемами из-за отсутствия Апача, так что не надо выдумывать!

Ну, а если у кого-то руки не из того места, то сколько на форуме тем о том, как люди не могут внести элементарные правки в .htaccess.

 

 

32 минуты назад, Yoda сказал:

А нифига так не быстрее. Подобное решение уместно абсолютно на высоконагруженных проектах от 100+ одновременных сессий - не вопрос.

 

Любопытно, а как вы связываете скорость и количество запросов? Количество запросов влияет прежде всего на количество воркеров, а они в свою очередь на потребление памяти. И таки да, на сотне воркеров Апач не хило её нажрётся, но при чём тут скорость?

И потребление памяти - это второй пункт, почему надо использовать именно nginx+php-fpm. На KVM виртуалках память достаточно дорогой ресурс, чтоб транжирить её на Апач.

 

 

53 минуты назад, Yoda сказал:

А на средней руки магазин даже в 5 000 хостов в день - это чистой воды погоня за модой и костыли!

 

Какая у вас "гениальная" логика: если запросов мало - это костыль, если много - уже не костыль. Это так не работает: костыль - он всегда костыль. Иначе это уже не костыль, а просто не рациональное использование инструментов. Но в использовании php-fpm ничего не рационального нет - это полноценная альтернатива запуску php под Апачем, которую можно использовать в любых случаях, потому что она не несёт каких-либо отрицательных изменений по сравнению с Апачем, а только положительные.

 

 

59 минут назад, Yoda сказал:

А вы сейчас два героя разведете здесь демагогию и начнется волна.

 

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

 

Наверное, лет 10 назад вы бы точно так же призывали не переносить отдачу статики с Апача на nginx (что уже стало стандартом) и с теми же аргументами про количество запросов и костыли.

[sitecreator]

Это  будет в некотором роде шпаргалка. Вероятно, что может пригодиться энтузиастам, желающим настроить nginx+php-fpm.

Для принятия изменений, сделанных в конфигах nginx, необходимо его перезапустить. Действия описываю из предположения, что установлена Centos 7.

 

systemctl restart nginx.service

Скорее всего версий php у вас будет установлено несколько. Буду исходить из того, что у вас используется php5.6. После изменения конфига (конфигов) перезагружаем службу

 

systemctl restart php-fpm56.service

основной конфиг php.ini находится здесь: /opt/php56/etc/php.ini

 

В нем у меня есть строка

display_errors = Off

Если в Shell дать команду (phpinfo)

/opt/php56/sbin/php-fpm -i

получим:

 

но если запустить phpinfo через веб-браузер, то результат иной, т. к. сработал еще файл конфигурации php для конкретного пользователя:

 

 

 

 

В конфиге для юзера  (а он и будет Master volume в нашем случае) /opt/php56/etc/php-fpm.d/user.conf  есть  (это создал ispmanager):

 

php_admin_value[display_errors] = stderr

заменил на:

 

php_admin_value[display_errors] = 0

Ошибки перестали выводиться. Но управлять display_errors через файл .user.ini или в коде php уже не получится. 

Лучше вообще убрать эту строку, тогда можно управлять выводом ошибок через файл .user.ini.

 

А вообще по идее должна быть строка:

php_value[display_errors] = Off

 

А значения stderr или stdout из конфига воспринимались всегда как On. Хотя, если я правильно понимаю мануал (http://php.net/manual/ru/errorfunc.configuration.php#ini.display-errors), то первое значение как раз должно было отменить вывод ошибок в общий поток (их не должно было отправлять в браузер). Но что-то не сработало.

Еще строка в этом конфиге:

php_value[max_execution_time] = 600

также не позволит менять  (через файл .user.ini или в коде php) время выполнения скрипта.

 

В общем, все параметры заданные через php_value или php_admin_value не позволят что-либо потом поменять оперативно и избирательно в самом скрипте php или через .user.ini.  Правда, я не понял почему это так в случае php_value.

Змінено 2 березня 2017 користувачем sitecreator

[Dotrox]

36 минут назад, sitecreator сказал:

Правда, я не понял почему это так в случае php_value.

Там есть нюанс: https://secure.php.net/manual/en/configuration.file.per-user.php

 

Цитата

Only INI settings with the modes PHP_INI_PERDIR and PHP_INI_USER will be recognized in .user.ini-style INI files.

 

 

44 минуты назад, sitecreator сказал:

Для принятия изменений, сделанных в конфигах nginx, необходимо его перезапустить.

 

Не обязательно! Конфиг можно перезагрузить без перезагрузки сервиса:

systemctl reload nginx.service

 

А ещё перед этим полезно тестировать конфиг:

nginx -t

 

[sitecreator]

11 часов назад, Dotrox сказал:

Там есть нюанс

 

спасибо,

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

 

https://roman.am/files/ServerAdministrationNGINX.pdf

 

Это книга в формате pdf на русском по администрированию nginx.  Думаю, что будет полезной для желающих изучить nginx. Плюс, конечно, официальная документация.

 

Есть у меня желание протестировать и проанализировать на двух хорошо нагруженных проектах nginx+php-fpm.

И, главное, сравнить с режимом работы nginx + Апаче + php (CGI/fastCGI).

 

И сравнение планирую проводить за ощутимый период, не менее недели под нагрузкой.  Думаю, что реальные проекты с просмотрами в районе 35000 и выше (в сутки)  вполне годятся для этого.

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

 

Обещаю полученной информацией поделиться с сообществом.

Думаю, что любые неаргументированные утверждения в данном вопросе сродни религиозному "убеждению" или схожи с утверждениями адептов "учений" тупоконечников / остроконечников.

 

--------

Для меня остается загадкой почему один маэстро категорически рекомендует пользователям использовать именно [nginx] + апаче + php (CGI).

Единственный аргумент, который я нашел:

Цитата

он будет работать от владельца виртуалхоста и это исключит проблемы с правами.

 

Просто такой режим создает потенциальные и реальные проблемы пользователям, которые они не в состоянии решить, и которые не возникли бы вообще если бы режим был [nginx] + апаче + php (модуль).

 

Известную проблему я описывал выше: не работают модули связи с 1С.  И данная проблема не решается только за счет правки .htaccess, нужно еще делать правки в коде.

 

Так о какой же тогда "заточенности  под работу в связке apache + mysql "  идет речь если эта связка, точнее вот эта:

апаче + php (CGI)

на деле оказывается не заточенной под Опенкарт. Или Опенкарт под нее не заточен.

 

Полагаю, что если уж и говорить о "заточенности" опенкарта, то вот под эту связку:

 

[nginx] + апаче + php (модуль)

Ибо именно в такой связке у пользователя не возникает проблем и танцев с бубнами по поводу http-авторизации. К тому же апаче в сборке Apache MPM-ITK хорош тем, что скрипты работают от имени пользователя, не смотря на то, что php работает как модуль.  С некоторых пор ispmanager предлагает прямо из панели управления такой вариант, а раньше нужно было собирать и настраивать самостоятельно, что не совсем подходит для начинающих.

 

Как минимум, производительность не должна быть ниже в случае php (как модуля) по сравнению с php (CGI).

 

--------------------

Либо я в чем -то заблуждаюсь, что бывает свойственно людям, и не вижу прелестей апаче + php (CGI), либо заблуждается некий маэстро, настоятельно его рекомендующий.

По крайней мере, никакой аргументации в пользу данного режима не было.  А будет ли?  Может быть, и нет никаких аргументов "за"?

[Dotrox]

6 часов назад, sitecreator сказал:

он будет работать от владельца виртуалхоста и это исключит проблемы с правами.

 

Это утверждение от тех, кто не умеет готовить php-fpm. Каждый пул php-fpm может работать от имени отдельного пользователя и группы и более того, слушать на отдельном сокете. То есть, владелец/группа пула могут быть те же, что и у вебдиректории и никаких проблем с правами не будет.

 

 

6 часов назад, sitecreator сказал:

не вижу прелестей апаче + php (CGI)

 

Лично я смысл этой связки кроме, как для организации параллельно нескольких версий php на шареде - не понимаю. Потому что Апач тут вообще выступает лишней прослойкой.

[sitecreator]

25 минут назад, Dotrox сказал:

Лично я смысл этой связки кроме, как для организации параллельно нескольких версий php на шареде - не понимаю.

 

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

 

И я тоже не могу понять зачем апаче нужен в этой цепочке: nginx + Апаче + php (CGI). В данном случае php не модуль и никак не привязан к апаче.  Так зачем нам апаче? Неужели только для .htaccess и rewrite, которые лень переписать один раз в другой формат?

 

----------------

организовал мониторинг двух серверов средствами Munin.  Интересно будет посмотреть и сравнить загруженность того же процессора и использование памяти, например. Сбор статистики стартовал. Недели две пособираю.

[sitecreator]

Наблюдение за высоконагруженным сайтом и сравнение 2-х режимов работы позволяют сделать определенное заявление о преимуществе nginx+ php-fpm над режимом Апаче+php (как CGI).

 

При переходе на nginx+ php-fpm  изменилось использование памяти:

увеличилось с 35...40%   до 45%

 

Нагрузка на процессор снизилась практически вдвое:

с 30...35%  до 15...20%

 

Сбор всех показаний ведется ежедневно. Цифры  выглядят довольно впечатляюще.  Даже не знаю уместно ли на этом фоне говорить о "заточенности" и преимуществах апаче+php (CGI), даже пусть будет апаче+php (как модуль)...

[HyperLabTeam]

.htaccess для nginx  тормоз
из за малой инфы по конфигу подумываю съехать

[sitecreator]

5 часов назад, AWARO сказал:

.htaccess для nginx  тормоз

 

по-русски можно? кто тормоз?

 

5 часов назад, AWARO сказал:

из за малой инфы по конфигу подумываю съехать

 

инфы по nginx мало? Есть официальная документация, в которой расписано все до мелочей.  Многие вещи делаются прозрачнее и логичнее чем в Апаче.

книг "nginx для чайников" не встречал, а нужны ли такие?

 

и ничего не понял: откуда куда съехать?

[HyperLabTeam]

я не люблю много стучать по клаве, кто знает тот понял
есть вещи которые я нифига не нашёл - например
такое просто делается

#RewriteRule (.*)/(.*) http://site.ru/$2? [R=301,L]
RewriteCond %{HTTP_HOST} ^/product&manufacturer_id=\[0-9]/product_id=\[0-9]$
RewriteRule ^(.*)$ http://site.ru/product_id=\[0-9]$2? [R=301,L]

а вот как иначе в конфиг?
----------
о чем я
https://yandex.ru/yandsearch?text=.htaccess и nginx&lr=213&clid=2186621

[sitecreator]

27 минут назад, AWARO сказал:

такое просто делается

 

да, для nginx это делается просто. 

И в nginx используются те же самые регулярные выражения в стиле perl.  регулярки - это отдельный язык (не программирования).  Может быть у вас проблема с регулярками, а не с nginx?

 

.htaccess не использует nginx.  Нужная запись делается в конфигурационный файл. Не вижу в этом проблемы.  Один раз понял суть - и нет проблем.

Преимущества nginx перекрывают такой недостаток как необходимость один раз немного углубиться в документацию и понять основные моменты.

 

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

 

Но если вы не хотите читать инструкцию, то оставьте связку nginx+php-fpm + апаче.  Вот апаче здесь будет исключительно только для того чтобы читать ваши .htaccess, но преимущество nginx вы уже получите.  Согласитесь, что присутствие апаче, а следовательно, лишняя нагрузка на процессор будут следствием простой человеческой лени изучить что-то новое.  В конце концов можно один раз пригласить того, кто разбирается.

 

вот тут с коллегой @Dotrox сделали наброски для конфигурации.  основное ISPmanager сам генерирует, остается руками дописать нужное.

 

 

28 минут назад, AWARO сказал:

кто знает тот понял

 

я считал, что я знаю уже кое-что, но многое не понял все равно в вашем тексте.  особенно сложно когда нет знаков препинания - непонятно вопрос это или утверждение....

 

46 минут назад, AWARO сказал:

я не люблю много стучать по клаве, кто знает тот понял

 

если вы пишите в общественном ресурсе, то, вероятно,  грамотное изложение - это и есть в первую очередь уважение к читающим? В противном случае "не люблю" можно воспринимать как "не уважаю" читающих, не так ли?

[HyperLabTeam]

По теме очень интересно, благодарю!   Но проблема во времени и его нет на всё это углубление в ленинскую библиотеку - - вообще в *веб разработку* я залетел на полчаса - это если сравнивать с тем сколько вы в нём обитаете, ну и как обычно это бывает из за прочих приоритетов придется вылететь обратно в офф и похоже на то, что это уже скоро произойдёт. (хотя это одному Богу известно)..
Влез как обычно по ходу чтения темы, бывает у меня такое, будто бы в дискуссии участвовал и вывалил то, что вспомнил т.к. как то пришлось с этим столкнутся ну а со временем забыл совсем.

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

А это

44 минуты назад, sitecreator сказал:

если вы пишите в общественном ресурсе, то, вероятно,  грамотное изложение - это и есть в первую очередь уважение к читающим? В противном случае "не люблю" можно воспринимать как "не уважаю" читающих, не так ли?

вроде и не первый раз пересекаемся, ну а коль уж если этим "не уважаю" повеяло - то отвечу утвердительно - нет, совершенно ни так) в данном случае это ошибочное мнение)

Так норм?))
 

[Dotrox]

2 часа назад, AWARO сказал:

есть вещи которые я нифига не нашёл - например
такое просто делается

#RewriteRule (.*)/(.*) http://site.ru/$2? [R=301,L]
RewriteCond %{HTTP_HOST} ^/product&manufacturer_id=\[0-9]/product_id=\[0-9]$
RewriteRule ^(.*)$ http://site.ru/product_id=\[0-9]$2? [R=301,L]

Я уж было хотел написать, как это будет для nginx, но внимательно посмотрев на этот конфиг, понял, что тут какой-то маразм, при чём полный.

 

Вот эта строка не имеет смысла вообще:

RewriteCond %{HTTP_HOST} ^/product&manufacturer_id=\[0-9]/product_id=\[0-9]$

1. {HTTP_HOST} - это домен! Бессмысленно в нём искать GET параметры.

2. Как можно догадаться, здесь кусок не ЧПУ ссылки, однако он обёрнут в "^/" и  "$", что означает, что это должно быть полное содержимое от начала до конца ссылки.

3. Сам по себе этот кусок ссылки неправильный поскольку не хватает амперсанда между manufacturer_id и product_id.

 

В общем, это условие должно было бы быть разбито на несколько и проверяться должна переменная {REQUEST_URI}, где и находятся все эти параметры.

 

И в следующей строке, где сам редирект, тоже ошибка: там не может быть $2! Если там нужно подставить значение из product_id в RewriteCond, то должно быть %2.

А параметры с долларом - это то, что выдернула регулярка в самом RewriteRule и в данном случае там есть только $1. Чтоб была двойка, должно было быть что-то типа ^(.*)bla-bla(.*)$ (или как в первой строке, которая закомментирована).

Ну, и наконец - в адресе переадресации не может быть регулярок, то есть вот этого: product_id=\[0-9].

 

Думаю, если посмотреть ещё внимательней, то получится найти и другие странности.

 

В общем, вы просто накидали, что в голову пришло, чтоб привести пример того, что не получится переформатировать под nginx

[HyperLabTeam]

15 часов назад, Dotrox сказал:

Я уж было хотел написать, как это будет для nginx, но внимательно посмотрев на этот конфиг, понял, что тут какой-то маразм, при чём полный.

 

Вот эта строка не имеет смысла вообще:

RewriteCond %{HTTP_HOST} ^/product&manufacturer_id=\[0-9]/product_id=\[0-9]$

1. {HTTP_HOST} - это домен! Бессмысленно в нём искать GET параметры.

2. Как можно догадаться, здесь кусок не ЧПУ ссылки, однако он обёрнут в "^/" и  "$", что означает, что это должно быть полное содержимое от начала до конца ссылки.

3. Сам по себе этот кусок ссылки неправильный поскольку не хватает амперсанда между manufacturer_id и product_id.

 

В общем, это условие должно было бы быть разбито на несколько и проверяться должна переменная {REQUEST_URI}, где и находятся все эти параметры.

 

И в следующей строке, где сам редирект, тоже ошибка: там не может быть $2! Если там нужно подставить значение из product_id в RewriteCond, то должно быть %2.

А параметры с долларом - это то, что выдернула регулярка в самом RewriteRule и в данном случае там есть только $1. Чтоб была двойка, должно было быть что-то типа ^(.*)bla-bla(.*)$ (или как в первой строке, которая закомментирована).

Ну, и наконец - в адресе переадресации не может быть регулярок, то есть вот этого: product_id=\[0-9].

 

Думаю, если посмотреть ещё внимательней, то получится найти и другие странности.

 

В общем, вы просто накидали, что в голову пришло, чтоб привести пример того, что не получится переформатировать под nginx

ок
как вы решите вот это
сайт.ру/бренд/товар/
перенаправляем на
сайт.ру/товар/

т.е. ПСы полны ссылками сайт.ру/бренд/товар/
а теперь нужно перенаправить на сайт.ру/товар/

старый и новый оба опенкарта
старый переделан сеопро вместо категории подставляется бренд
теперь при обновлении опенкарта задача использовать то что есть по умочанию т.е. сайт/товар
так же есть старый джумла (там таже беда сайт/бренд/товар  обновляем на опенкарт нужно сайт/товар
Вышеприведённый параметр для .htaccess иные варианты не работают (тот что привел выше работоспособный)
Как  перенаправить этот бред как вы выразились иначе?
покажите пойду проверю
без такого параметра при переходе по ссылке сайт/бренд/товар = 404

Вот вся байда год назад с чукчей разбирали две страницы

Покажите мне НЕмаразм, сэр?))

[Dotrox]

3 часа назад, AWARO сказал:

т.е. ПСы полны ссылками сайт.ру/бренд/товар/
а теперь нужно перенаправить на сайт.ру/товар/

 

Если ссылки ЧПУ, то так:

if (!-d $request_filename){
  set $r 1;
}

if (!-f $request_filename){
  set $r 2$r;
}

if ($r = 21){
  rewrite ^/(.*)/(.*)$ $scheme://$host/$2 permanent;
}

Добавлять просто в блок server.

 

Я думаю, можно придумать и что-то более элегантное, но без if-оф через location у меня сходу без косяков не получилось. А в этом варианте, вроде, никаких проблем быть не должно.

[HyperLabTeam]

2 часа назад, Dotrox сказал:

 

Если ссылки ЧПУ, то так:

if (!-d $request_filename){
  set $r 1;
}

if (!-f $request_filename){
  set $r 2$r;
}

if ($r = 21){
  rewrite ^/(.*)/(.*)$ $scheme://$host/$2 permanent;
}

Добавлять просто в блок server.

 

Я думаю, можно придумать и что-то более элегантное, но без if-оф через location у меня сходу без косяков не получилось. А в этом варианте, вроде, никаких проблем быть не должно.

Вот спасибо)
как поймаю время потестю - отпишусь, надо в закладки тему загнать
Спасибо ещё раз)