Rashp Опубліковано: 20 лютого 2017 Share Опубліковано: 20 лютого 2017 (змінено) Други здравствуйте, умумукался искать ошибку, решил курнуть на форуме ) короче ситуевина такая: Виснет апач, не проходят заказы, если дернуть версию php и перезагрузить httpd поисходят чудеса, заказы прилетают кажные 20-30 минут но в течение 2 часов, потом опять зависает ( как лечить х.з. техподдержку затераризировал, толку ноль. пациент-mirchulok.ru новый хостинг не предлагать, уже 4-й меняю, сейчас vds на админвпс Змінено 20 лютого 2017 користувачем Rashp Надіслати Поділитися на інших сайтах More sharing options...
kJlukOo Опубліковано: 20 лютого 2017 Share Опубліковано: 20 лютого 2017 а что там по логам сервера? 1 Надіслати Поділитися на інших сайтах More sharing options... Rashp Опубліковано: 20 лютого 2017 Автор Share Опубліковано: 20 лютого 2017 в основном фигня, когда сервант передергиваю [Mon Feb 20 17:22:01.580512 2017] [mpm_prefork:notice] [pid 28573] AH00171: Graceful restart requested, doing restart [Mon Feb 20 17:22:01.895060 2017] [auth_digest:notice] [pid 28573] AH01757: generating secret for digest authentication ... [Mon Feb 20 17:22:01.896048 2017] [lbmethod_heartbeat:notice] [pid 28573] AH02282: No slotmem from mod_heartmonitor [Mon Feb 20 17:22:02.132775 2017] [mpm_prefork:notice] [pid 28573] AH00163: Apache/2.4.6 (CentOS) mpm-itk/2.4.7-01 OpenSSL/1.0.1e-fips PHP/5.4.16 configured -- resuming normal operations [Mon Feb 20 17:22:02.132803 2017] [core:notice] [pid 28573] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND' [Mon Feb 20 17:22:22.994592 2017] [mpm_prefork:notice] [pid 28573] AH00171: Graceful restart requested, doing restart [Mon Feb 20 17:22:23.161353 2017] [auth_digest:notice] [pid 28573] AH01757: generating secret for digest authentication ... [Mon Feb 20 17:22:23.163255 2017] [lbmethod_heartbeat:notice] [pid 28573] AH02282: No slotmem from mod_heartmonitor [Mon Feb 20 17:22:23.239896 2017] [mpm_prefork:notice] [pid 28573] AH00163: Apache/2.4.6 (CentOS) mpm-itk/2.4.7-01 OpenSSL/1.0.1e-fips PHP/5.4.16 configured -- resuming normal operations [Mon Feb 20 17:22:23.239916 2017] [core:notice] [pid 28573] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND' [Mon Feb 20 17:22:47.780597 2017] [mpm_prefork:notice] [pid 28573] AH00170: caught SIGWINCH, shutting down gracefully [Mon Feb 20 17:22:48.898034 2017] [suexec:notice] [pid 9803] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Mon Feb 20 17:22:48.927188 2017] [auth_digest:notice] [pid 9803] AH01757: generating secret for digest authentication ... [Mon Feb 20 17:22:48.927813 2017] [lbmethod_heartbeat:notice] [pid 9803] AH02282: No slotmem from mod_heartmonitor [Mon Feb 20 17:22:48.967815 2017] [mpm_prefork:notice] [pid 9803] AH00163: Apache/2.4.6 (CentOS) mpm-itk/2.4.7-01 OpenSSL/1.0.1e-fips PHP/5.4.16 configured -- resuming normal operations [Mon Feb 20 17:22:48.967843 2017] [core:notice] [pid 9803] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND' [Mon Feb 20 17:25:59.163502 2017] [mpm_prefork:error] [pid 9803] AH00161: server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 20 лютого 2017 Share Опубліковано: 20 лютого 2017 Если у вас VDS, лучше вообще откажитесь от Апача - php-fpm будет работать намного быстрее. А проблема, вероятно, в этом: server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting У вас закончились свободные воркеры. Если на сервере достаточно оперативки, можно увеличить их количество в конфиге. Надіслати Поділитися на інших сайтах More sharing options... Otvet Опубліковано: 20 лютого 2017 Share Опубліковано: 20 лютого 2017 на ДДОСинг проверяли? либо какая то кривая рекурсия Надіслати Поділитися на інших сайтах More sharing options... Rashp Опубліковано: 20 лютого 2017 Автор Share Опубліковано: 20 лютого 2017 47 минут назад, Dotrox сказал: Если у вас VDS, лучше вообще откажитесь от Апача - php-fpm будет работать намного быстрее. А проблема, вероятно, в этом: server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting У вас закончились свободные воркеры. Если на сервере достаточно оперативки, можно увеличить их количество в конфиге. Попробую, оперативки там 4 гб, должно по идее хватить, спасиб за наводку. На php-fpm сам не перееду к сожалению, для меня сложновато. Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 20 лютого 2017 Share Опубліковано: 20 лютого 2017 2 минуты назад, Rashp сказал: На php-fpm сам не перееду к сожалению, для меня сложновато. Нужно просто установить php-fpm и поправить конфиги nginx, чтоб он проксировал php запросы на сокет php-fpm, а не на Апач. Ну, и содержимое .htaccess перенести в конфиг nginx (конечно, в формате nginx, а не Апача). Ну, или можете обратиться ко мне Надіслати Поділитися на інших сайтах More sharing options... Rashp Опубліковано: 20 лютого 2017 Автор Share Опубліковано: 20 лютого 2017 я правильно понимаю, что надо править MaxRequestWorkers в mpm_prefork.conf? у меня сейчас там такие значения: <IfModule prefork.c> StartServers 1 MinSpareServers 1 MaxSpareServers 5 ServerLimit 10 MaxClients 10 MaxRequestsPerChild 4000 </IfModule> 18 минут назад, Dotrox сказал: Нужно просто установить php-fpm и поправить конфиги nginx, чтоб он проксировал php запросы на сокет php-fpm, а не на Апач. Ну, и содержимое .htaccess перенести в конфиг nginx (конечно, в формате nginx, а не Апача). Ну, или можете обратиться ко мне в личку давайте перейдем по этому вопросу Надіслати Поділитися на інших сайтах More sharing options... Rashp Опубліковано: 20 лютого 2017 Автор Share Опубліковано: 20 лютого 2017 Отправил в личку Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 20 лютого 2017 Share Опубліковано: 20 лютого 2017 А какая у вас версия Апача? Параметр MaxRequestWorkers появился в 2.4, а у вас, похоже, конфиг от более старой версии, где оно называлось MaxClients. Если у вас 2.4, приведите этот блок к такому виду: <IfModule mpm_prefork_module> StartServers 1 MinSpareServers 1 MaxSpareServers 10 MaxRequestWorkers 100 ServerLimit 100 MaxConnectionsPerChild 300 </IfModule> А дальше смотрите появляется ли ошибка и сколько памяти свободно. Если ошибка будет повторяться, но есть свободная память, увеличивайте значения MaxRequestWorkers и ServerLimit на равные числа пока либо не исчезнет ошибка, либо не закончится память (и тогда только переход на php-fpm, воркеры которого потребляют памяти до 10 раз меньше, чем у Апача). Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 21 лютого 2017 Share Опубліковано: 21 лютого 2017 (змінено) В 20.02.2017 в 18:32, Dotrox сказал: лучше вообще откажитесь от Апача - php-fpm будет работать намного быстрее. чем можно подтвердить данную концепцию? желательно в цифрах. И при конкретных входных данных, учитывая количество просмотров, одновременных подключений и т. п. Любопытно было бы глянуть на авторитетные исследования по этому поводу. В сравнении, разумеется, разных вариантов при разных входных параметрах. С какого момента (по загруженности) начинает ощущаться разница в концепциях? Минусы? Змінено 21 лютого 2017 користувачем sitecreator Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 21 лютого 2017 Share Опубліковано: 21 лютого 2017 23 минуты назад, sitecreator сказал: чем можно подтвердить данную концепцию? желательно в цифрах. Видимо, вы никогда с php-fpm не работали, иначе вопросов бы не возникало. Но вот вам цифры: https://www.cloudways.com/blog/php-fpm-on-cloud/ И маленький экскурс в историю: php-fpm был разработан в Badoo для их хайлоада, то есть его изначальной задачей была именно производительность. Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 22 лютого 2017 Share Опубліковано: 22 лютого 2017 Практического интереса ради переключил один проект на nginx+php-fpm. Товаров, в принципе, не очень то и много пока, всего примерно 16000. Но ожидается нагрузка весной, товар сезонный. Несколько неудобно, что нельзя использовать привычные .htaccess. И все, что связано с rewrite (для того же ЧПУ) нужно прописывать отдельно в .config для определенного хоста, да и правила записи rewrite для nginx отличны от Апаче. Возникает вопрос: а нужен ли тогда Апаче? Для чего собственно если nginx+php-fpm так прекрасен? И насколько быстрее работает связка nginx+php-fpm чем Apache MPM-ITK+php как модуль? или быстрее связки Apache MPM-ITK +php как модуль + nginx? Можно ли принять за правило рекомендовать всегда для Опенкарт связку nginx+php-fpm в случае VPS/VDS? Понятное дело, что на шеаред хост-площадках это неактуально потому, что выбор невозможен. Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 22 лютого 2017 Share Опубліковано: 22 лютого 2017 1 час назад, sitecreator сказал: Можно ли принять за правило рекомендовать всегда для Опенкарт связку nginx+php-fpm в случае VPS/VDS? Ну, лично я когда кого-то перевожу с шареда на VDS, то это исключительно nginx+php-fpm, а Апач на сервер принципиально не ставлю. У первого, переехавшего на такую связку клиента, уже где-то года полтора прошло с момента переезда и никаких проблем за это время не возникало. 1 час назад, sitecreator сказал: Несколько неудобно, что нельзя использовать привычные .htaccess. Это с непривычки. На самом деле, конфиги nginx значительно удобней и логичней. 1 час назад, sitecreator сказал: Возникает вопрос: а нужен ли тогда Апаче? Для чего собственно если nginx+php-fpm так прекрасен? Не нужен. По крайней мере для ОК и любого другого php сайта. Не буду утверждать, что его существование вообще бессмысленно, думаю, есть варианты, где без него не обойтись, но не в случае php. Как я уже сказал, я на VDS в принципе Апач никогда не ставлю. Для php есть nginx+php-fpm, для Python - nginx+uWSGI. 1 Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 22 лютого 2017 Share Опубліковано: 22 лютого 2017 Интересно, какой приоритет (по производительности) в выборе: 1) nginx+php-fpm 2) апаче + php (модуль) + nginx 3) апаче + php (CGI) + nginx В плане производительности 1-й наиболее производителен, последний - наименее. Верно? Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 22 лютого 2017 Share Опубліковано: 22 лютого 2017 47 минут назад, Dotrox сказал: Ну, лично я когда кого-то перевожу с шареда на VDS, то это исключительно nginx+php-fpm, а Апач на сервер принципиально не ставлю. Мне вот такой вариант (с вашей подачи) сразу понравился. думаю, что от Апаче тоже откажусь и в будущих проектах. Он громоздкий, кроме авторизации средствами Апаче полезным вроде бы и не выделяется, а для Опенкарт такая авторизация неактуальна. Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 22 лютого 2017 Share Опубліковано: 22 лютого 2017 1 час назад, sitecreator сказал: В плане производительности 1-й наиболее производителен, последний - наименее. Верно? На счёт первого - да, а вот следующие два в каком порядке расставить я затрудняюсь ответить. Но, вроде, mod_php таки должен быть быстрее в виду большего родства с самим Апачем (в смысле, что интерпретатор запускается в процессе самого Апача). И кстати, логичнее nginx в различных связках всегда ставить на первое место, поскольку именно он встречает запросы на входе. 1 час назад, sitecreator сказал: кроме авторизации средствами Апаче полезным вроде бы и не выделяется Если речь идёт о запароливании пути средствами сервера, то nginx и это умеет: http://nginx.org/ru/docs/http/ngx_http_auth_basic_module.html Вообще, за несколько лет использования nginx в качестве полной замены Апача я ещё не сталкивался с функциями, которые были бы только у Апача, но не у nginx. 1 Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 23 лютого 2017 Share Опубліковано: 23 лютого 2017 Удавалось ли использовать кеширование средствами nginx для контента, генерируемого за счет php? Это в принципе возможно для Опенкарт? Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 23 лютого 2017 Share Опубліковано: 23 лютого 2017 2 часа назад, sitecreator сказал: Удавалось ли использовать кеширование средствами nginx для контента, генерируемого за счет php? Я немного игрался с этим, но на ОК не испытывал. Могу только сказать, что оно работает и со стороны nginx каких-либо сложностей там нет. 1 час назад, sitecreator сказал: Это в принципе возможно для Опенкарт? Возможно. Можно даже особо не трогать сам ОК, а просто указать nginx список правил запрещающих кеширование: адреса страниц, типы запросов (POST, например, точно лучше не кешировать) и т.д.. Для этого есть директивы fastcgi_cache_bypass и fastcgi_no_cache. Первая говорит nginx игнорировать существующий файл кеша и запрашивать ответ у php, а вторая говорит этот ответ не кешировать. Только условия надо проверять предварительно, а в эти директивы уже передать бинарное значение. Правда, как минимум корзину всё же придётся подправить, чтоб она загружалась аяксом не только при добавлении/удалении товара, но и при обновлении страницы. И то же самое с любым контентом, который может меняться из-за действий пользователя, но является частью страниц, которым кеширование запретить нельзя. Например, тот же модуль просмотренных, он может быть на любой странице, а его контент меняется в процессе переходов пользователя по магазину. Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 (змінено) Потратил несколько дней на серьезное изучение nginx + php-fpm. Всплыли некоторые особенности, о которых не думаешь вообще когда у вас установлен апаче + php (модуль) . Так, в частности, решения (модули) для работы по протоколу 1С CommerceML 2 без проблем (и лишних телодвижений и настроек) функционируют только в случае [nginx] + апаче + php (модуль). nginx в квадратных скобках означает, что он может быть, а может и отсутствовать. В случае работы php в режиме CGI/FastCGI с использованием Апаче или без него ( nginx+php-fpm ) нужны дополнительные настройки, а также может понадобиться некоторое изменение файлов Опенкарт, отвечающих за связь по протоколу 1С. Мне пришлось делать изменения в файлах в дополнение к настройкам в случае nginx+php-fpm. Вообще никакого описания настроек и необходимых изменений в случае если у вас не [nginx] + апаче + php (модуль) поставщиком файлов (exchange 1c, обмен с 1С) не предусмотрено. Та же "Большая птица", к примеру, предлагающая организацию складского и бух. учета (все по протоколу 1С) никакой документации в случае использования "нестандартного" сервера не предлагает. Но если не делать дополнительных настроек/изменений, то будет ситуация (со стороны 1С), что связь будет невозможна ("неверно указан адрес сайта" или "неверные логин/пароль"). Повторюсь, что эти сервисы складского и торгового учета (класс 365, Мой склад, Большая птица и т. д.), основанные на протоколе обмена 1С, никаких решений для "нестандартный" серверов не предлагают и даже в форуме поддержки слабо обращают внимание на данный вопрос. Решение для случая [nginx] + апаче + php (CGI/FastCGI) если работает описано здесь (для битрикса, разумеется): Не работает авторизация при обмене данными с 1С В Опенкарт поступаем аналогично. В случае nginx+php-fpm нужно в конфиге хоста добавить в блок обработки php строку: fastcgi_param REMOTE_USER $http_authorization; Тогда http авторизация будет работать. --------------------------------------------- Но в случае nginx+php-fpm открылись некоторые совершенно необъяснимые пока моменты. Например, при использовании файла .user.ini некоторые строки в нем игнорируются. display_errors = Off Вот это никак не работает в случае nginx+php-fpm. Хотя в случае апаче + php (в любом варианте) работает. memory_limit = 64M Это (да и многие другие директивы) работает, а отключение вывода ошибок не работает! Более того, не работает в коде php отключение ошибок: ini_set('display_errors', '0'); Также не работает в .user.ini в случае nginx+php-fpm и это: max_execution_time = 500 Если посмотреть мануал: http://php.net/manual/ru/errorfunc.configuration.php Я не смог отключить никаким образом мешающие nitice кроме одного способа: подавлением в самом коде за счет @ Вообще получил с показом ошибок пока непонятную ситуацию. Во всех php.ini файлах display_errors установлен в Off (0), причем настройки делались из ispmanager или вручную, но phpinfo неумолимо показывал, что во всех файлах php.ini отображение ошибок включено. Я не смог их отключить! php не реагирует на параметры ini файла! Повторюсь, что такое странное поведение с некоторыми директивами характерно только в случае php как FPM/FastCGI и nginx. В случае php как модуля апаче или апаче+ php (fastCGI) такой проблемы не возникает. Объяснения пока не нашел. Сталкивались ли с подобным? Змінено 1 березня 2017 користувачем sitecreator 1 Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 По поводу отключения показа ошибок. из .user.ini считываются изменения не мгновенно, они кешируются на время, которое можно менять. Это мне известно. Другие директивы ведь отрабатываются, поэтому грешить на кеширование или отсутствие перезагрузки веб-сервера не стоит. К тому же ради экспериментов установил время кеширования в 1 сек для файлов .user.ini. Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 Единственное, что приходит в голову - это php_admin_flag и php_admin_value. Если где-то через них установлен показ ошибок, то никак это переопределить не получится. Надіслати Поділитися на інших сайтах More sharing options... Yoda Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 4 часа назад, sitecreator сказал: Потратил несколько дней на серьезное изучение nginx + php-fpm. Всплыли некоторые особенности, о которых не думаешь вообще когда у вас установлен апаче + php (модуль) . Так, в частности, решения (модули) для работы по протоколу 1С CommerceML 2 без проблем (и лишних телодвижений и настроек) функционируют только в случае [nginx] + апаче + php (модуль). nginx в квадратных скобках означает, что он может быть, а может и отсутствовать. В случае работы php в режиме CGI/FastCGI с использованием Апаче или без него ( nginx+php-fpm ) нужны дополнительные настройки, а также может понадобиться некоторое изменение файлов Опенкарт, отвечающих за связь по протоколу 1С. Мне пришлось делать изменения в файлах в дополнение к настройкам в случае nginx+php-fpm. Вообще никакого описания настроек и необходимых изменений в случае если у вас не [nginx] + апаче + php (модуль) поставщиком файлов (exchange 1c, обмен с 1С) не предусмотрено. Та же "Большая птица", к примеру, предлагающая организацию складского и бух. учета (все по протоколу 1С) никакой документации в случае использования "нестандартного" сервера не предлагает. Но если не делать дополнительных настроек/изменений, то будет ситуация (со стороны 1С), что связь будет невозможна ("неверно указан адрес сайта" или "неверные логин/пароль"). Повторюсь, что эти сервисы складского и торгового учета (класс 365, Мой склад, Большая птица и т. д.), основанные на протоколе обмена 1С, никаких решений для "нестандартный" серверов не предлагают и даже в форуме поддержки слабо обращают внимание на данный вопрос. Решение для случая [nginx] + апаче + php (CGI/FastCGI) если работает описано здесь (для битрикса, разумеется): Не работает авторизация при обмене данными с 1С В Опенкарт поступаем аналогично. В случае nginx+php-fpm нужно в конфиге хоста добавить в блок обработки php строку: fastcgi_param REMOTE_USER $http_authorization; Тогда http авторизация будет работать. --------------------------------------------- Но в случае nginx+php-fpm открылись некоторые совершенно необъяснимые пока моменты. Например, при использовании файла .user.ini некоторые строки в нем игнорируются. display_errors = Off Вот это никак не работает в случае nginx+php-fpm. Хотя в случае апаче + php (в любом варианте) работает. memory_limit = 64M Это (да и многие другие директивы) работает, а отключение вывода ошибок не работает! Более того, не работает в коде php отключение ошибок: ini_set('display_errors', '0'); Также не работает в .user.ini в случае nginx+php-fpm и это: max_execution_time = 500 Если посмотреть мануал: http://php.net/manual/ru/errorfunc.configuration.php Я не смог отключить никаким образом мешающие nitice кроме одного способа: подавлением в самом коде за счет @ Вообще получил с показом ошибок пока непонятную ситуацию. Во всех php.ini файлах display_errors установлен в Off (0), причем настройки делались из ispmanager или вручную, но phpinfo неумолимо показывал, что во всех файлах php.ini отображение ошибок включено. Я не смог их отключить! php не реагирует на параметры ini файла! Повторюсь, что такое странное поведение с некоторыми директивами характерно только в случае php как FPM/FastCGI и nginx. В случае php как модуля апаче или апаче+ php (fastCGI) такой проблемы не возникает. Объяснения пока не нашел. Сталкивались ли с подобным? О да!!!! Это жестяная жесть, ставить nginx+phpfpm и пытаться настроить конфиги из ISP менеджера! Я смотрю тут проФФесионалы собрались. Как говорит один мой товарищ, у вас это выглядит как "копрофилия - попробовать можно, но об этом лучше никому не знать"! Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 13 минут назад, Yoda сказал: Это жестяная жесть, ставить nginx+phpfpm и пытаться настроить конфиги из ISP менеджера! Додумали? Разумеется, что прописывались вручную. Через блокнотик, встроенный в ISPmanager. Разве из контекста не видно, что конфиги вручную правились? Просто привел для примера, что по умолчанию ispmanager, видимо, косячит иногда с конфигами. не более того. Богатый ли у вас опыт работы с nginx+phpfpm? Поделиться советом не желаете? Надіслати Поділитися на інших сайтах More sharing options... Yoda Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 27 минут назад, sitecreator сказал: Додумали? Разумеется, что прописывались вручную. Через блокнотик, встроенный в ISPmanager. Разве из контекста не видно, что конфиги вручную правились? Просто привел для примера, что по умолчанию ispmanager, видимо, косячит иногда с конфигами. не более того. Богатый ли у вас опыт работы с nginx+phpfpm? Поделиться советом не желаете? Нет не желаю. По двум причинам. Во первых к вам и дотроксу я испытываю глубокую личную неприязнь как к проФФесионалам с большой буквы. Во вторых по сути вопроса на 99% проектов прирост производительности настолько ничтожный, что это экономия на спичках. И в силу того что нативно Opencart заточен все-таки под работу в связке apache + mysql а не nginx+phpfpm + mysql, делать в такой конфигурации магазины я крайне не рекомендую никому! А вы сейчас два героя разведете здесь демагогию и начнется волна. А мне вот так надо - а так быстрее. А нифига так не быстрее. Подобное решение уместно абсолютно на высоконагруженных проектах от 100+ одновременных сессий - не вопрос. Актуально более чем. А на средней руки магазин даже в 5 000 хостов в день - это чистой воды погоня за модой и костыли! На те самые 99% магазинов достаточно поставить nginx как проксирующую заглушку, оптимизирующую раздачу статики и забыть про все проблемы с индивидуальным конфигурированием окружения. Надіслати Поділитися на інших сайтах More sharing options... Назад 1 2 Вперед Сторінка 1 з 2 Створіть аккаунт або увійдіть для коментування Ви повинні бути користувачем, щоб залишити коментар Створити обліковий запис Зареєструйтеся для отримання облікового запису. Це просто! Зареєструвати аккаунт Вхід Уже зареєстровані? Увійдіть тут. Вхід зараз Share More sharing options... Передплатники 0 Перейти до списку тем Зараз на сторінці 0 користувачів Ні користувачів, які переглядиють цю сторінку Последние темы Последние дополнения Последние новости Вся активність Головна Разное Курилка Виснет апач Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення SP Telegram повідомлення FREE Автор: spectre Відключити порожні категорії Автор: spectre SEO Автор тексту категорії / фільтра / блогу з датою оновлення контенту + мікророзмітка Автор: radaevich Промо банери в категоріях товарів Автор: IHOR1989 Trend - адаптивний універсальний шаблон Автор: DSV × Уже зареєстровані? Ввійти Реєстрація Ваші замовлення Назад Придбані модулі та шаблони Ваші рахунки Лист очікувань Альтернативні контакти Форум Новини ocStore Назад Офіційний сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Завантажити ocStore Документація Історія версій ocStore Блоги Модулі Шаблони Назад Безкоштовні шаблони Платні шаблони Де купувати модулі? Послуги FAQ OpenCart.Pro Назад Демо Купити Порівняння × Створити... Important Information На нашому сайті використовуються файли cookie і відбувається обробка деяких персональних даних користувачів, щоб поліпшити користувальницький інтерфейс. Щоб дізнатися для чого і які персональні дані ми обробляємо перейдіть за посиланням . Якщо Ви натиснете «Я даю згоду», це означає, що Ви розумієте і приймаєте всі умови, зазначені в цьому Повідомленні про конфіденційність. Я даю згоду
Rashp Опубліковано: 20 лютого 2017 Автор Share Опубліковано: 20 лютого 2017 в основном фигня, когда сервант передергиваю [Mon Feb 20 17:22:01.580512 2017] [mpm_prefork:notice] [pid 28573] AH00171: Graceful restart requested, doing restart [Mon Feb 20 17:22:01.895060 2017] [auth_digest:notice] [pid 28573] AH01757: generating secret for digest authentication ... [Mon Feb 20 17:22:01.896048 2017] [lbmethod_heartbeat:notice] [pid 28573] AH02282: No slotmem from mod_heartmonitor [Mon Feb 20 17:22:02.132775 2017] [mpm_prefork:notice] [pid 28573] AH00163: Apache/2.4.6 (CentOS) mpm-itk/2.4.7-01 OpenSSL/1.0.1e-fips PHP/5.4.16 configured -- resuming normal operations [Mon Feb 20 17:22:02.132803 2017] [core:notice] [pid 28573] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND' [Mon Feb 20 17:22:22.994592 2017] [mpm_prefork:notice] [pid 28573] AH00171: Graceful restart requested, doing restart [Mon Feb 20 17:22:23.161353 2017] [auth_digest:notice] [pid 28573] AH01757: generating secret for digest authentication ... [Mon Feb 20 17:22:23.163255 2017] [lbmethod_heartbeat:notice] [pid 28573] AH02282: No slotmem from mod_heartmonitor [Mon Feb 20 17:22:23.239896 2017] [mpm_prefork:notice] [pid 28573] AH00163: Apache/2.4.6 (CentOS) mpm-itk/2.4.7-01 OpenSSL/1.0.1e-fips PHP/5.4.16 configured -- resuming normal operations [Mon Feb 20 17:22:23.239916 2017] [core:notice] [pid 28573] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND' [Mon Feb 20 17:22:47.780597 2017] [mpm_prefork:notice] [pid 28573] AH00170: caught SIGWINCH, shutting down gracefully [Mon Feb 20 17:22:48.898034 2017] [suexec:notice] [pid 9803] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Mon Feb 20 17:22:48.927188 2017] [auth_digest:notice] [pid 9803] AH01757: generating secret for digest authentication ... [Mon Feb 20 17:22:48.927813 2017] [lbmethod_heartbeat:notice] [pid 9803] AH02282: No slotmem from mod_heartmonitor [Mon Feb 20 17:22:48.967815 2017] [mpm_prefork:notice] [pid 9803] AH00163: Apache/2.4.6 (CentOS) mpm-itk/2.4.7-01 OpenSSL/1.0.1e-fips PHP/5.4.16 configured -- resuming normal operations [Mon Feb 20 17:22:48.967843 2017] [core:notice] [pid 9803] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND' [Mon Feb 20 17:25:59.163502 2017] [mpm_prefork:error] [pid 9803] AH00161: server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting Надіслати Поділитися на інших сайтах More sharing options...
Dotrox Опубліковано: 20 лютого 2017 Share Опубліковано: 20 лютого 2017 Если у вас VDS, лучше вообще откажитесь от Апача - php-fpm будет работать намного быстрее. А проблема, вероятно, в этом: server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting У вас закончились свободные воркеры. Если на сервере достаточно оперативки, можно увеличить их количество в конфиге. Надіслати Поділитися на інших сайтах More sharing options...
Otvet Опубліковано: 20 лютого 2017 Share Опубліковано: 20 лютого 2017 на ДДОСинг проверяли? либо какая то кривая рекурсия Надіслати Поділитися на інших сайтах More sharing options... Rashp Опубліковано: 20 лютого 2017 Автор Share Опубліковано: 20 лютого 2017 47 минут назад, Dotrox сказал: Если у вас VDS, лучше вообще откажитесь от Апача - php-fpm будет работать намного быстрее. А проблема, вероятно, в этом: server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting У вас закончились свободные воркеры. Если на сервере достаточно оперативки, можно увеличить их количество в конфиге. Попробую, оперативки там 4 гб, должно по идее хватить, спасиб за наводку. На php-fpm сам не перееду к сожалению, для меня сложновато. Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 20 лютого 2017 Share Опубліковано: 20 лютого 2017 2 минуты назад, Rashp сказал: На php-fpm сам не перееду к сожалению, для меня сложновато. Нужно просто установить php-fpm и поправить конфиги nginx, чтоб он проксировал php запросы на сокет php-fpm, а не на Апач. Ну, и содержимое .htaccess перенести в конфиг nginx (конечно, в формате nginx, а не Апача). Ну, или можете обратиться ко мне Надіслати Поділитися на інших сайтах More sharing options... Rashp Опубліковано: 20 лютого 2017 Автор Share Опубліковано: 20 лютого 2017 я правильно понимаю, что надо править MaxRequestWorkers в mpm_prefork.conf? у меня сейчас там такие значения: <IfModule prefork.c> StartServers 1 MinSpareServers 1 MaxSpareServers 5 ServerLimit 10 MaxClients 10 MaxRequestsPerChild 4000 </IfModule> 18 минут назад, Dotrox сказал: Нужно просто установить php-fpm и поправить конфиги nginx, чтоб он проксировал php запросы на сокет php-fpm, а не на Апач. Ну, и содержимое .htaccess перенести в конфиг nginx (конечно, в формате nginx, а не Апача). Ну, или можете обратиться ко мне в личку давайте перейдем по этому вопросу Надіслати Поділитися на інших сайтах More sharing options... Rashp Опубліковано: 20 лютого 2017 Автор Share Опубліковано: 20 лютого 2017 Отправил в личку Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 20 лютого 2017 Share Опубліковано: 20 лютого 2017 А какая у вас версия Апача? Параметр MaxRequestWorkers появился в 2.4, а у вас, похоже, конфиг от более старой версии, где оно называлось MaxClients. Если у вас 2.4, приведите этот блок к такому виду: <IfModule mpm_prefork_module> StartServers 1 MinSpareServers 1 MaxSpareServers 10 MaxRequestWorkers 100 ServerLimit 100 MaxConnectionsPerChild 300 </IfModule> А дальше смотрите появляется ли ошибка и сколько памяти свободно. Если ошибка будет повторяться, но есть свободная память, увеличивайте значения MaxRequestWorkers и ServerLimit на равные числа пока либо не исчезнет ошибка, либо не закончится память (и тогда только переход на php-fpm, воркеры которого потребляют памяти до 10 раз меньше, чем у Апача). Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 21 лютого 2017 Share Опубліковано: 21 лютого 2017 (змінено) В 20.02.2017 в 18:32, Dotrox сказал: лучше вообще откажитесь от Апача - php-fpm будет работать намного быстрее. чем можно подтвердить данную концепцию? желательно в цифрах. И при конкретных входных данных, учитывая количество просмотров, одновременных подключений и т. п. Любопытно было бы глянуть на авторитетные исследования по этому поводу. В сравнении, разумеется, разных вариантов при разных входных параметрах. С какого момента (по загруженности) начинает ощущаться разница в концепциях? Минусы? Змінено 21 лютого 2017 користувачем sitecreator Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 21 лютого 2017 Share Опубліковано: 21 лютого 2017 23 минуты назад, sitecreator сказал: чем можно подтвердить данную концепцию? желательно в цифрах. Видимо, вы никогда с php-fpm не работали, иначе вопросов бы не возникало. Но вот вам цифры: https://www.cloudways.com/blog/php-fpm-on-cloud/ И маленький экскурс в историю: php-fpm был разработан в Badoo для их хайлоада, то есть его изначальной задачей была именно производительность. Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 22 лютого 2017 Share Опубліковано: 22 лютого 2017 Практического интереса ради переключил один проект на nginx+php-fpm. Товаров, в принципе, не очень то и много пока, всего примерно 16000. Но ожидается нагрузка весной, товар сезонный. Несколько неудобно, что нельзя использовать привычные .htaccess. И все, что связано с rewrite (для того же ЧПУ) нужно прописывать отдельно в .config для определенного хоста, да и правила записи rewrite для nginx отличны от Апаче. Возникает вопрос: а нужен ли тогда Апаче? Для чего собственно если nginx+php-fpm так прекрасен? И насколько быстрее работает связка nginx+php-fpm чем Apache MPM-ITK+php как модуль? или быстрее связки Apache MPM-ITK +php как модуль + nginx? Можно ли принять за правило рекомендовать всегда для Опенкарт связку nginx+php-fpm в случае VPS/VDS? Понятное дело, что на шеаред хост-площадках это неактуально потому, что выбор невозможен. Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 22 лютого 2017 Share Опубліковано: 22 лютого 2017 1 час назад, sitecreator сказал: Можно ли принять за правило рекомендовать всегда для Опенкарт связку nginx+php-fpm в случае VPS/VDS? Ну, лично я когда кого-то перевожу с шареда на VDS, то это исключительно nginx+php-fpm, а Апач на сервер принципиально не ставлю. У первого, переехавшего на такую связку клиента, уже где-то года полтора прошло с момента переезда и никаких проблем за это время не возникало. 1 час назад, sitecreator сказал: Несколько неудобно, что нельзя использовать привычные .htaccess. Это с непривычки. На самом деле, конфиги nginx значительно удобней и логичней. 1 час назад, sitecreator сказал: Возникает вопрос: а нужен ли тогда Апаче? Для чего собственно если nginx+php-fpm так прекрасен? Не нужен. По крайней мере для ОК и любого другого php сайта. Не буду утверждать, что его существование вообще бессмысленно, думаю, есть варианты, где без него не обойтись, но не в случае php. Как я уже сказал, я на VDS в принципе Апач никогда не ставлю. Для php есть nginx+php-fpm, для Python - nginx+uWSGI. 1 Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 22 лютого 2017 Share Опубліковано: 22 лютого 2017 Интересно, какой приоритет (по производительности) в выборе: 1) nginx+php-fpm 2) апаче + php (модуль) + nginx 3) апаче + php (CGI) + nginx В плане производительности 1-й наиболее производителен, последний - наименее. Верно? Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 22 лютого 2017 Share Опубліковано: 22 лютого 2017 47 минут назад, Dotrox сказал: Ну, лично я когда кого-то перевожу с шареда на VDS, то это исключительно nginx+php-fpm, а Апач на сервер принципиально не ставлю. Мне вот такой вариант (с вашей подачи) сразу понравился. думаю, что от Апаче тоже откажусь и в будущих проектах. Он громоздкий, кроме авторизации средствами Апаче полезным вроде бы и не выделяется, а для Опенкарт такая авторизация неактуальна. Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 22 лютого 2017 Share Опубліковано: 22 лютого 2017 1 час назад, sitecreator сказал: В плане производительности 1-й наиболее производителен, последний - наименее. Верно? На счёт первого - да, а вот следующие два в каком порядке расставить я затрудняюсь ответить. Но, вроде, mod_php таки должен быть быстрее в виду большего родства с самим Апачем (в смысле, что интерпретатор запускается в процессе самого Апача). И кстати, логичнее nginx в различных связках всегда ставить на первое место, поскольку именно он встречает запросы на входе. 1 час назад, sitecreator сказал: кроме авторизации средствами Апаче полезным вроде бы и не выделяется Если речь идёт о запароливании пути средствами сервера, то nginx и это умеет: http://nginx.org/ru/docs/http/ngx_http_auth_basic_module.html Вообще, за несколько лет использования nginx в качестве полной замены Апача я ещё не сталкивался с функциями, которые были бы только у Апача, но не у nginx. 1 Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 23 лютого 2017 Share Опубліковано: 23 лютого 2017 Удавалось ли использовать кеширование средствами nginx для контента, генерируемого за счет php? Это в принципе возможно для Опенкарт? Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 23 лютого 2017 Share Опубліковано: 23 лютого 2017 2 часа назад, sitecreator сказал: Удавалось ли использовать кеширование средствами nginx для контента, генерируемого за счет php? Я немного игрался с этим, но на ОК не испытывал. Могу только сказать, что оно работает и со стороны nginx каких-либо сложностей там нет. 1 час назад, sitecreator сказал: Это в принципе возможно для Опенкарт? Возможно. Можно даже особо не трогать сам ОК, а просто указать nginx список правил запрещающих кеширование: адреса страниц, типы запросов (POST, например, точно лучше не кешировать) и т.д.. Для этого есть директивы fastcgi_cache_bypass и fastcgi_no_cache. Первая говорит nginx игнорировать существующий файл кеша и запрашивать ответ у php, а вторая говорит этот ответ не кешировать. Только условия надо проверять предварительно, а в эти директивы уже передать бинарное значение. Правда, как минимум корзину всё же придётся подправить, чтоб она загружалась аяксом не только при добавлении/удалении товара, но и при обновлении страницы. И то же самое с любым контентом, который может меняться из-за действий пользователя, но является частью страниц, которым кеширование запретить нельзя. Например, тот же модуль просмотренных, он может быть на любой странице, а его контент меняется в процессе переходов пользователя по магазину. Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 (змінено) Потратил несколько дней на серьезное изучение nginx + php-fpm. Всплыли некоторые особенности, о которых не думаешь вообще когда у вас установлен апаче + php (модуль) . Так, в частности, решения (модули) для работы по протоколу 1С CommerceML 2 без проблем (и лишних телодвижений и настроек) функционируют только в случае [nginx] + апаче + php (модуль). nginx в квадратных скобках означает, что он может быть, а может и отсутствовать. В случае работы php в режиме CGI/FastCGI с использованием Апаче или без него ( nginx+php-fpm ) нужны дополнительные настройки, а также может понадобиться некоторое изменение файлов Опенкарт, отвечающих за связь по протоколу 1С. Мне пришлось делать изменения в файлах в дополнение к настройкам в случае nginx+php-fpm. Вообще никакого описания настроек и необходимых изменений в случае если у вас не [nginx] + апаче + php (модуль) поставщиком файлов (exchange 1c, обмен с 1С) не предусмотрено. Та же "Большая птица", к примеру, предлагающая организацию складского и бух. учета (все по протоколу 1С) никакой документации в случае использования "нестандартного" сервера не предлагает. Но если не делать дополнительных настроек/изменений, то будет ситуация (со стороны 1С), что связь будет невозможна ("неверно указан адрес сайта" или "неверные логин/пароль"). Повторюсь, что эти сервисы складского и торгового учета (класс 365, Мой склад, Большая птица и т. д.), основанные на протоколе обмена 1С, никаких решений для "нестандартный" серверов не предлагают и даже в форуме поддержки слабо обращают внимание на данный вопрос. Решение для случая [nginx] + апаче + php (CGI/FastCGI) если работает описано здесь (для битрикса, разумеется): Не работает авторизация при обмене данными с 1С В Опенкарт поступаем аналогично. В случае nginx+php-fpm нужно в конфиге хоста добавить в блок обработки php строку: fastcgi_param REMOTE_USER $http_authorization; Тогда http авторизация будет работать. --------------------------------------------- Но в случае nginx+php-fpm открылись некоторые совершенно необъяснимые пока моменты. Например, при использовании файла .user.ini некоторые строки в нем игнорируются. display_errors = Off Вот это никак не работает в случае nginx+php-fpm. Хотя в случае апаче + php (в любом варианте) работает. memory_limit = 64M Это (да и многие другие директивы) работает, а отключение вывода ошибок не работает! Более того, не работает в коде php отключение ошибок: ini_set('display_errors', '0'); Также не работает в .user.ini в случае nginx+php-fpm и это: max_execution_time = 500 Если посмотреть мануал: http://php.net/manual/ru/errorfunc.configuration.php Я не смог отключить никаким образом мешающие nitice кроме одного способа: подавлением в самом коде за счет @ Вообще получил с показом ошибок пока непонятную ситуацию. Во всех php.ini файлах display_errors установлен в Off (0), причем настройки делались из ispmanager или вручную, но phpinfo неумолимо показывал, что во всех файлах php.ini отображение ошибок включено. Я не смог их отключить! php не реагирует на параметры ini файла! Повторюсь, что такое странное поведение с некоторыми директивами характерно только в случае php как FPM/FastCGI и nginx. В случае php как модуля апаче или апаче+ php (fastCGI) такой проблемы не возникает. Объяснения пока не нашел. Сталкивались ли с подобным? Змінено 1 березня 2017 користувачем sitecreator 1 Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 По поводу отключения показа ошибок. из .user.ini считываются изменения не мгновенно, они кешируются на время, которое можно менять. Это мне известно. Другие директивы ведь отрабатываются, поэтому грешить на кеширование или отсутствие перезагрузки веб-сервера не стоит. К тому же ради экспериментов установил время кеширования в 1 сек для файлов .user.ini. Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 Единственное, что приходит в голову - это php_admin_flag и php_admin_value. Если где-то через них установлен показ ошибок, то никак это переопределить не получится. Надіслати Поділитися на інших сайтах More sharing options... Yoda Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 4 часа назад, sitecreator сказал: Потратил несколько дней на серьезное изучение nginx + php-fpm. Всплыли некоторые особенности, о которых не думаешь вообще когда у вас установлен апаче + php (модуль) . Так, в частности, решения (модули) для работы по протоколу 1С CommerceML 2 без проблем (и лишних телодвижений и настроек) функционируют только в случае [nginx] + апаче + php (модуль). nginx в квадратных скобках означает, что он может быть, а может и отсутствовать. В случае работы php в режиме CGI/FastCGI с использованием Апаче или без него ( nginx+php-fpm ) нужны дополнительные настройки, а также может понадобиться некоторое изменение файлов Опенкарт, отвечающих за связь по протоколу 1С. Мне пришлось делать изменения в файлах в дополнение к настройкам в случае nginx+php-fpm. Вообще никакого описания настроек и необходимых изменений в случае если у вас не [nginx] + апаче + php (модуль) поставщиком файлов (exchange 1c, обмен с 1С) не предусмотрено. Та же "Большая птица", к примеру, предлагающая организацию складского и бух. учета (все по протоколу 1С) никакой документации в случае использования "нестандартного" сервера не предлагает. Но если не делать дополнительных настроек/изменений, то будет ситуация (со стороны 1С), что связь будет невозможна ("неверно указан адрес сайта" или "неверные логин/пароль"). Повторюсь, что эти сервисы складского и торгового учета (класс 365, Мой склад, Большая птица и т. д.), основанные на протоколе обмена 1С, никаких решений для "нестандартный" серверов не предлагают и даже в форуме поддержки слабо обращают внимание на данный вопрос. Решение для случая [nginx] + апаче + php (CGI/FastCGI) если работает описано здесь (для битрикса, разумеется): Не работает авторизация при обмене данными с 1С В Опенкарт поступаем аналогично. В случае nginx+php-fpm нужно в конфиге хоста добавить в блок обработки php строку: fastcgi_param REMOTE_USER $http_authorization; Тогда http авторизация будет работать. --------------------------------------------- Но в случае nginx+php-fpm открылись некоторые совершенно необъяснимые пока моменты. Например, при использовании файла .user.ini некоторые строки в нем игнорируются. display_errors = Off Вот это никак не работает в случае nginx+php-fpm. Хотя в случае апаче + php (в любом варианте) работает. memory_limit = 64M Это (да и многие другие директивы) работает, а отключение вывода ошибок не работает! Более того, не работает в коде php отключение ошибок: ini_set('display_errors', '0'); Также не работает в .user.ini в случае nginx+php-fpm и это: max_execution_time = 500 Если посмотреть мануал: http://php.net/manual/ru/errorfunc.configuration.php Я не смог отключить никаким образом мешающие nitice кроме одного способа: подавлением в самом коде за счет @ Вообще получил с показом ошибок пока непонятную ситуацию. Во всех php.ini файлах display_errors установлен в Off (0), причем настройки делались из ispmanager или вручную, но phpinfo неумолимо показывал, что во всех файлах php.ini отображение ошибок включено. Я не смог их отключить! php не реагирует на параметры ini файла! Повторюсь, что такое странное поведение с некоторыми директивами характерно только в случае php как FPM/FastCGI и nginx. В случае php как модуля апаче или апаче+ php (fastCGI) такой проблемы не возникает. Объяснения пока не нашел. Сталкивались ли с подобным? О да!!!! Это жестяная жесть, ставить nginx+phpfpm и пытаться настроить конфиги из ISP менеджера! Я смотрю тут проФФесионалы собрались. Как говорит один мой товарищ, у вас это выглядит как "копрофилия - попробовать можно, но об этом лучше никому не знать"! Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 13 минут назад, Yoda сказал: Это жестяная жесть, ставить nginx+phpfpm и пытаться настроить конфиги из ISP менеджера! Додумали? Разумеется, что прописывались вручную. Через блокнотик, встроенный в ISPmanager. Разве из контекста не видно, что конфиги вручную правились? Просто привел для примера, что по умолчанию ispmanager, видимо, косячит иногда с конфигами. не более того. Богатый ли у вас опыт работы с nginx+phpfpm? Поделиться советом не желаете? Надіслати Поділитися на інших сайтах More sharing options... Yoda Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 27 минут назад, sitecreator сказал: Додумали? Разумеется, что прописывались вручную. Через блокнотик, встроенный в ISPmanager. Разве из контекста не видно, что конфиги вручную правились? Просто привел для примера, что по умолчанию ispmanager, видимо, косячит иногда с конфигами. не более того. Богатый ли у вас опыт работы с nginx+phpfpm? Поделиться советом не желаете? Нет не желаю. По двум причинам. Во первых к вам и дотроксу я испытываю глубокую личную неприязнь как к проФФесионалам с большой буквы. Во вторых по сути вопроса на 99% проектов прирост производительности настолько ничтожный, что это экономия на спичках. И в силу того что нативно Opencart заточен все-таки под работу в связке apache + mysql а не nginx+phpfpm + mysql, делать в такой конфигурации магазины я крайне не рекомендую никому! А вы сейчас два героя разведете здесь демагогию и начнется волна. А мне вот так надо - а так быстрее. А нифига так не быстрее. Подобное решение уместно абсолютно на высоконагруженных проектах от 100+ одновременных сессий - не вопрос. Актуально более чем. А на средней руки магазин даже в 5 000 хостов в день - это чистой воды погоня за модой и костыли! На те самые 99% магазинов достаточно поставить nginx как проксирующую заглушку, оптимизирующую раздачу статики и забыть про все проблемы с индивидуальным конфигурированием окружения. Надіслати Поділитися на інших сайтах More sharing options... Назад 1 2 Вперед Сторінка 1 з 2 Створіть аккаунт або увійдіть для коментування Ви повинні бути користувачем, щоб залишити коментар Створити обліковий запис Зареєструйтеся для отримання облікового запису. Це просто! Зареєструвати аккаунт Вхід Уже зареєстровані? Увійдіть тут. Вхід зараз Share More sharing options... Передплатники 0 Перейти до списку тем Зараз на сторінці 0 користувачів Ні користувачів, які переглядиють цю сторінку Последние темы Последние дополнения Последние новости Вся активність Головна Разное Курилка Виснет апач Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення SP Telegram повідомлення FREE Автор: spectre Відключити порожні категорії Автор: spectre SEO Автор тексту категорії / фільтра / блогу з датою оновлення контенту + мікророзмітка Автор: radaevich Промо банери в категоріях товарів Автор: IHOR1989 Trend - адаптивний універсальний шаблон Автор: DSV × Уже зареєстровані? Ввійти Реєстрація Ваші замовлення Назад Придбані модулі та шаблони Ваші рахунки Лист очікувань Альтернативні контакти Форум Новини ocStore Назад Офіційний сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Завантажити ocStore Документація Історія версій ocStore Блоги Модулі Шаблони Назад Безкоштовні шаблони Платні шаблони Де купувати модулі? Послуги FAQ OpenCart.Pro Назад Демо Купити Порівняння × Створити... Important Information На нашому сайті використовуються файли cookie і відбувається обробка деяких персональних даних користувачів, щоб поліпшити користувальницький інтерфейс. Щоб дізнатися для чого і які персональні дані ми обробляємо перейдіть за посиланням . Якщо Ви натиснете «Я даю згоду», це означає, що Ви розумієте і приймаєте всі умови, зазначені в цьому Повідомленні про конфіденційність. Я даю згоду
Rashp Опубліковано: 20 лютого 2017 Автор Share Опубліковано: 20 лютого 2017 47 минут назад, Dotrox сказал: Если у вас VDS, лучше вообще откажитесь от Апача - php-fpm будет работать намного быстрее. А проблема, вероятно, в этом: server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting У вас закончились свободные воркеры. Если на сервере достаточно оперативки, можно увеличить их количество в конфиге. Попробую, оперативки там 4 гб, должно по идее хватить, спасиб за наводку. На php-fpm сам не перееду к сожалению, для меня сложновато. Надіслати Поділитися на інших сайтах More sharing options...
Dotrox Опубліковано: 20 лютого 2017 Share Опубліковано: 20 лютого 2017 2 минуты назад, Rashp сказал: На php-fpm сам не перееду к сожалению, для меня сложновато. Нужно просто установить php-fpm и поправить конфиги nginx, чтоб он проксировал php запросы на сокет php-fpm, а не на Апач. Ну, и содержимое .htaccess перенести в конфиг nginx (конечно, в формате nginx, а не Апача). Ну, или можете обратиться ко мне Надіслати Поділитися на інших сайтах More sharing options...
Rashp Опубліковано: 20 лютого 2017 Автор Share Опубліковано: 20 лютого 2017 я правильно понимаю, что надо править MaxRequestWorkers в mpm_prefork.conf? у меня сейчас там такие значения: <IfModule prefork.c> StartServers 1 MinSpareServers 1 MaxSpareServers 5 ServerLimit 10 MaxClients 10 MaxRequestsPerChild 4000 </IfModule> 18 минут назад, Dotrox сказал: Нужно просто установить php-fpm и поправить конфиги nginx, чтоб он проксировал php запросы на сокет php-fpm, а не на Апач. Ну, и содержимое .htaccess перенести в конфиг nginx (конечно, в формате nginx, а не Апача). Ну, или можете обратиться ко мне в личку давайте перейдем по этому вопросу Надіслати Поділитися на інших сайтах More sharing options...
Rashp Опубліковано: 20 лютого 2017 Автор Share Опубліковано: 20 лютого 2017 Отправил в личку Надіслати Поділитися на інших сайтах More sharing options...
Dotrox Опубліковано: 20 лютого 2017 Share Опубліковано: 20 лютого 2017 А какая у вас версия Апача? Параметр MaxRequestWorkers появился в 2.4, а у вас, похоже, конфиг от более старой версии, где оно называлось MaxClients. Если у вас 2.4, приведите этот блок к такому виду: <IfModule mpm_prefork_module> StartServers 1 MinSpareServers 1 MaxSpareServers 10 MaxRequestWorkers 100 ServerLimit 100 MaxConnectionsPerChild 300 </IfModule> А дальше смотрите появляется ли ошибка и сколько памяти свободно. Если ошибка будет повторяться, но есть свободная память, увеличивайте значения MaxRequestWorkers и ServerLimit на равные числа пока либо не исчезнет ошибка, либо не закончится память (и тогда только переход на php-fpm, воркеры которого потребляют памяти до 10 раз меньше, чем у Апача). Надіслати Поділитися на інших сайтах More sharing options...
sitecreator Опубліковано: 21 лютого 2017 Share Опубліковано: 21 лютого 2017 (змінено) В 20.02.2017 в 18:32, Dotrox сказал: лучше вообще откажитесь от Апача - php-fpm будет работать намного быстрее. чем можно подтвердить данную концепцию? желательно в цифрах. И при конкретных входных данных, учитывая количество просмотров, одновременных подключений и т. п. Любопытно было бы глянуть на авторитетные исследования по этому поводу. В сравнении, разумеется, разных вариантов при разных входных параметрах. С какого момента (по загруженности) начинает ощущаться разница в концепциях? Минусы? Змінено 21 лютого 2017 користувачем sitecreator Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 21 лютого 2017 Share Опубліковано: 21 лютого 2017 23 минуты назад, sitecreator сказал: чем можно подтвердить данную концепцию? желательно в цифрах. Видимо, вы никогда с php-fpm не работали, иначе вопросов бы не возникало. Но вот вам цифры: https://www.cloudways.com/blog/php-fpm-on-cloud/ И маленький экскурс в историю: php-fpm был разработан в Badoo для их хайлоада, то есть его изначальной задачей была именно производительность. Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 22 лютого 2017 Share Опубліковано: 22 лютого 2017 Практического интереса ради переключил один проект на nginx+php-fpm. Товаров, в принципе, не очень то и много пока, всего примерно 16000. Но ожидается нагрузка весной, товар сезонный. Несколько неудобно, что нельзя использовать привычные .htaccess. И все, что связано с rewrite (для того же ЧПУ) нужно прописывать отдельно в .config для определенного хоста, да и правила записи rewrite для nginx отличны от Апаче. Возникает вопрос: а нужен ли тогда Апаче? Для чего собственно если nginx+php-fpm так прекрасен? И насколько быстрее работает связка nginx+php-fpm чем Apache MPM-ITK+php как модуль? или быстрее связки Apache MPM-ITK +php как модуль + nginx? Можно ли принять за правило рекомендовать всегда для Опенкарт связку nginx+php-fpm в случае VPS/VDS? Понятное дело, что на шеаред хост-площадках это неактуально потому, что выбор невозможен. Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 22 лютого 2017 Share Опубліковано: 22 лютого 2017 1 час назад, sitecreator сказал: Можно ли принять за правило рекомендовать всегда для Опенкарт связку nginx+php-fpm в случае VPS/VDS? Ну, лично я когда кого-то перевожу с шареда на VDS, то это исключительно nginx+php-fpm, а Апач на сервер принципиально не ставлю. У первого, переехавшего на такую связку клиента, уже где-то года полтора прошло с момента переезда и никаких проблем за это время не возникало. 1 час назад, sitecreator сказал: Несколько неудобно, что нельзя использовать привычные .htaccess. Это с непривычки. На самом деле, конфиги nginx значительно удобней и логичней. 1 час назад, sitecreator сказал: Возникает вопрос: а нужен ли тогда Апаче? Для чего собственно если nginx+php-fpm так прекрасен? Не нужен. По крайней мере для ОК и любого другого php сайта. Не буду утверждать, что его существование вообще бессмысленно, думаю, есть варианты, где без него не обойтись, но не в случае php. Как я уже сказал, я на VDS в принципе Апач никогда не ставлю. Для php есть nginx+php-fpm, для Python - nginx+uWSGI. 1 Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 22 лютого 2017 Share Опубліковано: 22 лютого 2017 Интересно, какой приоритет (по производительности) в выборе: 1) nginx+php-fpm 2) апаче + php (модуль) + nginx 3) апаче + php (CGI) + nginx В плане производительности 1-й наиболее производителен, последний - наименее. Верно? Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 22 лютого 2017 Share Опубліковано: 22 лютого 2017 47 минут назад, Dotrox сказал: Ну, лично я когда кого-то перевожу с шареда на VDS, то это исключительно nginx+php-fpm, а Апач на сервер принципиально не ставлю. Мне вот такой вариант (с вашей подачи) сразу понравился. думаю, что от Апаче тоже откажусь и в будущих проектах. Он громоздкий, кроме авторизации средствами Апаче полезным вроде бы и не выделяется, а для Опенкарт такая авторизация неактуальна. Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 22 лютого 2017 Share Опубліковано: 22 лютого 2017 1 час назад, sitecreator сказал: В плане производительности 1-й наиболее производителен, последний - наименее. Верно? На счёт первого - да, а вот следующие два в каком порядке расставить я затрудняюсь ответить. Но, вроде, mod_php таки должен быть быстрее в виду большего родства с самим Апачем (в смысле, что интерпретатор запускается в процессе самого Апача). И кстати, логичнее nginx в различных связках всегда ставить на первое место, поскольку именно он встречает запросы на входе. 1 час назад, sitecreator сказал: кроме авторизации средствами Апаче полезным вроде бы и не выделяется Если речь идёт о запароливании пути средствами сервера, то nginx и это умеет: http://nginx.org/ru/docs/http/ngx_http_auth_basic_module.html Вообще, за несколько лет использования nginx в качестве полной замены Апача я ещё не сталкивался с функциями, которые были бы только у Апача, но не у nginx. 1 Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 23 лютого 2017 Share Опубліковано: 23 лютого 2017 Удавалось ли использовать кеширование средствами nginx для контента, генерируемого за счет php? Это в принципе возможно для Опенкарт? Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 23 лютого 2017 Share Опубліковано: 23 лютого 2017 2 часа назад, sitecreator сказал: Удавалось ли использовать кеширование средствами nginx для контента, генерируемого за счет php? Я немного игрался с этим, но на ОК не испытывал. Могу только сказать, что оно работает и со стороны nginx каких-либо сложностей там нет. 1 час назад, sitecreator сказал: Это в принципе возможно для Опенкарт? Возможно. Можно даже особо не трогать сам ОК, а просто указать nginx список правил запрещающих кеширование: адреса страниц, типы запросов (POST, например, точно лучше не кешировать) и т.д.. Для этого есть директивы fastcgi_cache_bypass и fastcgi_no_cache. Первая говорит nginx игнорировать существующий файл кеша и запрашивать ответ у php, а вторая говорит этот ответ не кешировать. Только условия надо проверять предварительно, а в эти директивы уже передать бинарное значение. Правда, как минимум корзину всё же придётся подправить, чтоб она загружалась аяксом не только при добавлении/удалении товара, но и при обновлении страницы. И то же самое с любым контентом, который может меняться из-за действий пользователя, но является частью страниц, которым кеширование запретить нельзя. Например, тот же модуль просмотренных, он может быть на любой странице, а его контент меняется в процессе переходов пользователя по магазину. Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 (змінено) Потратил несколько дней на серьезное изучение nginx + php-fpm. Всплыли некоторые особенности, о которых не думаешь вообще когда у вас установлен апаче + php (модуль) . Так, в частности, решения (модули) для работы по протоколу 1С CommerceML 2 без проблем (и лишних телодвижений и настроек) функционируют только в случае [nginx] + апаче + php (модуль). nginx в квадратных скобках означает, что он может быть, а может и отсутствовать. В случае работы php в режиме CGI/FastCGI с использованием Апаче или без него ( nginx+php-fpm ) нужны дополнительные настройки, а также может понадобиться некоторое изменение файлов Опенкарт, отвечающих за связь по протоколу 1С. Мне пришлось делать изменения в файлах в дополнение к настройкам в случае nginx+php-fpm. Вообще никакого описания настроек и необходимых изменений в случае если у вас не [nginx] + апаче + php (модуль) поставщиком файлов (exchange 1c, обмен с 1С) не предусмотрено. Та же "Большая птица", к примеру, предлагающая организацию складского и бух. учета (все по протоколу 1С) никакой документации в случае использования "нестандартного" сервера не предлагает. Но если не делать дополнительных настроек/изменений, то будет ситуация (со стороны 1С), что связь будет невозможна ("неверно указан адрес сайта" или "неверные логин/пароль"). Повторюсь, что эти сервисы складского и торгового учета (класс 365, Мой склад, Большая птица и т. д.), основанные на протоколе обмена 1С, никаких решений для "нестандартный" серверов не предлагают и даже в форуме поддержки слабо обращают внимание на данный вопрос. Решение для случая [nginx] + апаче + php (CGI/FastCGI) если работает описано здесь (для битрикса, разумеется): Не работает авторизация при обмене данными с 1С В Опенкарт поступаем аналогично. В случае nginx+php-fpm нужно в конфиге хоста добавить в блок обработки php строку: fastcgi_param REMOTE_USER $http_authorization; Тогда http авторизация будет работать. --------------------------------------------- Но в случае nginx+php-fpm открылись некоторые совершенно необъяснимые пока моменты. Например, при использовании файла .user.ini некоторые строки в нем игнорируются. display_errors = Off Вот это никак не работает в случае nginx+php-fpm. Хотя в случае апаче + php (в любом варианте) работает. memory_limit = 64M Это (да и многие другие директивы) работает, а отключение вывода ошибок не работает! Более того, не работает в коде php отключение ошибок: ini_set('display_errors', '0'); Также не работает в .user.ini в случае nginx+php-fpm и это: max_execution_time = 500 Если посмотреть мануал: http://php.net/manual/ru/errorfunc.configuration.php Я не смог отключить никаким образом мешающие nitice кроме одного способа: подавлением в самом коде за счет @ Вообще получил с показом ошибок пока непонятную ситуацию. Во всех php.ini файлах display_errors установлен в Off (0), причем настройки делались из ispmanager или вручную, но phpinfo неумолимо показывал, что во всех файлах php.ini отображение ошибок включено. Я не смог их отключить! php не реагирует на параметры ini файла! Повторюсь, что такое странное поведение с некоторыми директивами характерно только в случае php как FPM/FastCGI и nginx. В случае php как модуля апаче или апаче+ php (fastCGI) такой проблемы не возникает. Объяснения пока не нашел. Сталкивались ли с подобным? Змінено 1 березня 2017 користувачем sitecreator 1 Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 По поводу отключения показа ошибок. из .user.ini считываются изменения не мгновенно, они кешируются на время, которое можно менять. Это мне известно. Другие директивы ведь отрабатываются, поэтому грешить на кеширование или отсутствие перезагрузки веб-сервера не стоит. К тому же ради экспериментов установил время кеширования в 1 сек для файлов .user.ini. Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 Единственное, что приходит в голову - это php_admin_flag и php_admin_value. Если где-то через них установлен показ ошибок, то никак это переопределить не получится. Надіслати Поділитися на інших сайтах More sharing options... Yoda Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 4 часа назад, sitecreator сказал: Потратил несколько дней на серьезное изучение nginx + php-fpm. Всплыли некоторые особенности, о которых не думаешь вообще когда у вас установлен апаче + php (модуль) . Так, в частности, решения (модули) для работы по протоколу 1С CommerceML 2 без проблем (и лишних телодвижений и настроек) функционируют только в случае [nginx] + апаче + php (модуль). nginx в квадратных скобках означает, что он может быть, а может и отсутствовать. В случае работы php в режиме CGI/FastCGI с использованием Апаче или без него ( nginx+php-fpm ) нужны дополнительные настройки, а также может понадобиться некоторое изменение файлов Опенкарт, отвечающих за связь по протоколу 1С. Мне пришлось делать изменения в файлах в дополнение к настройкам в случае nginx+php-fpm. Вообще никакого описания настроек и необходимых изменений в случае если у вас не [nginx] + апаче + php (модуль) поставщиком файлов (exchange 1c, обмен с 1С) не предусмотрено. Та же "Большая птица", к примеру, предлагающая организацию складского и бух. учета (все по протоколу 1С) никакой документации в случае использования "нестандартного" сервера не предлагает. Но если не делать дополнительных настроек/изменений, то будет ситуация (со стороны 1С), что связь будет невозможна ("неверно указан адрес сайта" или "неверные логин/пароль"). Повторюсь, что эти сервисы складского и торгового учета (класс 365, Мой склад, Большая птица и т. д.), основанные на протоколе обмена 1С, никаких решений для "нестандартный" серверов не предлагают и даже в форуме поддержки слабо обращают внимание на данный вопрос. Решение для случая [nginx] + апаче + php (CGI/FastCGI) если работает описано здесь (для битрикса, разумеется): Не работает авторизация при обмене данными с 1С В Опенкарт поступаем аналогично. В случае nginx+php-fpm нужно в конфиге хоста добавить в блок обработки php строку: fastcgi_param REMOTE_USER $http_authorization; Тогда http авторизация будет работать. --------------------------------------------- Но в случае nginx+php-fpm открылись некоторые совершенно необъяснимые пока моменты. Например, при использовании файла .user.ini некоторые строки в нем игнорируются. display_errors = Off Вот это никак не работает в случае nginx+php-fpm. Хотя в случае апаче + php (в любом варианте) работает. memory_limit = 64M Это (да и многие другие директивы) работает, а отключение вывода ошибок не работает! Более того, не работает в коде php отключение ошибок: ini_set('display_errors', '0'); Также не работает в .user.ini в случае nginx+php-fpm и это: max_execution_time = 500 Если посмотреть мануал: http://php.net/manual/ru/errorfunc.configuration.php Я не смог отключить никаким образом мешающие nitice кроме одного способа: подавлением в самом коде за счет @ Вообще получил с показом ошибок пока непонятную ситуацию. Во всех php.ini файлах display_errors установлен в Off (0), причем настройки делались из ispmanager или вручную, но phpinfo неумолимо показывал, что во всех файлах php.ini отображение ошибок включено. Я не смог их отключить! php не реагирует на параметры ini файла! Повторюсь, что такое странное поведение с некоторыми директивами характерно только в случае php как FPM/FastCGI и nginx. В случае php как модуля апаче или апаче+ php (fastCGI) такой проблемы не возникает. Объяснения пока не нашел. Сталкивались ли с подобным? О да!!!! Это жестяная жесть, ставить nginx+phpfpm и пытаться настроить конфиги из ISP менеджера! Я смотрю тут проФФесионалы собрались. Как говорит один мой товарищ, у вас это выглядит как "копрофилия - попробовать можно, но об этом лучше никому не знать"! Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 13 минут назад, Yoda сказал: Это жестяная жесть, ставить nginx+phpfpm и пытаться настроить конфиги из ISP менеджера! Додумали? Разумеется, что прописывались вручную. Через блокнотик, встроенный в ISPmanager. Разве из контекста не видно, что конфиги вручную правились? Просто привел для примера, что по умолчанию ispmanager, видимо, косячит иногда с конфигами. не более того. Богатый ли у вас опыт работы с nginx+phpfpm? Поделиться советом не желаете? Надіслати Поділитися на інших сайтах More sharing options... Yoda Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 27 минут назад, sitecreator сказал: Додумали? Разумеется, что прописывались вручную. Через блокнотик, встроенный в ISPmanager. Разве из контекста не видно, что конфиги вручную правились? Просто привел для примера, что по умолчанию ispmanager, видимо, косячит иногда с конфигами. не более того. Богатый ли у вас опыт работы с nginx+phpfpm? Поделиться советом не желаете? Нет не желаю. По двум причинам. Во первых к вам и дотроксу я испытываю глубокую личную неприязнь как к проФФесионалам с большой буквы. Во вторых по сути вопроса на 99% проектов прирост производительности настолько ничтожный, что это экономия на спичках. И в силу того что нативно Opencart заточен все-таки под работу в связке apache + mysql а не nginx+phpfpm + mysql, делать в такой конфигурации магазины я крайне не рекомендую никому! А вы сейчас два героя разведете здесь демагогию и начнется волна. А мне вот так надо - а так быстрее. А нифига так не быстрее. Подобное решение уместно абсолютно на высоконагруженных проектах от 100+ одновременных сессий - не вопрос. Актуально более чем. А на средней руки магазин даже в 5 000 хостов в день - это чистой воды погоня за модой и костыли! На те самые 99% магазинов достаточно поставить nginx как проксирующую заглушку, оптимизирующую раздачу статики и забыть про все проблемы с индивидуальным конфигурированием окружения. Надіслати Поділитися на інших сайтах More sharing options... Назад 1 2 Вперед Сторінка 1 з 2 Створіть аккаунт або увійдіть для коментування Ви повинні бути користувачем, щоб залишити коментар Створити обліковий запис Зареєструйтеся для отримання облікового запису. Це просто! Зареєструвати аккаунт Вхід Уже зареєстровані? Увійдіть тут. Вхід зараз Share More sharing options... Передплатники 0 Перейти до списку тем Зараз на сторінці 0 користувачів Ні користувачів, які переглядиють цю сторінку Последние темы Последние дополнения Последние новости Вся активність Головна Разное Курилка Виснет апач Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення SP Telegram повідомлення FREE Автор: spectre Відключити порожні категорії Автор: spectre SEO Автор тексту категорії / фільтра / блогу з датою оновлення контенту + мікророзмітка Автор: radaevich Промо банери в категоріях товарів Автор: IHOR1989 Trend - адаптивний універсальний шаблон Автор: DSV × Уже зареєстровані? Ввійти Реєстрація Ваші замовлення Назад Придбані модулі та шаблони Ваші рахунки Лист очікувань Альтернативні контакти Форум Новини ocStore Назад Офіційний сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Завантажити ocStore Документація Історія версій ocStore Блоги Модулі Шаблони Назад Безкоштовні шаблони Платні шаблони Де купувати модулі? Послуги FAQ OpenCart.Pro Назад Демо Купити Порівняння × Створити... Important Information На нашому сайті використовуються файли cookie і відбувається обробка деяких персональних даних користувачів, щоб поліпшити користувальницький інтерфейс. Щоб дізнатися для чого і які персональні дані ми обробляємо перейдіть за посиланням . Якщо Ви натиснете «Я даю згоду», це означає, що Ви розумієте і приймаєте всі умови, зазначені в цьому Повідомленні про конфіденційність. Я даю згоду
Dotrox Опубліковано: 21 лютого 2017 Share Опубліковано: 21 лютого 2017 23 минуты назад, sitecreator сказал: чем можно подтвердить данную концепцию? желательно в цифрах. Видимо, вы никогда с php-fpm не работали, иначе вопросов бы не возникало. Но вот вам цифры: https://www.cloudways.com/blog/php-fpm-on-cloud/ И маленький экскурс в историю: php-fpm был разработан в Badoo для их хайлоада, то есть его изначальной задачей была именно производительность. Надіслати Поділитися на інших сайтах More sharing options...
sitecreator Опубліковано: 22 лютого 2017 Share Опубліковано: 22 лютого 2017 Практического интереса ради переключил один проект на nginx+php-fpm. Товаров, в принципе, не очень то и много пока, всего примерно 16000. Но ожидается нагрузка весной, товар сезонный. Несколько неудобно, что нельзя использовать привычные .htaccess. И все, что связано с rewrite (для того же ЧПУ) нужно прописывать отдельно в .config для определенного хоста, да и правила записи rewrite для nginx отличны от Апаче. Возникает вопрос: а нужен ли тогда Апаче? Для чего собственно если nginx+php-fpm так прекрасен? И насколько быстрее работает связка nginx+php-fpm чем Apache MPM-ITK+php как модуль? или быстрее связки Apache MPM-ITK +php как модуль + nginx? Можно ли принять за правило рекомендовать всегда для Опенкарт связку nginx+php-fpm в случае VPS/VDS? Понятное дело, что на шеаред хост-площадках это неактуально потому, что выбор невозможен. Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 22 лютого 2017 Share Опубліковано: 22 лютого 2017 1 час назад, sitecreator сказал: Можно ли принять за правило рекомендовать всегда для Опенкарт связку nginx+php-fpm в случае VPS/VDS? Ну, лично я когда кого-то перевожу с шареда на VDS, то это исключительно nginx+php-fpm, а Апач на сервер принципиально не ставлю. У первого, переехавшего на такую связку клиента, уже где-то года полтора прошло с момента переезда и никаких проблем за это время не возникало. 1 час назад, sitecreator сказал: Несколько неудобно, что нельзя использовать привычные .htaccess. Это с непривычки. На самом деле, конфиги nginx значительно удобней и логичней. 1 час назад, sitecreator сказал: Возникает вопрос: а нужен ли тогда Апаче? Для чего собственно если nginx+php-fpm так прекрасен? Не нужен. По крайней мере для ОК и любого другого php сайта. Не буду утверждать, что его существование вообще бессмысленно, думаю, есть варианты, где без него не обойтись, но не в случае php. Как я уже сказал, я на VDS в принципе Апач никогда не ставлю. Для php есть nginx+php-fpm, для Python - nginx+uWSGI. 1 Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 22 лютого 2017 Share Опубліковано: 22 лютого 2017 Интересно, какой приоритет (по производительности) в выборе: 1) nginx+php-fpm 2) апаче + php (модуль) + nginx 3) апаче + php (CGI) + nginx В плане производительности 1-й наиболее производителен, последний - наименее. Верно? Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 22 лютого 2017 Share Опубліковано: 22 лютого 2017 47 минут назад, Dotrox сказал: Ну, лично я когда кого-то перевожу с шареда на VDS, то это исключительно nginx+php-fpm, а Апач на сервер принципиально не ставлю. Мне вот такой вариант (с вашей подачи) сразу понравился. думаю, что от Апаче тоже откажусь и в будущих проектах. Он громоздкий, кроме авторизации средствами Апаче полезным вроде бы и не выделяется, а для Опенкарт такая авторизация неактуальна. Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 22 лютого 2017 Share Опубліковано: 22 лютого 2017 1 час назад, sitecreator сказал: В плане производительности 1-й наиболее производителен, последний - наименее. Верно? На счёт первого - да, а вот следующие два в каком порядке расставить я затрудняюсь ответить. Но, вроде, mod_php таки должен быть быстрее в виду большего родства с самим Апачем (в смысле, что интерпретатор запускается в процессе самого Апача). И кстати, логичнее nginx в различных связках всегда ставить на первое место, поскольку именно он встречает запросы на входе. 1 час назад, sitecreator сказал: кроме авторизации средствами Апаче полезным вроде бы и не выделяется Если речь идёт о запароливании пути средствами сервера, то nginx и это умеет: http://nginx.org/ru/docs/http/ngx_http_auth_basic_module.html Вообще, за несколько лет использования nginx в качестве полной замены Апача я ещё не сталкивался с функциями, которые были бы только у Апача, но не у nginx. 1 Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 23 лютого 2017 Share Опубліковано: 23 лютого 2017 Удавалось ли использовать кеширование средствами nginx для контента, генерируемого за счет php? Это в принципе возможно для Опенкарт? Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 23 лютого 2017 Share Опубліковано: 23 лютого 2017 2 часа назад, sitecreator сказал: Удавалось ли использовать кеширование средствами nginx для контента, генерируемого за счет php? Я немного игрался с этим, но на ОК не испытывал. Могу только сказать, что оно работает и со стороны nginx каких-либо сложностей там нет. 1 час назад, sitecreator сказал: Это в принципе возможно для Опенкарт? Возможно. Можно даже особо не трогать сам ОК, а просто указать nginx список правил запрещающих кеширование: адреса страниц, типы запросов (POST, например, точно лучше не кешировать) и т.д.. Для этого есть директивы fastcgi_cache_bypass и fastcgi_no_cache. Первая говорит nginx игнорировать существующий файл кеша и запрашивать ответ у php, а вторая говорит этот ответ не кешировать. Только условия надо проверять предварительно, а в эти директивы уже передать бинарное значение. Правда, как минимум корзину всё же придётся подправить, чтоб она загружалась аяксом не только при добавлении/удалении товара, но и при обновлении страницы. И то же самое с любым контентом, который может меняться из-за действий пользователя, но является частью страниц, которым кеширование запретить нельзя. Например, тот же модуль просмотренных, он может быть на любой странице, а его контент меняется в процессе переходов пользователя по магазину. Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 (змінено) Потратил несколько дней на серьезное изучение nginx + php-fpm. Всплыли некоторые особенности, о которых не думаешь вообще когда у вас установлен апаче + php (модуль) . Так, в частности, решения (модули) для работы по протоколу 1С CommerceML 2 без проблем (и лишних телодвижений и настроек) функционируют только в случае [nginx] + апаче + php (модуль). nginx в квадратных скобках означает, что он может быть, а может и отсутствовать. В случае работы php в режиме CGI/FastCGI с использованием Апаче или без него ( nginx+php-fpm ) нужны дополнительные настройки, а также может понадобиться некоторое изменение файлов Опенкарт, отвечающих за связь по протоколу 1С. Мне пришлось делать изменения в файлах в дополнение к настройкам в случае nginx+php-fpm. Вообще никакого описания настроек и необходимых изменений в случае если у вас не [nginx] + апаче + php (модуль) поставщиком файлов (exchange 1c, обмен с 1С) не предусмотрено. Та же "Большая птица", к примеру, предлагающая организацию складского и бух. учета (все по протоколу 1С) никакой документации в случае использования "нестандартного" сервера не предлагает. Но если не делать дополнительных настроек/изменений, то будет ситуация (со стороны 1С), что связь будет невозможна ("неверно указан адрес сайта" или "неверные логин/пароль"). Повторюсь, что эти сервисы складского и торгового учета (класс 365, Мой склад, Большая птица и т. д.), основанные на протоколе обмена 1С, никаких решений для "нестандартный" серверов не предлагают и даже в форуме поддержки слабо обращают внимание на данный вопрос. Решение для случая [nginx] + апаче + php (CGI/FastCGI) если работает описано здесь (для битрикса, разумеется): Не работает авторизация при обмене данными с 1С В Опенкарт поступаем аналогично. В случае nginx+php-fpm нужно в конфиге хоста добавить в блок обработки php строку: fastcgi_param REMOTE_USER $http_authorization; Тогда http авторизация будет работать. --------------------------------------------- Но в случае nginx+php-fpm открылись некоторые совершенно необъяснимые пока моменты. Например, при использовании файла .user.ini некоторые строки в нем игнорируются. display_errors = Off Вот это никак не работает в случае nginx+php-fpm. Хотя в случае апаче + php (в любом варианте) работает. memory_limit = 64M Это (да и многие другие директивы) работает, а отключение вывода ошибок не работает! Более того, не работает в коде php отключение ошибок: ini_set('display_errors', '0'); Также не работает в .user.ini в случае nginx+php-fpm и это: max_execution_time = 500 Если посмотреть мануал: http://php.net/manual/ru/errorfunc.configuration.php Я не смог отключить никаким образом мешающие nitice кроме одного способа: подавлением в самом коде за счет @ Вообще получил с показом ошибок пока непонятную ситуацию. Во всех php.ini файлах display_errors установлен в Off (0), причем настройки делались из ispmanager или вручную, но phpinfo неумолимо показывал, что во всех файлах php.ini отображение ошибок включено. Я не смог их отключить! php не реагирует на параметры ini файла! Повторюсь, что такое странное поведение с некоторыми директивами характерно только в случае php как FPM/FastCGI и nginx. В случае php как модуля апаче или апаче+ php (fastCGI) такой проблемы не возникает. Объяснения пока не нашел. Сталкивались ли с подобным? Змінено 1 березня 2017 користувачем sitecreator 1 Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 По поводу отключения показа ошибок. из .user.ini считываются изменения не мгновенно, они кешируются на время, которое можно менять. Это мне известно. Другие директивы ведь отрабатываются, поэтому грешить на кеширование или отсутствие перезагрузки веб-сервера не стоит. К тому же ради экспериментов установил время кеширования в 1 сек для файлов .user.ini. Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 Единственное, что приходит в голову - это php_admin_flag и php_admin_value. Если где-то через них установлен показ ошибок, то никак это переопределить не получится. Надіслати Поділитися на інших сайтах More sharing options... Yoda Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 4 часа назад, sitecreator сказал: Потратил несколько дней на серьезное изучение nginx + php-fpm. Всплыли некоторые особенности, о которых не думаешь вообще когда у вас установлен апаче + php (модуль) . Так, в частности, решения (модули) для работы по протоколу 1С CommerceML 2 без проблем (и лишних телодвижений и настроек) функционируют только в случае [nginx] + апаче + php (модуль). nginx в квадратных скобках означает, что он может быть, а может и отсутствовать. В случае работы php в режиме CGI/FastCGI с использованием Апаче или без него ( nginx+php-fpm ) нужны дополнительные настройки, а также может понадобиться некоторое изменение файлов Опенкарт, отвечающих за связь по протоколу 1С. Мне пришлось делать изменения в файлах в дополнение к настройкам в случае nginx+php-fpm. Вообще никакого описания настроек и необходимых изменений в случае если у вас не [nginx] + апаче + php (модуль) поставщиком файлов (exchange 1c, обмен с 1С) не предусмотрено. Та же "Большая птица", к примеру, предлагающая организацию складского и бух. учета (все по протоколу 1С) никакой документации в случае использования "нестандартного" сервера не предлагает. Но если не делать дополнительных настроек/изменений, то будет ситуация (со стороны 1С), что связь будет невозможна ("неверно указан адрес сайта" или "неверные логин/пароль"). Повторюсь, что эти сервисы складского и торгового учета (класс 365, Мой склад, Большая птица и т. д.), основанные на протоколе обмена 1С, никаких решений для "нестандартный" серверов не предлагают и даже в форуме поддержки слабо обращают внимание на данный вопрос. Решение для случая [nginx] + апаче + php (CGI/FastCGI) если работает описано здесь (для битрикса, разумеется): Не работает авторизация при обмене данными с 1С В Опенкарт поступаем аналогично. В случае nginx+php-fpm нужно в конфиге хоста добавить в блок обработки php строку: fastcgi_param REMOTE_USER $http_authorization; Тогда http авторизация будет работать. --------------------------------------------- Но в случае nginx+php-fpm открылись некоторые совершенно необъяснимые пока моменты. Например, при использовании файла .user.ini некоторые строки в нем игнорируются. display_errors = Off Вот это никак не работает в случае nginx+php-fpm. Хотя в случае апаче + php (в любом варианте) работает. memory_limit = 64M Это (да и многие другие директивы) работает, а отключение вывода ошибок не работает! Более того, не работает в коде php отключение ошибок: ini_set('display_errors', '0'); Также не работает в .user.ini в случае nginx+php-fpm и это: max_execution_time = 500 Если посмотреть мануал: http://php.net/manual/ru/errorfunc.configuration.php Я не смог отключить никаким образом мешающие nitice кроме одного способа: подавлением в самом коде за счет @ Вообще получил с показом ошибок пока непонятную ситуацию. Во всех php.ini файлах display_errors установлен в Off (0), причем настройки делались из ispmanager или вручную, но phpinfo неумолимо показывал, что во всех файлах php.ini отображение ошибок включено. Я не смог их отключить! php не реагирует на параметры ini файла! Повторюсь, что такое странное поведение с некоторыми директивами характерно только в случае php как FPM/FastCGI и nginx. В случае php как модуля апаче или апаче+ php (fastCGI) такой проблемы не возникает. Объяснения пока не нашел. Сталкивались ли с подобным? О да!!!! Это жестяная жесть, ставить nginx+phpfpm и пытаться настроить конфиги из ISP менеджера! Я смотрю тут проФФесионалы собрались. Как говорит один мой товарищ, у вас это выглядит как "копрофилия - попробовать можно, но об этом лучше никому не знать"! Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 13 минут назад, Yoda сказал: Это жестяная жесть, ставить nginx+phpfpm и пытаться настроить конфиги из ISP менеджера! Додумали? Разумеется, что прописывались вручную. Через блокнотик, встроенный в ISPmanager. Разве из контекста не видно, что конфиги вручную правились? Просто привел для примера, что по умолчанию ispmanager, видимо, косячит иногда с конфигами. не более того. Богатый ли у вас опыт работы с nginx+phpfpm? Поделиться советом не желаете? Надіслати Поділитися на інших сайтах More sharing options... Yoda Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 27 минут назад, sitecreator сказал: Додумали? Разумеется, что прописывались вручную. Через блокнотик, встроенный в ISPmanager. Разве из контекста не видно, что конфиги вручную правились? Просто привел для примера, что по умолчанию ispmanager, видимо, косячит иногда с конфигами. не более того. Богатый ли у вас опыт работы с nginx+phpfpm? Поделиться советом не желаете? Нет не желаю. По двум причинам. Во первых к вам и дотроксу я испытываю глубокую личную неприязнь как к проФФесионалам с большой буквы. Во вторых по сути вопроса на 99% проектов прирост производительности настолько ничтожный, что это экономия на спичках. И в силу того что нативно Opencart заточен все-таки под работу в связке apache + mysql а не nginx+phpfpm + mysql, делать в такой конфигурации магазины я крайне не рекомендую никому! А вы сейчас два героя разведете здесь демагогию и начнется волна. А мне вот так надо - а так быстрее. А нифига так не быстрее. Подобное решение уместно абсолютно на высоконагруженных проектах от 100+ одновременных сессий - не вопрос. Актуально более чем. А на средней руки магазин даже в 5 000 хостов в день - это чистой воды погоня за модой и костыли! На те самые 99% магазинов достаточно поставить nginx как проксирующую заглушку, оптимизирующую раздачу статики и забыть про все проблемы с индивидуальным конфигурированием окружения. Надіслати Поділитися на інших сайтах More sharing options... Назад 1 2 Вперед Сторінка 1 з 2 Створіть аккаунт або увійдіть для коментування Ви повинні бути користувачем, щоб залишити коментар Створити обліковий запис Зареєструйтеся для отримання облікового запису. Це просто! Зареєструвати аккаунт Вхід Уже зареєстровані? Увійдіть тут. Вхід зараз Share More sharing options... Передплатники 0 Перейти до списку тем Зараз на сторінці 0 користувачів Ні користувачів, які переглядиють цю сторінку Последние темы Последние дополнения Последние новости Вся активність Головна Разное Курилка Виснет апач Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення SP Telegram повідомлення FREE Автор: spectre Відключити порожні категорії Автор: spectre SEO Автор тексту категорії / фільтра / блогу з датою оновлення контенту + мікророзмітка Автор: radaevich Промо банери в категоріях товарів Автор: IHOR1989 Trend - адаптивний універсальний шаблон Автор: DSV × Уже зареєстровані? Ввійти Реєстрація Ваші замовлення Назад Придбані модулі та шаблони Ваші рахунки Лист очікувань Альтернативні контакти Форум Новини ocStore Назад Офіційний сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Завантажити ocStore Документація Історія версій ocStore Блоги Модулі Шаблони Назад Безкоштовні шаблони Платні шаблони Де купувати модулі? Послуги FAQ OpenCart.Pro Назад Демо Купити Порівняння × Створити... Important Information На нашому сайті використовуються файли cookie і відбувається обробка деяких персональних даних користувачів, щоб поліпшити користувальницький інтерфейс. Щоб дізнатися для чого і які персональні дані ми обробляємо перейдіть за посиланням . Якщо Ви натиснете «Я даю згоду», це означає, що Ви розумієте і приймаєте всі умови, зазначені в цьому Повідомленні про конфіденційність. Я даю згоду
Dotrox Опубліковано: 22 лютого 2017 Share Опубліковано: 22 лютого 2017 1 час назад, sitecreator сказал: Можно ли принять за правило рекомендовать всегда для Опенкарт связку nginx+php-fpm в случае VPS/VDS? Ну, лично я когда кого-то перевожу с шареда на VDS, то это исключительно nginx+php-fpm, а Апач на сервер принципиально не ставлю. У первого, переехавшего на такую связку клиента, уже где-то года полтора прошло с момента переезда и никаких проблем за это время не возникало. 1 час назад, sitecreator сказал: Несколько неудобно, что нельзя использовать привычные .htaccess. Это с непривычки. На самом деле, конфиги nginx значительно удобней и логичней. 1 час назад, sitecreator сказал: Возникает вопрос: а нужен ли тогда Апаче? Для чего собственно если nginx+php-fpm так прекрасен? Не нужен. По крайней мере для ОК и любого другого php сайта. Не буду утверждать, что его существование вообще бессмысленно, думаю, есть варианты, где без него не обойтись, но не в случае php. Как я уже сказал, я на VDS в принципе Апач никогда не ставлю. Для php есть nginx+php-fpm, для Python - nginx+uWSGI. 1 Надіслати Поділитися на інших сайтах More sharing options...
sitecreator Опубліковано: 22 лютого 2017 Share Опубліковано: 22 лютого 2017 Интересно, какой приоритет (по производительности) в выборе: 1) nginx+php-fpm 2) апаче + php (модуль) + nginx 3) апаче + php (CGI) + nginx В плане производительности 1-й наиболее производителен, последний - наименее. Верно? Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 22 лютого 2017 Share Опубліковано: 22 лютого 2017 47 минут назад, Dotrox сказал: Ну, лично я когда кого-то перевожу с шареда на VDS, то это исключительно nginx+php-fpm, а Апач на сервер принципиально не ставлю. Мне вот такой вариант (с вашей подачи) сразу понравился. думаю, что от Апаче тоже откажусь и в будущих проектах. Он громоздкий, кроме авторизации средствами Апаче полезным вроде бы и не выделяется, а для Опенкарт такая авторизация неактуальна. Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 22 лютого 2017 Share Опубліковано: 22 лютого 2017 1 час назад, sitecreator сказал: В плане производительности 1-й наиболее производителен, последний - наименее. Верно? На счёт первого - да, а вот следующие два в каком порядке расставить я затрудняюсь ответить. Но, вроде, mod_php таки должен быть быстрее в виду большего родства с самим Апачем (в смысле, что интерпретатор запускается в процессе самого Апача). И кстати, логичнее nginx в различных связках всегда ставить на первое место, поскольку именно он встречает запросы на входе. 1 час назад, sitecreator сказал: кроме авторизации средствами Апаче полезным вроде бы и не выделяется Если речь идёт о запароливании пути средствами сервера, то nginx и это умеет: http://nginx.org/ru/docs/http/ngx_http_auth_basic_module.html Вообще, за несколько лет использования nginx в качестве полной замены Апача я ещё не сталкивался с функциями, которые были бы только у Апача, но не у nginx. 1 Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 23 лютого 2017 Share Опубліковано: 23 лютого 2017 Удавалось ли использовать кеширование средствами nginx для контента, генерируемого за счет php? Это в принципе возможно для Опенкарт? Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 23 лютого 2017 Share Опубліковано: 23 лютого 2017 2 часа назад, sitecreator сказал: Удавалось ли использовать кеширование средствами nginx для контента, генерируемого за счет php? Я немного игрался с этим, но на ОК не испытывал. Могу только сказать, что оно работает и со стороны nginx каких-либо сложностей там нет. 1 час назад, sitecreator сказал: Это в принципе возможно для Опенкарт? Возможно. Можно даже особо не трогать сам ОК, а просто указать nginx список правил запрещающих кеширование: адреса страниц, типы запросов (POST, например, точно лучше не кешировать) и т.д.. Для этого есть директивы fastcgi_cache_bypass и fastcgi_no_cache. Первая говорит nginx игнорировать существующий файл кеша и запрашивать ответ у php, а вторая говорит этот ответ не кешировать. Только условия надо проверять предварительно, а в эти директивы уже передать бинарное значение. Правда, как минимум корзину всё же придётся подправить, чтоб она загружалась аяксом не только при добавлении/удалении товара, но и при обновлении страницы. И то же самое с любым контентом, который может меняться из-за действий пользователя, но является частью страниц, которым кеширование запретить нельзя. Например, тот же модуль просмотренных, он может быть на любой странице, а его контент меняется в процессе переходов пользователя по магазину. Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 (змінено) Потратил несколько дней на серьезное изучение nginx + php-fpm. Всплыли некоторые особенности, о которых не думаешь вообще когда у вас установлен апаче + php (модуль) . Так, в частности, решения (модули) для работы по протоколу 1С CommerceML 2 без проблем (и лишних телодвижений и настроек) функционируют только в случае [nginx] + апаче + php (модуль). nginx в квадратных скобках означает, что он может быть, а может и отсутствовать. В случае работы php в режиме CGI/FastCGI с использованием Апаче или без него ( nginx+php-fpm ) нужны дополнительные настройки, а также может понадобиться некоторое изменение файлов Опенкарт, отвечающих за связь по протоколу 1С. Мне пришлось делать изменения в файлах в дополнение к настройкам в случае nginx+php-fpm. Вообще никакого описания настроек и необходимых изменений в случае если у вас не [nginx] + апаче + php (модуль) поставщиком файлов (exchange 1c, обмен с 1С) не предусмотрено. Та же "Большая птица", к примеру, предлагающая организацию складского и бух. учета (все по протоколу 1С) никакой документации в случае использования "нестандартного" сервера не предлагает. Но если не делать дополнительных настроек/изменений, то будет ситуация (со стороны 1С), что связь будет невозможна ("неверно указан адрес сайта" или "неверные логин/пароль"). Повторюсь, что эти сервисы складского и торгового учета (класс 365, Мой склад, Большая птица и т. д.), основанные на протоколе обмена 1С, никаких решений для "нестандартный" серверов не предлагают и даже в форуме поддержки слабо обращают внимание на данный вопрос. Решение для случая [nginx] + апаче + php (CGI/FastCGI) если работает описано здесь (для битрикса, разумеется): Не работает авторизация при обмене данными с 1С В Опенкарт поступаем аналогично. В случае nginx+php-fpm нужно в конфиге хоста добавить в блок обработки php строку: fastcgi_param REMOTE_USER $http_authorization; Тогда http авторизация будет работать. --------------------------------------------- Но в случае nginx+php-fpm открылись некоторые совершенно необъяснимые пока моменты. Например, при использовании файла .user.ini некоторые строки в нем игнорируются. display_errors = Off Вот это никак не работает в случае nginx+php-fpm. Хотя в случае апаче + php (в любом варианте) работает. memory_limit = 64M Это (да и многие другие директивы) работает, а отключение вывода ошибок не работает! Более того, не работает в коде php отключение ошибок: ini_set('display_errors', '0'); Также не работает в .user.ini в случае nginx+php-fpm и это: max_execution_time = 500 Если посмотреть мануал: http://php.net/manual/ru/errorfunc.configuration.php Я не смог отключить никаким образом мешающие nitice кроме одного способа: подавлением в самом коде за счет @ Вообще получил с показом ошибок пока непонятную ситуацию. Во всех php.ini файлах display_errors установлен в Off (0), причем настройки делались из ispmanager или вручную, но phpinfo неумолимо показывал, что во всех файлах php.ini отображение ошибок включено. Я не смог их отключить! php не реагирует на параметры ini файла! Повторюсь, что такое странное поведение с некоторыми директивами характерно только в случае php как FPM/FastCGI и nginx. В случае php как модуля апаче или апаче+ php (fastCGI) такой проблемы не возникает. Объяснения пока не нашел. Сталкивались ли с подобным? Змінено 1 березня 2017 користувачем sitecreator 1 Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 По поводу отключения показа ошибок. из .user.ini считываются изменения не мгновенно, они кешируются на время, которое можно менять. Это мне известно. Другие директивы ведь отрабатываются, поэтому грешить на кеширование или отсутствие перезагрузки веб-сервера не стоит. К тому же ради экспериментов установил время кеширования в 1 сек для файлов .user.ini. Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 Единственное, что приходит в голову - это php_admin_flag и php_admin_value. Если где-то через них установлен показ ошибок, то никак это переопределить не получится. Надіслати Поділитися на інших сайтах More sharing options... Yoda Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 4 часа назад, sitecreator сказал: Потратил несколько дней на серьезное изучение nginx + php-fpm. Всплыли некоторые особенности, о которых не думаешь вообще когда у вас установлен апаче + php (модуль) . Так, в частности, решения (модули) для работы по протоколу 1С CommerceML 2 без проблем (и лишних телодвижений и настроек) функционируют только в случае [nginx] + апаче + php (модуль). nginx в квадратных скобках означает, что он может быть, а может и отсутствовать. В случае работы php в режиме CGI/FastCGI с использованием Апаче или без него ( nginx+php-fpm ) нужны дополнительные настройки, а также может понадобиться некоторое изменение файлов Опенкарт, отвечающих за связь по протоколу 1С. Мне пришлось делать изменения в файлах в дополнение к настройкам в случае nginx+php-fpm. Вообще никакого описания настроек и необходимых изменений в случае если у вас не [nginx] + апаче + php (модуль) поставщиком файлов (exchange 1c, обмен с 1С) не предусмотрено. Та же "Большая птица", к примеру, предлагающая организацию складского и бух. учета (все по протоколу 1С) никакой документации в случае использования "нестандартного" сервера не предлагает. Но если не делать дополнительных настроек/изменений, то будет ситуация (со стороны 1С), что связь будет невозможна ("неверно указан адрес сайта" или "неверные логин/пароль"). Повторюсь, что эти сервисы складского и торгового учета (класс 365, Мой склад, Большая птица и т. д.), основанные на протоколе обмена 1С, никаких решений для "нестандартный" серверов не предлагают и даже в форуме поддержки слабо обращают внимание на данный вопрос. Решение для случая [nginx] + апаче + php (CGI/FastCGI) если работает описано здесь (для битрикса, разумеется): Не работает авторизация при обмене данными с 1С В Опенкарт поступаем аналогично. В случае nginx+php-fpm нужно в конфиге хоста добавить в блок обработки php строку: fastcgi_param REMOTE_USER $http_authorization; Тогда http авторизация будет работать. --------------------------------------------- Но в случае nginx+php-fpm открылись некоторые совершенно необъяснимые пока моменты. Например, при использовании файла .user.ini некоторые строки в нем игнорируются. display_errors = Off Вот это никак не работает в случае nginx+php-fpm. Хотя в случае апаче + php (в любом варианте) работает. memory_limit = 64M Это (да и многие другие директивы) работает, а отключение вывода ошибок не работает! Более того, не работает в коде php отключение ошибок: ini_set('display_errors', '0'); Также не работает в .user.ini в случае nginx+php-fpm и это: max_execution_time = 500 Если посмотреть мануал: http://php.net/manual/ru/errorfunc.configuration.php Я не смог отключить никаким образом мешающие nitice кроме одного способа: подавлением в самом коде за счет @ Вообще получил с показом ошибок пока непонятную ситуацию. Во всех php.ini файлах display_errors установлен в Off (0), причем настройки делались из ispmanager или вручную, но phpinfo неумолимо показывал, что во всех файлах php.ini отображение ошибок включено. Я не смог их отключить! php не реагирует на параметры ini файла! Повторюсь, что такое странное поведение с некоторыми директивами характерно только в случае php как FPM/FastCGI и nginx. В случае php как модуля апаче или апаче+ php (fastCGI) такой проблемы не возникает. Объяснения пока не нашел. Сталкивались ли с подобным? О да!!!! Это жестяная жесть, ставить nginx+phpfpm и пытаться настроить конфиги из ISP менеджера! Я смотрю тут проФФесионалы собрались. Как говорит один мой товарищ, у вас это выглядит как "копрофилия - попробовать можно, но об этом лучше никому не знать"! Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 13 минут назад, Yoda сказал: Это жестяная жесть, ставить nginx+phpfpm и пытаться настроить конфиги из ISP менеджера! Додумали? Разумеется, что прописывались вручную. Через блокнотик, встроенный в ISPmanager. Разве из контекста не видно, что конфиги вручную правились? Просто привел для примера, что по умолчанию ispmanager, видимо, косячит иногда с конфигами. не более того. Богатый ли у вас опыт работы с nginx+phpfpm? Поделиться советом не желаете? Надіслати Поділитися на інших сайтах More sharing options... Yoda Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 27 минут назад, sitecreator сказал: Додумали? Разумеется, что прописывались вручную. Через блокнотик, встроенный в ISPmanager. Разве из контекста не видно, что конфиги вручную правились? Просто привел для примера, что по умолчанию ispmanager, видимо, косячит иногда с конфигами. не более того. Богатый ли у вас опыт работы с nginx+phpfpm? Поделиться советом не желаете? Нет не желаю. По двум причинам. Во первых к вам и дотроксу я испытываю глубокую личную неприязнь как к проФФесионалам с большой буквы. Во вторых по сути вопроса на 99% проектов прирост производительности настолько ничтожный, что это экономия на спичках. И в силу того что нативно Opencart заточен все-таки под работу в связке apache + mysql а не nginx+phpfpm + mysql, делать в такой конфигурации магазины я крайне не рекомендую никому! А вы сейчас два героя разведете здесь демагогию и начнется волна. А мне вот так надо - а так быстрее. А нифига так не быстрее. Подобное решение уместно абсолютно на высоконагруженных проектах от 100+ одновременных сессий - не вопрос. Актуально более чем. А на средней руки магазин даже в 5 000 хостов в день - это чистой воды погоня за модой и костыли! На те самые 99% магазинов достаточно поставить nginx как проксирующую заглушку, оптимизирующую раздачу статики и забыть про все проблемы с индивидуальным конфигурированием окружения. Надіслати Поділитися на інших сайтах More sharing options... Назад 1 2 Вперед Сторінка 1 з 2 Створіть аккаунт або увійдіть для коментування Ви повинні бути користувачем, щоб залишити коментар Створити обліковий запис Зареєструйтеся для отримання облікового запису. Це просто! Зареєструвати аккаунт Вхід Уже зареєстровані? Увійдіть тут. Вхід зараз Share More sharing options... Передплатники 0 Перейти до списку тем Зараз на сторінці 0 користувачів Ні користувачів, які переглядиють цю сторінку Последние темы Последние дополнения Последние новости Вся активність Головна Разное Курилка Виснет апач Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення SP Telegram повідомлення FREE Автор: spectre Відключити порожні категорії Автор: spectre SEO Автор тексту категорії / фільтра / блогу з датою оновлення контенту + мікророзмітка Автор: radaevich Промо банери в категоріях товарів Автор: IHOR1989 Trend - адаптивний універсальний шаблон Автор: DSV × Уже зареєстровані? Ввійти Реєстрація Ваші замовлення Назад Придбані модулі та шаблони Ваші рахунки Лист очікувань Альтернативні контакти Форум Новини ocStore Назад Офіційний сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Завантажити ocStore Документація Історія версій ocStore Блоги Модулі Шаблони Назад Безкоштовні шаблони Платні шаблони Де купувати модулі? Послуги FAQ OpenCart.Pro Назад Демо Купити Порівняння × Створити... Important Information На нашому сайті використовуються файли cookie і відбувається обробка деяких персональних даних користувачів, щоб поліпшити користувальницький інтерфейс. Щоб дізнатися для чого і які персональні дані ми обробляємо перейдіть за посиланням . Якщо Ви натиснете «Я даю згоду», це означає, що Ви розумієте і приймаєте всі умови, зазначені в цьому Повідомленні про конфіденційність. Я даю згоду
sitecreator Опубліковано: 22 лютого 2017 Share Опубліковано: 22 лютого 2017 47 минут назад, Dotrox сказал: Ну, лично я когда кого-то перевожу с шареда на VDS, то это исключительно nginx+php-fpm, а Апач на сервер принципиально не ставлю. Мне вот такой вариант (с вашей подачи) сразу понравился. думаю, что от Апаче тоже откажусь и в будущих проектах. Он громоздкий, кроме авторизации средствами Апаче полезным вроде бы и не выделяется, а для Опенкарт такая авторизация неактуальна. Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 22 лютого 2017 Share Опубліковано: 22 лютого 2017 1 час назад, sitecreator сказал: В плане производительности 1-й наиболее производителен, последний - наименее. Верно? На счёт первого - да, а вот следующие два в каком порядке расставить я затрудняюсь ответить. Но, вроде, mod_php таки должен быть быстрее в виду большего родства с самим Апачем (в смысле, что интерпретатор запускается в процессе самого Апача). И кстати, логичнее nginx в различных связках всегда ставить на первое место, поскольку именно он встречает запросы на входе. 1 час назад, sitecreator сказал: кроме авторизации средствами Апаче полезным вроде бы и не выделяется Если речь идёт о запароливании пути средствами сервера, то nginx и это умеет: http://nginx.org/ru/docs/http/ngx_http_auth_basic_module.html Вообще, за несколько лет использования nginx в качестве полной замены Апача я ещё не сталкивался с функциями, которые были бы только у Апача, но не у nginx. 1 Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 23 лютого 2017 Share Опубліковано: 23 лютого 2017 Удавалось ли использовать кеширование средствами nginx для контента, генерируемого за счет php? Это в принципе возможно для Опенкарт? Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 23 лютого 2017 Share Опубліковано: 23 лютого 2017 2 часа назад, sitecreator сказал: Удавалось ли использовать кеширование средствами nginx для контента, генерируемого за счет php? Я немного игрался с этим, но на ОК не испытывал. Могу только сказать, что оно работает и со стороны nginx каких-либо сложностей там нет. 1 час назад, sitecreator сказал: Это в принципе возможно для Опенкарт? Возможно. Можно даже особо не трогать сам ОК, а просто указать nginx список правил запрещающих кеширование: адреса страниц, типы запросов (POST, например, точно лучше не кешировать) и т.д.. Для этого есть директивы fastcgi_cache_bypass и fastcgi_no_cache. Первая говорит nginx игнорировать существующий файл кеша и запрашивать ответ у php, а вторая говорит этот ответ не кешировать. Только условия надо проверять предварительно, а в эти директивы уже передать бинарное значение. Правда, как минимум корзину всё же придётся подправить, чтоб она загружалась аяксом не только при добавлении/удалении товара, но и при обновлении страницы. И то же самое с любым контентом, который может меняться из-за действий пользователя, но является частью страниц, которым кеширование запретить нельзя. Например, тот же модуль просмотренных, он может быть на любой странице, а его контент меняется в процессе переходов пользователя по магазину. Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 (змінено) Потратил несколько дней на серьезное изучение nginx + php-fpm. Всплыли некоторые особенности, о которых не думаешь вообще когда у вас установлен апаче + php (модуль) . Так, в частности, решения (модули) для работы по протоколу 1С CommerceML 2 без проблем (и лишних телодвижений и настроек) функционируют только в случае [nginx] + апаче + php (модуль). nginx в квадратных скобках означает, что он может быть, а может и отсутствовать. В случае работы php в режиме CGI/FastCGI с использованием Апаче или без него ( nginx+php-fpm ) нужны дополнительные настройки, а также может понадобиться некоторое изменение файлов Опенкарт, отвечающих за связь по протоколу 1С. Мне пришлось делать изменения в файлах в дополнение к настройкам в случае nginx+php-fpm. Вообще никакого описания настроек и необходимых изменений в случае если у вас не [nginx] + апаче + php (модуль) поставщиком файлов (exchange 1c, обмен с 1С) не предусмотрено. Та же "Большая птица", к примеру, предлагающая организацию складского и бух. учета (все по протоколу 1С) никакой документации в случае использования "нестандартного" сервера не предлагает. Но если не делать дополнительных настроек/изменений, то будет ситуация (со стороны 1С), что связь будет невозможна ("неверно указан адрес сайта" или "неверные логин/пароль"). Повторюсь, что эти сервисы складского и торгового учета (класс 365, Мой склад, Большая птица и т. д.), основанные на протоколе обмена 1С, никаких решений для "нестандартный" серверов не предлагают и даже в форуме поддержки слабо обращают внимание на данный вопрос. Решение для случая [nginx] + апаче + php (CGI/FastCGI) если работает описано здесь (для битрикса, разумеется): Не работает авторизация при обмене данными с 1С В Опенкарт поступаем аналогично. В случае nginx+php-fpm нужно в конфиге хоста добавить в блок обработки php строку: fastcgi_param REMOTE_USER $http_authorization; Тогда http авторизация будет работать. --------------------------------------------- Но в случае nginx+php-fpm открылись некоторые совершенно необъяснимые пока моменты. Например, при использовании файла .user.ini некоторые строки в нем игнорируются. display_errors = Off Вот это никак не работает в случае nginx+php-fpm. Хотя в случае апаче + php (в любом варианте) работает. memory_limit = 64M Это (да и многие другие директивы) работает, а отключение вывода ошибок не работает! Более того, не работает в коде php отключение ошибок: ini_set('display_errors', '0'); Также не работает в .user.ini в случае nginx+php-fpm и это: max_execution_time = 500 Если посмотреть мануал: http://php.net/manual/ru/errorfunc.configuration.php Я не смог отключить никаким образом мешающие nitice кроме одного способа: подавлением в самом коде за счет @ Вообще получил с показом ошибок пока непонятную ситуацию. Во всех php.ini файлах display_errors установлен в Off (0), причем настройки делались из ispmanager или вручную, но phpinfo неумолимо показывал, что во всех файлах php.ini отображение ошибок включено. Я не смог их отключить! php не реагирует на параметры ini файла! Повторюсь, что такое странное поведение с некоторыми директивами характерно только в случае php как FPM/FastCGI и nginx. В случае php как модуля апаче или апаче+ php (fastCGI) такой проблемы не возникает. Объяснения пока не нашел. Сталкивались ли с подобным? Змінено 1 березня 2017 користувачем sitecreator 1 Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 По поводу отключения показа ошибок. из .user.ini считываются изменения не мгновенно, они кешируются на время, которое можно менять. Это мне известно. Другие директивы ведь отрабатываются, поэтому грешить на кеширование или отсутствие перезагрузки веб-сервера не стоит. К тому же ради экспериментов установил время кеширования в 1 сек для файлов .user.ini. Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 Единственное, что приходит в голову - это php_admin_flag и php_admin_value. Если где-то через них установлен показ ошибок, то никак это переопределить не получится. Надіслати Поділитися на інших сайтах More sharing options... Yoda Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 4 часа назад, sitecreator сказал: Потратил несколько дней на серьезное изучение nginx + php-fpm. Всплыли некоторые особенности, о которых не думаешь вообще когда у вас установлен апаче + php (модуль) . Так, в частности, решения (модули) для работы по протоколу 1С CommerceML 2 без проблем (и лишних телодвижений и настроек) функционируют только в случае [nginx] + апаче + php (модуль). nginx в квадратных скобках означает, что он может быть, а может и отсутствовать. В случае работы php в режиме CGI/FastCGI с использованием Апаче или без него ( nginx+php-fpm ) нужны дополнительные настройки, а также может понадобиться некоторое изменение файлов Опенкарт, отвечающих за связь по протоколу 1С. Мне пришлось делать изменения в файлах в дополнение к настройкам в случае nginx+php-fpm. Вообще никакого описания настроек и необходимых изменений в случае если у вас не [nginx] + апаче + php (модуль) поставщиком файлов (exchange 1c, обмен с 1С) не предусмотрено. Та же "Большая птица", к примеру, предлагающая организацию складского и бух. учета (все по протоколу 1С) никакой документации в случае использования "нестандартного" сервера не предлагает. Но если не делать дополнительных настроек/изменений, то будет ситуация (со стороны 1С), что связь будет невозможна ("неверно указан адрес сайта" или "неверные логин/пароль"). Повторюсь, что эти сервисы складского и торгового учета (класс 365, Мой склад, Большая птица и т. д.), основанные на протоколе обмена 1С, никаких решений для "нестандартный" серверов не предлагают и даже в форуме поддержки слабо обращают внимание на данный вопрос. Решение для случая [nginx] + апаче + php (CGI/FastCGI) если работает описано здесь (для битрикса, разумеется): Не работает авторизация при обмене данными с 1С В Опенкарт поступаем аналогично. В случае nginx+php-fpm нужно в конфиге хоста добавить в блок обработки php строку: fastcgi_param REMOTE_USER $http_authorization; Тогда http авторизация будет работать. --------------------------------------------- Но в случае nginx+php-fpm открылись некоторые совершенно необъяснимые пока моменты. Например, при использовании файла .user.ini некоторые строки в нем игнорируются. display_errors = Off Вот это никак не работает в случае nginx+php-fpm. Хотя в случае апаче + php (в любом варианте) работает. memory_limit = 64M Это (да и многие другие директивы) работает, а отключение вывода ошибок не работает! Более того, не работает в коде php отключение ошибок: ini_set('display_errors', '0'); Также не работает в .user.ini в случае nginx+php-fpm и это: max_execution_time = 500 Если посмотреть мануал: http://php.net/manual/ru/errorfunc.configuration.php Я не смог отключить никаким образом мешающие nitice кроме одного способа: подавлением в самом коде за счет @ Вообще получил с показом ошибок пока непонятную ситуацию. Во всех php.ini файлах display_errors установлен в Off (0), причем настройки делались из ispmanager или вручную, но phpinfo неумолимо показывал, что во всех файлах php.ini отображение ошибок включено. Я не смог их отключить! php не реагирует на параметры ini файла! Повторюсь, что такое странное поведение с некоторыми директивами характерно только в случае php как FPM/FastCGI и nginx. В случае php как модуля апаче или апаче+ php (fastCGI) такой проблемы не возникает. Объяснения пока не нашел. Сталкивались ли с подобным? О да!!!! Это жестяная жесть, ставить nginx+phpfpm и пытаться настроить конфиги из ISP менеджера! Я смотрю тут проФФесионалы собрались. Как говорит один мой товарищ, у вас это выглядит как "копрофилия - попробовать можно, но об этом лучше никому не знать"! Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 13 минут назад, Yoda сказал: Это жестяная жесть, ставить nginx+phpfpm и пытаться настроить конфиги из ISP менеджера! Додумали? Разумеется, что прописывались вручную. Через блокнотик, встроенный в ISPmanager. Разве из контекста не видно, что конфиги вручную правились? Просто привел для примера, что по умолчанию ispmanager, видимо, косячит иногда с конфигами. не более того. Богатый ли у вас опыт работы с nginx+phpfpm? Поделиться советом не желаете? Надіслати Поділитися на інших сайтах More sharing options... Yoda Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 27 минут назад, sitecreator сказал: Додумали? Разумеется, что прописывались вручную. Через блокнотик, встроенный в ISPmanager. Разве из контекста не видно, что конфиги вручную правились? Просто привел для примера, что по умолчанию ispmanager, видимо, косячит иногда с конфигами. не более того. Богатый ли у вас опыт работы с nginx+phpfpm? Поделиться советом не желаете? Нет не желаю. По двум причинам. Во первых к вам и дотроксу я испытываю глубокую личную неприязнь как к проФФесионалам с большой буквы. Во вторых по сути вопроса на 99% проектов прирост производительности настолько ничтожный, что это экономия на спичках. И в силу того что нативно Opencart заточен все-таки под работу в связке apache + mysql а не nginx+phpfpm + mysql, делать в такой конфигурации магазины я крайне не рекомендую никому! А вы сейчас два героя разведете здесь демагогию и начнется волна. А мне вот так надо - а так быстрее. А нифига так не быстрее. Подобное решение уместно абсолютно на высоконагруженных проектах от 100+ одновременных сессий - не вопрос. Актуально более чем. А на средней руки магазин даже в 5 000 хостов в день - это чистой воды погоня за модой и костыли! На те самые 99% магазинов достаточно поставить nginx как проксирующую заглушку, оптимизирующую раздачу статики и забыть про все проблемы с индивидуальным конфигурированием окружения. Надіслати Поділитися на інших сайтах More sharing options... Назад 1 2 Вперед Сторінка 1 з 2 Створіть аккаунт або увійдіть для коментування Ви повинні бути користувачем, щоб залишити коментар Створити обліковий запис Зареєструйтеся для отримання облікового запису. Це просто! Зареєструвати аккаунт Вхід Уже зареєстровані? Увійдіть тут. Вхід зараз Share More sharing options... Передплатники 0 Перейти до списку тем Зараз на сторінці 0 користувачів Ні користувачів, які переглядиють цю сторінку Последние темы Последние дополнения Последние новости Вся активність Головна Разное Курилка Виснет апач Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення SP Telegram повідомлення FREE Автор: spectre Відключити порожні категорії Автор: spectre SEO Автор тексту категорії / фільтра / блогу з датою оновлення контенту + мікророзмітка Автор: radaevich Промо банери в категоріях товарів Автор: IHOR1989 Trend - адаптивний універсальний шаблон Автор: DSV × Уже зареєстровані? Ввійти Реєстрація Ваші замовлення Назад Придбані модулі та шаблони Ваші рахунки Лист очікувань Альтернативні контакти Форум Новини ocStore Назад Офіційний сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Завантажити ocStore Документація Історія версій ocStore Блоги Модулі Шаблони Назад Безкоштовні шаблони Платні шаблони Де купувати модулі? Послуги FAQ OpenCart.Pro Назад Демо Купити Порівняння × Створити... Important Information На нашому сайті використовуються файли cookie і відбувається обробка деяких персональних даних користувачів, щоб поліпшити користувальницький інтерфейс. Щоб дізнатися для чого і які персональні дані ми обробляємо перейдіть за посиланням . Якщо Ви натиснете «Я даю згоду», це означає, що Ви розумієте і приймаєте всі умови, зазначені в цьому Повідомленні про конфіденційність. Я даю згоду
Dotrox Опубліковано: 22 лютого 2017 Share Опубліковано: 22 лютого 2017 1 час назад, sitecreator сказал: В плане производительности 1-й наиболее производителен, последний - наименее. Верно? На счёт первого - да, а вот следующие два в каком порядке расставить я затрудняюсь ответить. Но, вроде, mod_php таки должен быть быстрее в виду большего родства с самим Апачем (в смысле, что интерпретатор запускается в процессе самого Апача). И кстати, логичнее nginx в различных связках всегда ставить на первое место, поскольку именно он встречает запросы на входе. 1 час назад, sitecreator сказал: кроме авторизации средствами Апаче полезным вроде бы и не выделяется Если речь идёт о запароливании пути средствами сервера, то nginx и это умеет: http://nginx.org/ru/docs/http/ngx_http_auth_basic_module.html Вообще, за несколько лет использования nginx в качестве полной замены Апача я ещё не сталкивался с функциями, которые были бы только у Апача, но не у nginx. 1 Надіслати Поділитися на інших сайтах More sharing options...
sitecreator Опубліковано: 23 лютого 2017 Share Опубліковано: 23 лютого 2017 Удавалось ли использовать кеширование средствами nginx для контента, генерируемого за счет php? Это в принципе возможно для Опенкарт? Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 23 лютого 2017 Share Опубліковано: 23 лютого 2017 2 часа назад, sitecreator сказал: Удавалось ли использовать кеширование средствами nginx для контента, генерируемого за счет php? Я немного игрался с этим, но на ОК не испытывал. Могу только сказать, что оно работает и со стороны nginx каких-либо сложностей там нет. 1 час назад, sitecreator сказал: Это в принципе возможно для Опенкарт? Возможно. Можно даже особо не трогать сам ОК, а просто указать nginx список правил запрещающих кеширование: адреса страниц, типы запросов (POST, например, точно лучше не кешировать) и т.д.. Для этого есть директивы fastcgi_cache_bypass и fastcgi_no_cache. Первая говорит nginx игнорировать существующий файл кеша и запрашивать ответ у php, а вторая говорит этот ответ не кешировать. Только условия надо проверять предварительно, а в эти директивы уже передать бинарное значение. Правда, как минимум корзину всё же придётся подправить, чтоб она загружалась аяксом не только при добавлении/удалении товара, но и при обновлении страницы. И то же самое с любым контентом, который может меняться из-за действий пользователя, но является частью страниц, которым кеширование запретить нельзя. Например, тот же модуль просмотренных, он может быть на любой странице, а его контент меняется в процессе переходов пользователя по магазину. Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 (змінено) Потратил несколько дней на серьезное изучение nginx + php-fpm. Всплыли некоторые особенности, о которых не думаешь вообще когда у вас установлен апаче + php (модуль) . Так, в частности, решения (модули) для работы по протоколу 1С CommerceML 2 без проблем (и лишних телодвижений и настроек) функционируют только в случае [nginx] + апаче + php (модуль). nginx в квадратных скобках означает, что он может быть, а может и отсутствовать. В случае работы php в режиме CGI/FastCGI с использованием Апаче или без него ( nginx+php-fpm ) нужны дополнительные настройки, а также может понадобиться некоторое изменение файлов Опенкарт, отвечающих за связь по протоколу 1С. Мне пришлось делать изменения в файлах в дополнение к настройкам в случае nginx+php-fpm. Вообще никакого описания настроек и необходимых изменений в случае если у вас не [nginx] + апаче + php (модуль) поставщиком файлов (exchange 1c, обмен с 1С) не предусмотрено. Та же "Большая птица", к примеру, предлагающая организацию складского и бух. учета (все по протоколу 1С) никакой документации в случае использования "нестандартного" сервера не предлагает. Но если не делать дополнительных настроек/изменений, то будет ситуация (со стороны 1С), что связь будет невозможна ("неверно указан адрес сайта" или "неверные логин/пароль"). Повторюсь, что эти сервисы складского и торгового учета (класс 365, Мой склад, Большая птица и т. д.), основанные на протоколе обмена 1С, никаких решений для "нестандартный" серверов не предлагают и даже в форуме поддержки слабо обращают внимание на данный вопрос. Решение для случая [nginx] + апаче + php (CGI/FastCGI) если работает описано здесь (для битрикса, разумеется): Не работает авторизация при обмене данными с 1С В Опенкарт поступаем аналогично. В случае nginx+php-fpm нужно в конфиге хоста добавить в блок обработки php строку: fastcgi_param REMOTE_USER $http_authorization; Тогда http авторизация будет работать. --------------------------------------------- Но в случае nginx+php-fpm открылись некоторые совершенно необъяснимые пока моменты. Например, при использовании файла .user.ini некоторые строки в нем игнорируются. display_errors = Off Вот это никак не работает в случае nginx+php-fpm. Хотя в случае апаче + php (в любом варианте) работает. memory_limit = 64M Это (да и многие другие директивы) работает, а отключение вывода ошибок не работает! Более того, не работает в коде php отключение ошибок: ini_set('display_errors', '0'); Также не работает в .user.ini в случае nginx+php-fpm и это: max_execution_time = 500 Если посмотреть мануал: http://php.net/manual/ru/errorfunc.configuration.php Я не смог отключить никаким образом мешающие nitice кроме одного способа: подавлением в самом коде за счет @ Вообще получил с показом ошибок пока непонятную ситуацию. Во всех php.ini файлах display_errors установлен в Off (0), причем настройки делались из ispmanager или вручную, но phpinfo неумолимо показывал, что во всех файлах php.ini отображение ошибок включено. Я не смог их отключить! php не реагирует на параметры ini файла! Повторюсь, что такое странное поведение с некоторыми директивами характерно только в случае php как FPM/FastCGI и nginx. В случае php как модуля апаче или апаче+ php (fastCGI) такой проблемы не возникает. Объяснения пока не нашел. Сталкивались ли с подобным? Змінено 1 березня 2017 користувачем sitecreator 1 Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 По поводу отключения показа ошибок. из .user.ini считываются изменения не мгновенно, они кешируются на время, которое можно менять. Это мне известно. Другие директивы ведь отрабатываются, поэтому грешить на кеширование или отсутствие перезагрузки веб-сервера не стоит. К тому же ради экспериментов установил время кеширования в 1 сек для файлов .user.ini. Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 Единственное, что приходит в голову - это php_admin_flag и php_admin_value. Если где-то через них установлен показ ошибок, то никак это переопределить не получится. Надіслати Поділитися на інших сайтах More sharing options... Yoda Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 4 часа назад, sitecreator сказал: Потратил несколько дней на серьезное изучение nginx + php-fpm. Всплыли некоторые особенности, о которых не думаешь вообще когда у вас установлен апаче + php (модуль) . Так, в частности, решения (модули) для работы по протоколу 1С CommerceML 2 без проблем (и лишних телодвижений и настроек) функционируют только в случае [nginx] + апаче + php (модуль). nginx в квадратных скобках означает, что он может быть, а может и отсутствовать. В случае работы php в режиме CGI/FastCGI с использованием Апаче или без него ( nginx+php-fpm ) нужны дополнительные настройки, а также может понадобиться некоторое изменение файлов Опенкарт, отвечающих за связь по протоколу 1С. Мне пришлось делать изменения в файлах в дополнение к настройкам в случае nginx+php-fpm. Вообще никакого описания настроек и необходимых изменений в случае если у вас не [nginx] + апаче + php (модуль) поставщиком файлов (exchange 1c, обмен с 1С) не предусмотрено. Та же "Большая птица", к примеру, предлагающая организацию складского и бух. учета (все по протоколу 1С) никакой документации в случае использования "нестандартного" сервера не предлагает. Но если не делать дополнительных настроек/изменений, то будет ситуация (со стороны 1С), что связь будет невозможна ("неверно указан адрес сайта" или "неверные логин/пароль"). Повторюсь, что эти сервисы складского и торгового учета (класс 365, Мой склад, Большая птица и т. д.), основанные на протоколе обмена 1С, никаких решений для "нестандартный" серверов не предлагают и даже в форуме поддержки слабо обращают внимание на данный вопрос. Решение для случая [nginx] + апаче + php (CGI/FastCGI) если работает описано здесь (для битрикса, разумеется): Не работает авторизация при обмене данными с 1С В Опенкарт поступаем аналогично. В случае nginx+php-fpm нужно в конфиге хоста добавить в блок обработки php строку: fastcgi_param REMOTE_USER $http_authorization; Тогда http авторизация будет работать. --------------------------------------------- Но в случае nginx+php-fpm открылись некоторые совершенно необъяснимые пока моменты. Например, при использовании файла .user.ini некоторые строки в нем игнорируются. display_errors = Off Вот это никак не работает в случае nginx+php-fpm. Хотя в случае апаче + php (в любом варианте) работает. memory_limit = 64M Это (да и многие другие директивы) работает, а отключение вывода ошибок не работает! Более того, не работает в коде php отключение ошибок: ini_set('display_errors', '0'); Также не работает в .user.ini в случае nginx+php-fpm и это: max_execution_time = 500 Если посмотреть мануал: http://php.net/manual/ru/errorfunc.configuration.php Я не смог отключить никаким образом мешающие nitice кроме одного способа: подавлением в самом коде за счет @ Вообще получил с показом ошибок пока непонятную ситуацию. Во всех php.ini файлах display_errors установлен в Off (0), причем настройки делались из ispmanager или вручную, но phpinfo неумолимо показывал, что во всех файлах php.ini отображение ошибок включено. Я не смог их отключить! php не реагирует на параметры ini файла! Повторюсь, что такое странное поведение с некоторыми директивами характерно только в случае php как FPM/FastCGI и nginx. В случае php как модуля апаче или апаче+ php (fastCGI) такой проблемы не возникает. Объяснения пока не нашел. Сталкивались ли с подобным? О да!!!! Это жестяная жесть, ставить nginx+phpfpm и пытаться настроить конфиги из ISP менеджера! Я смотрю тут проФФесионалы собрались. Как говорит один мой товарищ, у вас это выглядит как "копрофилия - попробовать можно, но об этом лучше никому не знать"! Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 13 минут назад, Yoda сказал: Это жестяная жесть, ставить nginx+phpfpm и пытаться настроить конфиги из ISP менеджера! Додумали? Разумеется, что прописывались вручную. Через блокнотик, встроенный в ISPmanager. Разве из контекста не видно, что конфиги вручную правились? Просто привел для примера, что по умолчанию ispmanager, видимо, косячит иногда с конфигами. не более того. Богатый ли у вас опыт работы с nginx+phpfpm? Поделиться советом не желаете? Надіслати Поділитися на інших сайтах More sharing options... Yoda Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 27 минут назад, sitecreator сказал: Додумали? Разумеется, что прописывались вручную. Через блокнотик, встроенный в ISPmanager. Разве из контекста не видно, что конфиги вручную правились? Просто привел для примера, что по умолчанию ispmanager, видимо, косячит иногда с конфигами. не более того. Богатый ли у вас опыт работы с nginx+phpfpm? Поделиться советом не желаете? Нет не желаю. По двум причинам. Во первых к вам и дотроксу я испытываю глубокую личную неприязнь как к проФФесионалам с большой буквы. Во вторых по сути вопроса на 99% проектов прирост производительности настолько ничтожный, что это экономия на спичках. И в силу того что нативно Opencart заточен все-таки под работу в связке apache + mysql а не nginx+phpfpm + mysql, делать в такой конфигурации магазины я крайне не рекомендую никому! А вы сейчас два героя разведете здесь демагогию и начнется волна. А мне вот так надо - а так быстрее. А нифига так не быстрее. Подобное решение уместно абсолютно на высоконагруженных проектах от 100+ одновременных сессий - не вопрос. Актуально более чем. А на средней руки магазин даже в 5 000 хостов в день - это чистой воды погоня за модой и костыли! На те самые 99% магазинов достаточно поставить nginx как проксирующую заглушку, оптимизирующую раздачу статики и забыть про все проблемы с индивидуальным конфигурированием окружения. Надіслати Поділитися на інших сайтах More sharing options... Назад 1 2 Вперед Сторінка 1 з 2 Створіть аккаунт або увійдіть для коментування Ви повинні бути користувачем, щоб залишити коментар Створити обліковий запис Зареєструйтеся для отримання облікового запису. Це просто! Зареєструвати аккаунт Вхід Уже зареєстровані? Увійдіть тут. Вхід зараз Share More sharing options... Передплатники 0 Перейти до списку тем Зараз на сторінці 0 користувачів Ні користувачів, які переглядиють цю сторінку Последние темы Последние дополнения Последние новости Вся активність Головна Разное Курилка Виснет апач Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення SP Telegram повідомлення FREE Автор: spectre Відключити порожні категорії Автор: spectre SEO Автор тексту категорії / фільтра / блогу з датою оновлення контенту + мікророзмітка Автор: radaevich Промо банери в категоріях товарів Автор: IHOR1989 Trend - адаптивний універсальний шаблон Автор: DSV
Dotrox Опубліковано: 23 лютого 2017 Share Опубліковано: 23 лютого 2017 2 часа назад, sitecreator сказал: Удавалось ли использовать кеширование средствами nginx для контента, генерируемого за счет php? Я немного игрался с этим, но на ОК не испытывал. Могу только сказать, что оно работает и со стороны nginx каких-либо сложностей там нет. 1 час назад, sitecreator сказал: Это в принципе возможно для Опенкарт? Возможно. Можно даже особо не трогать сам ОК, а просто указать nginx список правил запрещающих кеширование: адреса страниц, типы запросов (POST, например, точно лучше не кешировать) и т.д.. Для этого есть директивы fastcgi_cache_bypass и fastcgi_no_cache. Первая говорит nginx игнорировать существующий файл кеша и запрашивать ответ у php, а вторая говорит этот ответ не кешировать. Только условия надо проверять предварительно, а в эти директивы уже передать бинарное значение. Правда, как минимум корзину всё же придётся подправить, чтоб она загружалась аяксом не только при добавлении/удалении товара, но и при обновлении страницы. И то же самое с любым контентом, который может меняться из-за действий пользователя, но является частью страниц, которым кеширование запретить нельзя. Например, тот же модуль просмотренных, он может быть на любой странице, а его контент меняется в процессе переходов пользователя по магазину. Надіслати Поділитися на інших сайтах More sharing options...
sitecreator Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 (змінено) Потратил несколько дней на серьезное изучение nginx + php-fpm. Всплыли некоторые особенности, о которых не думаешь вообще когда у вас установлен апаче + php (модуль) . Так, в частности, решения (модули) для работы по протоколу 1С CommerceML 2 без проблем (и лишних телодвижений и настроек) функционируют только в случае [nginx] + апаче + php (модуль). nginx в квадратных скобках означает, что он может быть, а может и отсутствовать. В случае работы php в режиме CGI/FastCGI с использованием Апаче или без него ( nginx+php-fpm ) нужны дополнительные настройки, а также может понадобиться некоторое изменение файлов Опенкарт, отвечающих за связь по протоколу 1С. Мне пришлось делать изменения в файлах в дополнение к настройкам в случае nginx+php-fpm. Вообще никакого описания настроек и необходимых изменений в случае если у вас не [nginx] + апаче + php (модуль) поставщиком файлов (exchange 1c, обмен с 1С) не предусмотрено. Та же "Большая птица", к примеру, предлагающая организацию складского и бух. учета (все по протоколу 1С) никакой документации в случае использования "нестандартного" сервера не предлагает. Но если не делать дополнительных настроек/изменений, то будет ситуация (со стороны 1С), что связь будет невозможна ("неверно указан адрес сайта" или "неверные логин/пароль"). Повторюсь, что эти сервисы складского и торгового учета (класс 365, Мой склад, Большая птица и т. д.), основанные на протоколе обмена 1С, никаких решений для "нестандартный" серверов не предлагают и даже в форуме поддержки слабо обращают внимание на данный вопрос. Решение для случая [nginx] + апаче + php (CGI/FastCGI) если работает описано здесь (для битрикса, разумеется): Не работает авторизация при обмене данными с 1С В Опенкарт поступаем аналогично. В случае nginx+php-fpm нужно в конфиге хоста добавить в блок обработки php строку: fastcgi_param REMOTE_USER $http_authorization; Тогда http авторизация будет работать. --------------------------------------------- Но в случае nginx+php-fpm открылись некоторые совершенно необъяснимые пока моменты. Например, при использовании файла .user.ini некоторые строки в нем игнорируются. display_errors = Off Вот это никак не работает в случае nginx+php-fpm. Хотя в случае апаче + php (в любом варианте) работает. memory_limit = 64M Это (да и многие другие директивы) работает, а отключение вывода ошибок не работает! Более того, не работает в коде php отключение ошибок: ini_set('display_errors', '0'); Также не работает в .user.ini в случае nginx+php-fpm и это: max_execution_time = 500 Если посмотреть мануал: http://php.net/manual/ru/errorfunc.configuration.php Я не смог отключить никаким образом мешающие nitice кроме одного способа: подавлением в самом коде за счет @ Вообще получил с показом ошибок пока непонятную ситуацию. Во всех php.ini файлах display_errors установлен в Off (0), причем настройки делались из ispmanager или вручную, но phpinfo неумолимо показывал, что во всех файлах php.ini отображение ошибок включено. Я не смог их отключить! php не реагирует на параметры ini файла! Повторюсь, что такое странное поведение с некоторыми директивами характерно только в случае php как FPM/FastCGI и nginx. В случае php как модуля апаче или апаче+ php (fastCGI) такой проблемы не возникает. Объяснения пока не нашел. Сталкивались ли с подобным? Змінено 1 березня 2017 користувачем sitecreator 1 Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 По поводу отключения показа ошибок. из .user.ini считываются изменения не мгновенно, они кешируются на время, которое можно менять. Это мне известно. Другие директивы ведь отрабатываются, поэтому грешить на кеширование или отсутствие перезагрузки веб-сервера не стоит. К тому же ради экспериментов установил время кеширования в 1 сек для файлов .user.ini. Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 Единственное, что приходит в голову - это php_admin_flag и php_admin_value. Если где-то через них установлен показ ошибок, то никак это переопределить не получится. Надіслати Поділитися на інших сайтах More sharing options... Yoda Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 4 часа назад, sitecreator сказал: Потратил несколько дней на серьезное изучение nginx + php-fpm. Всплыли некоторые особенности, о которых не думаешь вообще когда у вас установлен апаче + php (модуль) . Так, в частности, решения (модули) для работы по протоколу 1С CommerceML 2 без проблем (и лишних телодвижений и настроек) функционируют только в случае [nginx] + апаче + php (модуль). nginx в квадратных скобках означает, что он может быть, а может и отсутствовать. В случае работы php в режиме CGI/FastCGI с использованием Апаче или без него ( nginx+php-fpm ) нужны дополнительные настройки, а также может понадобиться некоторое изменение файлов Опенкарт, отвечающих за связь по протоколу 1С. Мне пришлось делать изменения в файлах в дополнение к настройкам в случае nginx+php-fpm. Вообще никакого описания настроек и необходимых изменений в случае если у вас не [nginx] + апаче + php (модуль) поставщиком файлов (exchange 1c, обмен с 1С) не предусмотрено. Та же "Большая птица", к примеру, предлагающая организацию складского и бух. учета (все по протоколу 1С) никакой документации в случае использования "нестандартного" сервера не предлагает. Но если не делать дополнительных настроек/изменений, то будет ситуация (со стороны 1С), что связь будет невозможна ("неверно указан адрес сайта" или "неверные логин/пароль"). Повторюсь, что эти сервисы складского и торгового учета (класс 365, Мой склад, Большая птица и т. д.), основанные на протоколе обмена 1С, никаких решений для "нестандартный" серверов не предлагают и даже в форуме поддержки слабо обращают внимание на данный вопрос. Решение для случая [nginx] + апаче + php (CGI/FastCGI) если работает описано здесь (для битрикса, разумеется): Не работает авторизация при обмене данными с 1С В Опенкарт поступаем аналогично. В случае nginx+php-fpm нужно в конфиге хоста добавить в блок обработки php строку: fastcgi_param REMOTE_USER $http_authorization; Тогда http авторизация будет работать. --------------------------------------------- Но в случае nginx+php-fpm открылись некоторые совершенно необъяснимые пока моменты. Например, при использовании файла .user.ini некоторые строки в нем игнорируются. display_errors = Off Вот это никак не работает в случае nginx+php-fpm. Хотя в случае апаче + php (в любом варианте) работает. memory_limit = 64M Это (да и многие другие директивы) работает, а отключение вывода ошибок не работает! Более того, не работает в коде php отключение ошибок: ini_set('display_errors', '0'); Также не работает в .user.ini в случае nginx+php-fpm и это: max_execution_time = 500 Если посмотреть мануал: http://php.net/manual/ru/errorfunc.configuration.php Я не смог отключить никаким образом мешающие nitice кроме одного способа: подавлением в самом коде за счет @ Вообще получил с показом ошибок пока непонятную ситуацию. Во всех php.ini файлах display_errors установлен в Off (0), причем настройки делались из ispmanager или вручную, но phpinfo неумолимо показывал, что во всех файлах php.ini отображение ошибок включено. Я не смог их отключить! php не реагирует на параметры ini файла! Повторюсь, что такое странное поведение с некоторыми директивами характерно только в случае php как FPM/FastCGI и nginx. В случае php как модуля апаче или апаче+ php (fastCGI) такой проблемы не возникает. Объяснения пока не нашел. Сталкивались ли с подобным? О да!!!! Это жестяная жесть, ставить nginx+phpfpm и пытаться настроить конфиги из ISP менеджера! Я смотрю тут проФФесионалы собрались. Как говорит один мой товарищ, у вас это выглядит как "копрофилия - попробовать можно, но об этом лучше никому не знать"! Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 13 минут назад, Yoda сказал: Это жестяная жесть, ставить nginx+phpfpm и пытаться настроить конфиги из ISP менеджера! Додумали? Разумеется, что прописывались вручную. Через блокнотик, встроенный в ISPmanager. Разве из контекста не видно, что конфиги вручную правились? Просто привел для примера, что по умолчанию ispmanager, видимо, косячит иногда с конфигами. не более того. Богатый ли у вас опыт работы с nginx+phpfpm? Поделиться советом не желаете? Надіслати Поділитися на інших сайтах More sharing options... Yoda Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 27 минут назад, sitecreator сказал: Додумали? Разумеется, что прописывались вручную. Через блокнотик, встроенный в ISPmanager. Разве из контекста не видно, что конфиги вручную правились? Просто привел для примера, что по умолчанию ispmanager, видимо, косячит иногда с конфигами. не более того. Богатый ли у вас опыт работы с nginx+phpfpm? Поделиться советом не желаете? Нет не желаю. По двум причинам. Во первых к вам и дотроксу я испытываю глубокую личную неприязнь как к проФФесионалам с большой буквы. Во вторых по сути вопроса на 99% проектов прирост производительности настолько ничтожный, что это экономия на спичках. И в силу того что нативно Opencart заточен все-таки под работу в связке apache + mysql а не nginx+phpfpm + mysql, делать в такой конфигурации магазины я крайне не рекомендую никому! А вы сейчас два героя разведете здесь демагогию и начнется волна. А мне вот так надо - а так быстрее. А нифига так не быстрее. Подобное решение уместно абсолютно на высоконагруженных проектах от 100+ одновременных сессий - не вопрос. Актуально более чем. А на средней руки магазин даже в 5 000 хостов в день - это чистой воды погоня за модой и костыли! На те самые 99% магазинов достаточно поставить nginx как проксирующую заглушку, оптимизирующую раздачу статики и забыть про все проблемы с индивидуальным конфигурированием окружения. Надіслати Поділитися на інших сайтах More sharing options... Назад 1 2 Вперед Сторінка 1 з 2 Створіть аккаунт або увійдіть для коментування Ви повинні бути користувачем, щоб залишити коментар Створити обліковий запис Зареєструйтеся для отримання облікового запису. Це просто! Зареєструвати аккаунт Вхід Уже зареєстровані? Увійдіть тут. Вхід зараз Share More sharing options... Передплатники 0 Перейти до списку тем Зараз на сторінці 0 користувачів Ні користувачів, які переглядиють цю сторінку Последние темы Последние дополнения Последние новости Вся активність Головна Разное Курилка Виснет апач
sitecreator Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 По поводу отключения показа ошибок. из .user.ini считываются изменения не мгновенно, они кешируются на время, которое можно менять. Это мне известно. Другие директивы ведь отрабатываются, поэтому грешить на кеширование или отсутствие перезагрузки веб-сервера не стоит. К тому же ради экспериментов установил время кеширования в 1 сек для файлов .user.ini. Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 Единственное, что приходит в голову - это php_admin_flag и php_admin_value. Если где-то через них установлен показ ошибок, то никак это переопределить не получится. Надіслати Поділитися на інших сайтах More sharing options... Yoda Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 4 часа назад, sitecreator сказал: Потратил несколько дней на серьезное изучение nginx + php-fpm. Всплыли некоторые особенности, о которых не думаешь вообще когда у вас установлен апаче + php (модуль) . Так, в частности, решения (модули) для работы по протоколу 1С CommerceML 2 без проблем (и лишних телодвижений и настроек) функционируют только в случае [nginx] + апаче + php (модуль). nginx в квадратных скобках означает, что он может быть, а может и отсутствовать. В случае работы php в режиме CGI/FastCGI с использованием Апаче или без него ( nginx+php-fpm ) нужны дополнительные настройки, а также может понадобиться некоторое изменение файлов Опенкарт, отвечающих за связь по протоколу 1С. Мне пришлось делать изменения в файлах в дополнение к настройкам в случае nginx+php-fpm. Вообще никакого описания настроек и необходимых изменений в случае если у вас не [nginx] + апаче + php (модуль) поставщиком файлов (exchange 1c, обмен с 1С) не предусмотрено. Та же "Большая птица", к примеру, предлагающая организацию складского и бух. учета (все по протоколу 1С) никакой документации в случае использования "нестандартного" сервера не предлагает. Но если не делать дополнительных настроек/изменений, то будет ситуация (со стороны 1С), что связь будет невозможна ("неверно указан адрес сайта" или "неверные логин/пароль"). Повторюсь, что эти сервисы складского и торгового учета (класс 365, Мой склад, Большая птица и т. д.), основанные на протоколе обмена 1С, никаких решений для "нестандартный" серверов не предлагают и даже в форуме поддержки слабо обращают внимание на данный вопрос. Решение для случая [nginx] + апаче + php (CGI/FastCGI) если работает описано здесь (для битрикса, разумеется): Не работает авторизация при обмене данными с 1С В Опенкарт поступаем аналогично. В случае nginx+php-fpm нужно в конфиге хоста добавить в блок обработки php строку: fastcgi_param REMOTE_USER $http_authorization; Тогда http авторизация будет работать. --------------------------------------------- Но в случае nginx+php-fpm открылись некоторые совершенно необъяснимые пока моменты. Например, при использовании файла .user.ini некоторые строки в нем игнорируются. display_errors = Off Вот это никак не работает в случае nginx+php-fpm. Хотя в случае апаче + php (в любом варианте) работает. memory_limit = 64M Это (да и многие другие директивы) работает, а отключение вывода ошибок не работает! Более того, не работает в коде php отключение ошибок: ini_set('display_errors', '0'); Также не работает в .user.ini в случае nginx+php-fpm и это: max_execution_time = 500 Если посмотреть мануал: http://php.net/manual/ru/errorfunc.configuration.php Я не смог отключить никаким образом мешающие nitice кроме одного способа: подавлением в самом коде за счет @ Вообще получил с показом ошибок пока непонятную ситуацию. Во всех php.ini файлах display_errors установлен в Off (0), причем настройки делались из ispmanager или вручную, но phpinfo неумолимо показывал, что во всех файлах php.ini отображение ошибок включено. Я не смог их отключить! php не реагирует на параметры ini файла! Повторюсь, что такое странное поведение с некоторыми директивами характерно только в случае php как FPM/FastCGI и nginx. В случае php как модуля апаче или апаче+ php (fastCGI) такой проблемы не возникает. Объяснения пока не нашел. Сталкивались ли с подобным? О да!!!! Это жестяная жесть, ставить nginx+phpfpm и пытаться настроить конфиги из ISP менеджера! Я смотрю тут проФФесионалы собрались. Как говорит один мой товарищ, у вас это выглядит как "копрофилия - попробовать можно, но об этом лучше никому не знать"! Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 13 минут назад, Yoda сказал: Это жестяная жесть, ставить nginx+phpfpm и пытаться настроить конфиги из ISP менеджера! Додумали? Разумеется, что прописывались вручную. Через блокнотик, встроенный в ISPmanager. Разве из контекста не видно, что конфиги вручную правились? Просто привел для примера, что по умолчанию ispmanager, видимо, косячит иногда с конфигами. не более того. Богатый ли у вас опыт работы с nginx+phpfpm? Поделиться советом не желаете? Надіслати Поділитися на інших сайтах More sharing options... Yoda Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 27 минут назад, sitecreator сказал: Додумали? Разумеется, что прописывались вручную. Через блокнотик, встроенный в ISPmanager. Разве из контекста не видно, что конфиги вручную правились? Просто привел для примера, что по умолчанию ispmanager, видимо, косячит иногда с конфигами. не более того. Богатый ли у вас опыт работы с nginx+phpfpm? Поделиться советом не желаете? Нет не желаю. По двум причинам. Во первых к вам и дотроксу я испытываю глубокую личную неприязнь как к проФФесионалам с большой буквы. Во вторых по сути вопроса на 99% проектов прирост производительности настолько ничтожный, что это экономия на спичках. И в силу того что нативно Opencart заточен все-таки под работу в связке apache + mysql а не nginx+phpfpm + mysql, делать в такой конфигурации магазины я крайне не рекомендую никому! А вы сейчас два героя разведете здесь демагогию и начнется волна. А мне вот так надо - а так быстрее. А нифига так не быстрее. Подобное решение уместно абсолютно на высоконагруженных проектах от 100+ одновременных сессий - не вопрос. Актуально более чем. А на средней руки магазин даже в 5 000 хостов в день - это чистой воды погоня за модой и костыли! На те самые 99% магазинов достаточно поставить nginx как проксирующую заглушку, оптимизирующую раздачу статики и забыть про все проблемы с индивидуальным конфигурированием окружения. Надіслати Поділитися на інших сайтах More sharing options... Назад 1 2 Вперед Сторінка 1 з 2 Створіть аккаунт або увійдіть для коментування Ви повинні бути користувачем, щоб залишити коментар Створити обліковий запис Зареєструйтеся для отримання облікового запису. Це просто! Зареєструвати аккаунт Вхід Уже зареєстровані? Увійдіть тут. Вхід зараз Share More sharing options... Передплатники 0 Перейти до списку тем Зараз на сторінці 0 користувачів Ні користувачів, які переглядиють цю сторінку
Dotrox Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 Единственное, что приходит в голову - это php_admin_flag и php_admin_value. Если где-то через них установлен показ ошибок, то никак это переопределить не получится. Надіслати Поділитися на інших сайтах More sharing options...
Yoda Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 4 часа назад, sitecreator сказал: Потратил несколько дней на серьезное изучение nginx + php-fpm. Всплыли некоторые особенности, о которых не думаешь вообще когда у вас установлен апаче + php (модуль) . Так, в частности, решения (модули) для работы по протоколу 1С CommerceML 2 без проблем (и лишних телодвижений и настроек) функционируют только в случае [nginx] + апаче + php (модуль). nginx в квадратных скобках означает, что он может быть, а может и отсутствовать. В случае работы php в режиме CGI/FastCGI с использованием Апаче или без него ( nginx+php-fpm ) нужны дополнительные настройки, а также может понадобиться некоторое изменение файлов Опенкарт, отвечающих за связь по протоколу 1С. Мне пришлось делать изменения в файлах в дополнение к настройкам в случае nginx+php-fpm. Вообще никакого описания настроек и необходимых изменений в случае если у вас не [nginx] + апаче + php (модуль) поставщиком файлов (exchange 1c, обмен с 1С) не предусмотрено. Та же "Большая птица", к примеру, предлагающая организацию складского и бух. учета (все по протоколу 1С) никакой документации в случае использования "нестандартного" сервера не предлагает. Но если не делать дополнительных настроек/изменений, то будет ситуация (со стороны 1С), что связь будет невозможна ("неверно указан адрес сайта" или "неверные логин/пароль"). Повторюсь, что эти сервисы складского и торгового учета (класс 365, Мой склад, Большая птица и т. д.), основанные на протоколе обмена 1С, никаких решений для "нестандартный" серверов не предлагают и даже в форуме поддержки слабо обращают внимание на данный вопрос. Решение для случая [nginx] + апаче + php (CGI/FastCGI) если работает описано здесь (для битрикса, разумеется): Не работает авторизация при обмене данными с 1С В Опенкарт поступаем аналогично. В случае nginx+php-fpm нужно в конфиге хоста добавить в блок обработки php строку: fastcgi_param REMOTE_USER $http_authorization; Тогда http авторизация будет работать. --------------------------------------------- Но в случае nginx+php-fpm открылись некоторые совершенно необъяснимые пока моменты. Например, при использовании файла .user.ini некоторые строки в нем игнорируются. display_errors = Off Вот это никак не работает в случае nginx+php-fpm. Хотя в случае апаче + php (в любом варианте) работает. memory_limit = 64M Это (да и многие другие директивы) работает, а отключение вывода ошибок не работает! Более того, не работает в коде php отключение ошибок: ini_set('display_errors', '0'); Также не работает в .user.ini в случае nginx+php-fpm и это: max_execution_time = 500 Если посмотреть мануал: http://php.net/manual/ru/errorfunc.configuration.php Я не смог отключить никаким образом мешающие nitice кроме одного способа: подавлением в самом коде за счет @ Вообще получил с показом ошибок пока непонятную ситуацию. Во всех php.ini файлах display_errors установлен в Off (0), причем настройки делались из ispmanager или вручную, но phpinfo неумолимо показывал, что во всех файлах php.ini отображение ошибок включено. Я не смог их отключить! php не реагирует на параметры ini файла! Повторюсь, что такое странное поведение с некоторыми директивами характерно только в случае php как FPM/FastCGI и nginx. В случае php как модуля апаче или апаче+ php (fastCGI) такой проблемы не возникает. Объяснения пока не нашел. Сталкивались ли с подобным? О да!!!! Это жестяная жесть, ставить nginx+phpfpm и пытаться настроить конфиги из ISP менеджера! Я смотрю тут проФФесионалы собрались. Как говорит один мой товарищ, у вас это выглядит как "копрофилия - попробовать можно, но об этом лучше никому не знать"! Надіслати Поділитися на інших сайтах More sharing options...
sitecreator Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 13 минут назад, Yoda сказал: Это жестяная жесть, ставить nginx+phpfpm и пытаться настроить конфиги из ISP менеджера! Додумали? Разумеется, что прописывались вручную. Через блокнотик, встроенный в ISPmanager. Разве из контекста не видно, что конфиги вручную правились? Просто привел для примера, что по умолчанию ispmanager, видимо, косячит иногда с конфигами. не более того. Богатый ли у вас опыт работы с nginx+phpfpm? Поделиться советом не желаете? Надіслати Поділитися на інших сайтах More sharing options... Yoda Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 27 минут назад, sitecreator сказал: Додумали? Разумеется, что прописывались вручную. Через блокнотик, встроенный в ISPmanager. Разве из контекста не видно, что конфиги вручную правились? Просто привел для примера, что по умолчанию ispmanager, видимо, косячит иногда с конфигами. не более того. Богатый ли у вас опыт работы с nginx+phpfpm? Поделиться советом не желаете? Нет не желаю. По двум причинам. Во первых к вам и дотроксу я испытываю глубокую личную неприязнь как к проФФесионалам с большой буквы. Во вторых по сути вопроса на 99% проектов прирост производительности настолько ничтожный, что это экономия на спичках. И в силу того что нативно Opencart заточен все-таки под работу в связке apache + mysql а не nginx+phpfpm + mysql, делать в такой конфигурации магазины я крайне не рекомендую никому! А вы сейчас два героя разведете здесь демагогию и начнется волна. А мне вот так надо - а так быстрее. А нифига так не быстрее. Подобное решение уместно абсолютно на высоконагруженных проектах от 100+ одновременных сессий - не вопрос. Актуально более чем. А на средней руки магазин даже в 5 000 хостов в день - это чистой воды погоня за модой и костыли! На те самые 99% магазинов достаточно поставить nginx как проксирующую заглушку, оптимизирующую раздачу статики и забыть про все проблемы с индивидуальным конфигурированием окружения. Надіслати Поділитися на інших сайтах More sharing options... Назад 1 2 Вперед Сторінка 1 з 2 Створіть аккаунт або увійдіть для коментування Ви повинні бути користувачем, щоб залишити коментар Створити обліковий запис Зареєструйтеся для отримання облікового запису. Це просто! Зареєструвати аккаунт Вхід Уже зареєстровані? Увійдіть тут. Вхід зараз Share More sharing options... Передплатники 0
Yoda Опубліковано: 1 березня 2017 Share Опубліковано: 1 березня 2017 27 минут назад, sitecreator сказал: Додумали? Разумеется, что прописывались вручную. Через блокнотик, встроенный в ISPmanager. Разве из контекста не видно, что конфиги вручную правились? Просто привел для примера, что по умолчанию ispmanager, видимо, косячит иногда с конфигами. не более того. Богатый ли у вас опыт работы с nginx+phpfpm? Поделиться советом не желаете? Нет не желаю. По двум причинам. Во первых к вам и дотроксу я испытываю глубокую личную неприязнь как к проФФесионалам с большой буквы. Во вторых по сути вопроса на 99% проектов прирост производительности настолько ничтожный, что это экономия на спичках. И в силу того что нативно Opencart заточен все-таки под работу в связке apache + mysql а не nginx+phpfpm + mysql, делать в такой конфигурации магазины я крайне не рекомендую никому! А вы сейчас два героя разведете здесь демагогию и начнется волна. А мне вот так надо - а так быстрее. А нифига так не быстрее. Подобное решение уместно абсолютно на высоконагруженных проектах от 100+ одновременных сессий - не вопрос. Актуально более чем. А на средней руки магазин даже в 5 000 хостов в день - это чистой воды погоня за модой и костыли! На те самые 99% магазинов достаточно поставить nginx как проксирующую заглушку, оптимизирующую раздачу статики и забыть про все проблемы с индивидуальным конфигурированием окружения. Надіслати Поділитися на інших сайтах More sharing options...
Recommended Posts