Хочу предложить  вашему вниманию небольшой материал, касающийся тонкой настройки PHP. Мне давно хотелось собрать описание настроек PHP  в одном месте, с указанием что лучше, а что нет. Давая рекомендации, я придерживаюсь разделения оных на две части: первая – наиболее эффективна для отладки скриптов и тестирования на локальных машинах, вторая – для использования скриптов уже на сервере.

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

Основной раздел конфигурационного файла php.ini

short_open_tag– разрешает использование коротких тэгов (<? … ?>) для оформления PHP кода. Считаю это излишним, зачем давать возможность использовать что-то, если оно уже есть. 
Рекомендация: Off

asp_tags – аналогично предыдущему, но касается тэгов (<% … %>). По-хорошему, надо вообще задаться вопросом, зачем это нужно. В PHP6 эта опция и возможность, скорее всего, будет исключена вовсе.
Рекомендация: Off

y2k_compliance – решение «проблемы 2000», уже не актуально.
Рекомендация: Off

expose_php – скрипт, через веб-сервер посылает пользователю заголовок, содержащий версию PHP. Смысл в этом – никакой, лишь даем потенциальному злоумышленнику лишнюю информацию о себе.
Рекомендация: Off

output_buffering – включение/выключение буферизации вывода. Буферизация сама по себе штука хорошая, но и использовать ее надо с умом, а не для тупого решения проблемы «Cannot send headers, headers already sent by…». Она хорошо может помочь при использовании сжатия, искусственного кэширования, поэтому, кому надо могут ее использовать через функции ob_*(), а включать ее изначально – лишняя нагрузка, которая ни к чему.
Ряд последующих директив (output_handler, zlib.output_compression, zlib.output_compression_level, zlib.output_handler, implicit_flush) соответственно либо отключаются, либо комментируются
Рекомендация: Off

open_basedir – данный каталог будет считаться корневым для работы с файлами и директориями в PHP. Это актуально при работе сервера, когда PHP разграничен между каждым пользователем. В реальности, такое встречается не часто.
Рекомендация:  пустое значение или закомментировать

disable_functions, disable_classes – директивы представляют интерес только для админов серверов. По-хорошему, они могут запретить функции и классы, чтобы лишний раз не сломали сервер, ввиду его безграмотной настройки.
Рекомендация: оставлять пустыми.

Группа настроек Safe Mode

C PHP6 «safe mode» будет убран, скорее всего, из языка. Использование safe mode, лично для меня, ничего кроме непонятного урезания возможностей языка не представляет. Ни с БД поработать, ничего…
Ряд последующих директив (safe_mode_gid, safe_mode_include_dir, safe_mode_exec_dir, safe_mode_allowed_env_vars, safe_mode_protected_env_vars) соответственно либо отключаются, либо комментируются
Рекомендация: Off

Управление ресурсами

max_execution_time = 30 – устанавливает время скрипта по стечении которого, автоматически происходит его программное снятие (прекращается выполнение). В тех задачах, где надо больше времени на обработку информации (работа с графикой, например), эта директива может быть перманентно изменена в самом скрипте через ini_set. Для обычных же скриптов время выполнения, как правило, не превышает секунды, в зависимости от «тормознутости» сервера 2-3 секунд, поэтому нечего грузить  сервер, если что-то пошло не так (зацикливание и т.п.).
Рекомендация: - 10

max_input_time = 60 – время, которое скрипт будет ждать входную информацию, к примеру с HTML формы. Если загружаете большие файлы, то делаете это значение побольше, если нет, поменьше. Т.к. эпоха dial-ip’a все-таки прошла, стандартного значения (60) вполне хватает для нормальной работы. Для очень уж больших файлов вообще лучше использовать FTP протокол.

memory_limit = 16M – ограничивает предел максимального значения памяти, которое может занимать скрипт и его дискрипторы. К примеру, fopen грузит весь файл в память, imagecreateformpng аналогично, при загрузке файла, также загружаемый файл использует этот же выделенный объем памяти. Примеров – много. Суть такая. Если вам не надо работать с большими файлами, делаете эту директиву поменьше, если надо – побольше. Само собой, чем меньше, тем лучше, но при этом не забываете о достаточности для решения стоящих перед скриптами задач.

post_max_size = 8M – ограничивает максимальный объем данных, получаемых от пользователя методом POST
Рекомендация: в любом случае он должен быть меньше memory_limit причем в два раза (условно, конечно).

upload_max_filesize = 2М – устанавливает максимальный размер файла, который может быть получен методом POST.
Рекомендация: в любом случае он должен быть меньше post_max_size.

Обработка ошибок

error_reporting – устанавливает  уровень показа ошибок.
Рекомендация: на домашнем сервере для отладки включаем показ ВСЕХ ошибок: E_ALL & E_STRICT, на сервере, ошибки не показываем (значение - 0). Во-первых, не позоримся, ваши скрипты должны работать без ошибок, во-вторых, не даем потенциальным злоумышленникам видеть пути и файлы и какие ошибки.

display_errors, display_startup_errors – устанавливают возможность показывать и не показывать сообщения об ошибках.
Рекомендация: аналогично error_reporting

log_errors, log_errors_max_len – запись ошибок в файл и длина строки оных, в файл, путь к которому установлен в error_log. Если честно, не вижу смысла. На сервере вывод ошибок отключен, считаем, что ошибок в скрипте – нет, для тестирования достаточно вывода ошибок в браузер, и смысла грузить сервер лишними действиями по логированию – нет.
Рекомендация: для отладки – выключаем, на сервере, все-таки включить можно.

ignore_repeated_errors, ignore_repeated_source – игнорирование повторов.
Рекомендация: вылючать, т.к. ошибки надо видеть все.

track_errors – запись ПОСЛЕДНЕЙ ошибки в $php_errormsg. Смысла нет. При тестировании ошибки видны в браузере, на сервере уже считаем, что скрипт сам работает с ошибками.
Рекомендация: отключить

Работа скриптов

register_globals– практически «убивает» понятие области видимости. В PHP6, скорее всего будет удалена, в целях безопасности и грамотного программирования.
Рекомендация: Off

register_long_arrays – позволяет использовать массивы HTTP_GET_VARS, как суперглобальные. Смысла в этом нет, темпаче эти переменные выйдут из PHP.
Рекомендация: Off

magic_quotes_gpc, magic_quotes_runtime, magic_quotes_sybase – автоматически экранируют получаемые от пользователя данные. В PHP6 этих настроек, скорее всего, не будет.
Рекомендация: вы сами должны управлять данными, получая их в исходном виде, следовательно, настройки ставятся в значение Off.

auto_prepend_file, auto_append_file – служат для указания файлов, которые будут автоматически выполняться до выполнения запрашиваемого файла. О выполнении этих файлов пользователь не узнает, если вы не сделаете какого-либо вывода. Можно использовать для запуска после выполнения запрашиваемого файла скрипта статистики.
Рекомендация: если действительно есть такая необходимость, значит, включайте, если можно обойтись, то не надо.

default_charset – установление кодировки. Иногда бывает необходимо ее прописать.
Рекомендация: прописывайте нужную вам кодировку.

allow_url_fopen – позволяет использовать URL’ы, в качестве параметров для функций файловой системы.
Рекомендация: Off, почему: 


allow_url_include – аналогична предыдущей, но для include подобных функций. Смысла нет опять-таки. Введена в 5.2.0.
Рекомендация: Off

А как же конструкции вида 

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

почему плохо?

Always use <?php ?> to delimit PHP code, not the <? ?> shorthand. This is required for PEAR compliance and is also the most portable way to include PHP code on differing operating systems and setups. © Pear Coding Standart

Подскажи, это имеется ввиду проблема в "годе"? Если на сайте есть, скажем, скрипт календаря старого - эту директиву все равно отключать?

Данные настройки allow_url_fopen, expose_php, open_basedir, ignore_repeated_errors, ignore_repeated_source, track_errors, register_long_arrays изменяются ли через .htaccess?

auto_prepend_file, auto_append_file - можно ли использовать, скажем, для подлючения конфига?

allow_url_include - если пхп 4ый - не стоит ее пытаться отключить?

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

Спасибо за ответы!

На нее забить можно... Это все от "проблемы 2000" для совместимости с очень старыми браузерами.


http://ru.php.net/manual/ru/ini.php#ini.list


Нет. Смысл этих директив в том, чтобы независимо от запрашиваемого файла выполнить какой-то скрипт до или после его выполнения.


Нет.


http://vingrad.ru/PHP-ART-002859

(далее ИМХО)


Не согласен, наоборот в РНР-5.2.0 должна быть включена обязательно, опасность представляет удалённый include (который включать очень опасно) но на версии 5.2.0 где он отключается отдельно и в таком случае удалённый fopen может во много раз упростить (ускорить) написание скрипта а стало быть сэкономить время, деньги и нервы !!!


В корне не согласен, это мало того "по стандарту" это ещё и главная часть "native-шаблонизаторa" для РНР

По этому пункту, позволю себе не согласиться, т.к. данная деректива _всегда_ должна быть E_ALL & E_NOTICE, почему она должна быть включена, читайте ниже. Фраза "не позоримся" убила вообще, если скрипт написан корректно и всё делается так, как должно, то даже E-NOTICE не появиться, о неопределённой переменной...

Если display_errors = Off на сервере, что вполне оправданно, то данная директива так же должна быть включена, потому что полагаться на то, что ошибок в скрите нет, мягко говоря глупо. Быть в этом уверенным можно только в одном случае: когда скрипта не существует. Объясняется это тем, что на этапе разработки от программиста какая-нибудь ошибка может ускользнуть, а при работе на хостинге она может появиться не в самый удачный момент. Конечно же показывать её пользователю не имеет смысла, а вот записать в лог, для дальнейшего анализа данного лога очень хорошая идея.

P.S. Программисты позоряться не появлением ошибок на экране, а своей халатностью к их исправлению и попыткам их скрыть. Рано или поздно они всплывут.

Это сообщение отредактировал(а) Fally - 16.7.2007, 10:00

(ИМХО) Единственно правильная идея

fopen(http://....) не содержи тайм аута, почему о его применении говорить даже не стоит... Плюс, я уже писал выше, что фопен все равно вызывает сокеты, так зачем, спрашивается поливать помидоры, если идет ливень?


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



Если мне не изменяет память, STRICT выше NOTICE, при крайней мере на момент написания было именно так.


Я писал с некоторой харизматической иронией, которую вы не просекли 



В принципе согласен с вами, но, если проект крупный и идет нагрузка на сервер, при условии что проект отлажен, нужды в этом - нет. И потом, как вы сказали: "если скрипт написан корректно и всё делается так, как должно, то даже E-NOTICE не появиться, о неопределённой переменной". Я бы тут исходил из конкретной ситуации, наверное.

 А где живет стандарт PHP?

 Только 2 пункт логичен, остальное притянуто за... [вставить нужное слово]

С пунктами 1 и 5 вообще не согласен.
1. Это удобно. Да и умный хостер всегда послушается нормального клиента.
5. Оверхед на C предпочтительнее оверхеда на PHP.

Это сообщение отредактировал(а) nerezus - 30.11.2007, 10:47

Сколько не искал, почему не стоит  использовать short_open_tag - не нашел... В основном говорят о каких то неизвестных стандартах, о том, что эта опция может быть отключена (чего ни разу за свой 5-летний стаж не наблюдал), о несоответствии xml... при чём тут xml вообще не понятно...

вывод такой: минусы использовния short tag -  кто то может сказать, что это не круто...
плюсы: читабельный html код, экономия времени разработки...

patt, 
<?php ?>
будет работать везде

<? ?>
нет

Одного этого минуса достаточно.

patt, PEAR Coding Standart, Zend Framework Coding Standart.. я на них всегда ориентируюсь.