Какие ограничения в PHP существуют?

Question

[eugene159]

Я знаю только 6:

1. max_execution_time - максимальное время выполнения скрипта.
   
2. mysql.connect_timeout - максимальное время ожидания ответа от MySQL.
   
3. post_max_size - максимальный размер всего POST запроса.
   
4. upload_max_filesize - максимальный размер файла, передаваемого методом POST.
   
5. memory_limit - максимальный размер используемой ОЗУ.
   
6. default_socket_timeout - максимальное время ожидания ответа при работе через сокет.
   

1 и 2 нужно увеличить, если не хватает времени выполнения для долгого скрипта.
3 и 4 нужно увеличить, если на сервер отправляются слишком большие файлы.
5 нужно увеличить для тяжелых скриптов, требующих много ОЗУ.
6 нужно увеличить, если отваливается соединение через сокет.

Кроме того, в браузере тоже есть ограничение по времени ожидания ответа от сервера. Кажется, его настроить никак нельзя. Для очень долгих скриптов надо использовать AJAX-запросы. Ну либо выполнять их через CLI. Но меня интересует режим HTTP, а не CLI.

Можете сказать, какие еще есть? Да, все они написаны в мануале. Но там очень много чего написано, можно случайно упустить какую-либо директиву. И потом долго гадать, почему правильно написанный скрипт не работает.

Может, есть ограничения не только в php ini, но и в apache / nginx? Может, есть на уровне ОС? Если так, то напишите, пожалуйста, про них.

Comments

[Ипатьев]

вторая не имеет отношения к долгим и тяжелым скриптам, а третья - к заливанию

[eugene159]

Ипатьев, да, я немного опечатался, поправил

[Vitsliputsli]

все они написаны в мануале. Но там очень много чего написано, можно случайно упустить какую-либо директиву. И потом долго гадать, почему правильно написанный скрипт не работает.

Не нужно гадать, в логах все отражается. А если нет, то расширяйте логирование.
И не получится описать все, не описывая все.

[Ипатьев]

К отправке файлов третья тоже не имеет отношения.
Отправка - это передача по сети. При чем тут память?

[eugene159]

Ипатьев, post_max_size не имеет отношения к файлам?
память - это пятая, а не третья.

[eugene159]

Я подредактировал ответ, чтобы там были не маркеры, а числа. Теперь путаницы не ложно быть.

[eugene159]

Vitsliputsli, как ты расширишь логирование у сайта на CMS? Будешь лазить по файлам CMS и добавлять свои функции для логирования?

[Vitsliputsli]

eugene159, php сам логирует все что нужно, дополнять нужно то, что сам писал. В любом случае, решать проблемы наугад меняя конфиги в надежде что вдруг заработает - это путь в никуда.
Что за CMS и что она не логирует?

[eugene159]

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

[eugene159]

Vitsliputsli, какая у тебя ошибка выдается, если отвалилось соединение с БД? а если не хватает ОЗУ? где эта ошибка выводится? В логах PHP? На самой странице, где выполняется код? У меня такие ошибки никогда не выводились. Я догадывался о них интуитивно. Как раз таки пробуя менять лимиты.

[Vitsliputsli]

eugene159, да, но есть ли пример такой проблемы, которую нельзя обнаружить по логам из-за "кривых" плагинов и которая решается настройкой конфига php (на конфиги nginx или систему плагину уж точно не могут повлиять)?

[Vitsliputsli]

eugene159,

какая у тебя ошибка выдается, если отвалилось соединение с БД?

Выкидывается exception PDO, который логируется с указанием причины разрыва соединения.

а если не хватает ОЗУ?

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

В логах PHP?

именно.

На самой странице, где выполняется код?

обычно туда технические ошибки не выводят.

У меня такие ошибки никогда не выводились. Я догадывался о них интуитивно. Как раз таки пробуя менять лимиты.

Об этом и речь, быть может стоит пересмотреть вопрос логирования. Я просто предлагаю, если это невозможно, я не настаиваю.

[eugene159]

Vitsliputsli, у меня стоит

ini_set('display_errors', '1');
ini_set('display_startup_errors', '1');
error_reporting(E_ALL);

В начале скрипта. Но такие ошибки не выводятся. Я подумал, может, дело в настройках apache / nginx. Но ты сказал PHP.

Ты в Open Server разрабатываешь? Может, проблема в нем.

[Vitsliputsli]

eugene159, apache / nginx в эту ситуации ни при чем, в OpenServer они запущены или иначе тоже.
Указанных настроек должно быть достаточно для вывода ошибок на экран. Возможно, что-то перехватывает исключения и обрабатывает их внутри себя, или вероятнее подключение к СУБД происходит в другом месте с другим настройками, тогда нужно смотреть функционал обработки ошибок в CMS, и вряд ли это делают плагины. Возможно, в CMS есть режим дебага, при включении которого, вывод ошибок будет прямо на экран.
Ну и посмотреть файловый лог, в него CMS обязана писать, оставить разработчика без логов это совсем не адекватно.

Answer 1

[Дмитрий]

имя им легион
php -i | egrep 'limit|timeout|max'

hard_timeout => 2 => 2
log_errors_max_len => 1024 => 1024
max_execution_time => 0 => 0
max_file_uploads => 20 => 20
max_input_nesting_level => 64 => 64
max_input_time => -1 => -1
max_input_vars => 1000 => 1000
memory_limit => -1 => -1
post_max_size => 8M => 8M
upload_max_filesize => 2M => 2M
zend.exception_string_param_max_len => 0 => 0
mbstring.regex_retry_limit => 1000000 => 1000000
mbstring.regex_stack_limit => 100000 => 100000
memcached.default_connect_timeout => 0 => 0
memcached.sess_connect_timeout => 0 => 0
memcached.sess_lock_max_wait => not set => not set
memcached.sess_lock_wait_max => 150 => 150
memcached.sess_server_failure_limit => 0 => 0
mysqli.max_links => Unlimited => Unlimited
mysqli.max_persistent => Unlimited => Unlimited
Read timeout => 86400
pcre.backtrack_limit => 1000000 => 1000000
pcre.recursion_limit => 100000 => 100000
pgsql.max_links => Unlimited => Unlimited
pgsql.max_persistent => Unlimited => Unlimited
session.cache_limiter => nocache => nocache
session.gc_maxlifetime => 1440 => 1440
default_socket_timeout => 60 => 60
unserialize_max_depth => 4096 => 4096
xdebug.connect_timeout_ms => 200 => 200
xdebug.max_nesting_level => 256 => 256
xdebug.max_stack_frames => -1 => -1
xdebug.remote_timeout => (setting renamed in Xdebug 3) => (setting renamed in Xdebug 3)
xdebug.var_display_max_children => 128 => 128
xdebug.var_display_max_data => 512 => 512
xdebug.var_display_max_depth => 3 => 3
opcache.force_restart_timeout => 180 => 180
opcache.jit_bisect_limit => 0 => 0
opcache.jit_max_exit_counters => 8192 => 8192
opcache.jit_max_loop_unrolls => 8 => 8
opcache.jit_max_polymorphic_calls => 2 => 2
opcache.jit_max_recursive_calls => 2 => 2
opcache.jit_max_recursive_returns => 2 => 2
opcache.jit_max_root_traces => 1024 => 1024
opcache.jit_max_side_traces => 128 => 128
opcache.max_accelerated_files => 10000 => 10000
opcache.max_file_size => 0 => 0
opcache.max_wasted_percentage => 5 => 5

Вы явно пытаетесь что то не то.

Answer 2

[SagePtr]

Ещё есть ограничение на одновременную работу с сессиями. Нельзя одну и ту же сессию открыть дважды параллельно, не закрыв старый экземпляр, новый будет ждать освобождения блокировки.

Comments

[eugene159]

Что это за директива в php_ini?

[SagePtr]

eugene159, это особенность реализации встроенного механизма сессий и не настраивается директивами конфигурации

Answer 3

[ThunderCat]

какая у тебя ошибка выдается, если отвалилось соединение с БД? а если не хватает ОЗУ? где эта ошибка выводится? В логах PHP? На самой странице, где выполняется код? У меня такие ошибки никогда не выводились. Я догадывался о них интуитивно. Как раз таки пробуя менять лимиты.

Все ошибки логируются, если специально не выключать логи. По этому чтобы знать что за ограничение у вас сработало, не надо тыкать пальцем в небо и молиться Линусу Торвальдсу, надо просто посмотреть что конкретно произошло и решать конкретную проблему.

Но такие ошибки не выводятся. Я подумал, может, дело в настройках apache / nginx. Но ты сказал PHP.

Хостер может запретить изменение настроек сервера через ini_set, так что это ни о чем не говорит. В логах в любом случае ошибка отразится.

Comments

[eugene159]

Я поставил Open Server 5.4.2. Настройки по умолчанию я не менял, только xdebug включил.

У меня есть код, который выполняется очень долго. Код пытается достать 28653 товара из mysql и вывести их характеристики на страницу сайта.

Сайт написан на CMS MODX.

В начале этого кода я пишу такое:

ini_set('display_errors', '1');
ini_set('display_startup_errors', '1');
error_reporting(E_ALL);

Дальше я играюсь вот с этими значениями:

ini_set('memory_limit', '1M');
ini_set('mysql.connect_timeout','1');
ini_set('max_execution_time', '1');

Тут самые минимальные ограничения.

Открываю страницу в браузере. Выводится шапка сайта и подвал. Посередине должна быть информация о товарах. Но ее просто нет.

В логах PHP у Open Server ничего не пишется. В ошибках Apache тоже ничего не пишется.

Почему? Как исправить?

[eugene159]

Поправка: ошибка с max_execution_time выводится. Остальное - нет.

Fatal error: Maximum execution time of 1 second exceeded

[ThunderCat]

eugene159, ну, некоторый налет идиотизма при выводе 28 653 итемов на страницу присутствует. Скорее всего просто сам браузер не вытягивает такой фигни. Для начала попробуйте вывести меньшее количество элементов, и разобраться что код принципиально работает.

[eugene159]

ThunderCat, я это делал. Код работает.

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

[ThunderCat]

eugene159, 99% проблема не в ошибке, проблема в отображении. Просто уменьшите количество элементов в несколько раз и все начнет выводиться (но это не точно). Постепенно добавляя элементы определите какое количество элементов на страницу выводится нормально.