Хочу предложить вашему вниманию небольшой материал, касающийся тонкой настройки 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, почему:
| Цитата |
Наболевший вопрос, который задается на форумах с периодичностью раз в 3-4 дня.
Как мы знаем, fopen, file, file_get_contents могут принимать в качестве параметра URL удаленного файла. НО использование этих функций не правильно, и вот почему:
1. Эти функции работают с удаленными хостами только при включенной директиве allow_url_fopen в php.ini (установить эту директиву в .htaccess или скрипте нельзя). Как правило, хостеры ее отключают. По крайней мере умные.
2. fopen не имеет параметра тайм-аута, что самое важное, т.к. в случае если сайт не отвечает или тяжело отвечает, скрипт может легко "подвиснуть".
3. Если где-то используется fopen и случайно пропущена обработка возможности ошибочного входного параметра, то может быть XSS или переполнения буфера.
4. Нет возможности указать порт, по которому необходимо соединиться с сервером.
5. Лишние операции, т.к. тот же fopen вызывать будет сокеты. Зачем использовать сверх функции?
|
allow_url_include – аналогична предыдущей, но для include подобных функций. Смысла нет опять-таки. Введена в 5.2.0.
Рекомендация: Off
|
)