Вступление
Ваш файл php.ini обеспечивает значительную мощность над поведением вашей экосистемы PHP-приложений. Давайте рассмотрим некоторые из наиболее распространенных декларативов и обсудим, как они влияют на производительность и поведение вашего приложения. Я не буду подробно объяснять каждый доступный параметр, но расскажу об основных возможностях, о которых вам следует знать. Помните, что изменение любых настроек в вашем php.ini может и может очень хорошо изменить поведение вашего приложения, как положительное, так и неблагоприятное. Пожалуйста, соблюдайте осторожность при настройке своих настроек, проконсультируйтесь с вашей командой, проведите исследование, поймите последствия и, конечно же, протестируйте, протестируйте и протестируйте снова перед развертыванием чего-либо в производство!
Что такое php.ini?
Как и во всех сложных программных приложениях, поведение вашей среды выполнения PHP можно настроить с помощью файла php.ini. Это файл, который инструктирует, как должен вести себя PHP перед выполнением кода вашего PHP-приложения. Ваш php.ini обычно находится в каталоге ./lib, где вы установили PHP. Например, если вы установили php в / usr / local /, вы можете найти php.ini в / usr / local / php / lib.
Кроме того, вы можете найти его самостоятельно, обратившись к нашей функции «все полезные утилиты»:
<?php phpinfo(): ?>
Найдите строку «Загруженный файл конфигурации:»; это путь к вашему файлу php.ini.
Я организовал этот пост по следующим категориям: безопасность, память и производительность. Если вы заинтересованы только в одном аспекте, не стесняйтесь перейти к этой категории.
основы
Вы можете редактировать свой файл php.ini напрямую. Однако, в зависимости от того, как настроена ваша среда, вы можете использовать одну и ту же среду выполнения PHP, но иметь разные настройки для каждого приложения. В частности, если вы используете виртуальные хосты с Apache, например, вы настраиваете свой сервер так, чтобы файл .htaccess для каждого каталога приложения с конкретными декларациями php переопределял параметры php.ini по умолчанию. Кроме того, вы также можете переопределить настройки php.ini изнутри самого приложения в полете с помощью ini_set (). Имейте в виду, что ini_set () используется только во время выполнения скрипта при жизни и не будет постоянно сохранять свое значение.
На что влияет php.ini? Это влияет на все. Ну, почти все: у вас могут быть дополнительные конфигурационные файлы (например, apc.ini) для различных библиотек и инструментов, которые вы используете (уточните у системного администратора, пытаетесь ли вы настроить что-то, что не находится в вашем php.ini) , Вообще говоря, ваш php.ini содержит ключи к настройкам, которые влияют на безопасность, скорость и удобство работы вашего приложения. Мы рассмотрим некоторые основы и поймем, почему они важны, и углубимся в то, как вы можете оптимизировать свою среду для достижения своих целей. Мы начнем с пары простых примеров: short_open_tag и error_reporting.
short_open_tag
Этот тег является одним из моих любимых — он позволяет использовать стенографию <? вместо <? php при открытии кода PHP. С этим сокращением вы можете урезать свой код PHP в своем HTML, когда вам нужно сделать что-то вроде этого:
Hello, <?=$firstname>!
Если вы используете PHP в своем HTML, вы можете обрезать встроенный код, чтобы он стал более читабельным.
Отчет об ошибках
PHP имеет несколько уровней ошибок: E_ALL, E_NOTICE, E_WARNING и т. Д. Эта директива позволяет вам определять порог появления ошибки. Вам нужны разные уровни в разных средах, но старайтесь быть наиболее строгими в разработке и наименее производительными.
Обычная хитрость, о которой некоторые разработчики не знают, — преобразовывать ваши ошибки в исключения. Используя этот метод, вы можете «ловить» свои ошибки и «обрабатывать» их, как обычно. Это стало возможным благодаря использованию класса ErrorException с функцией set_error_handler () . Кроме того, используйте этот параметр в сочетании с display_errors при настройке обработки ошибок отображения в рабочей среде . Настройка этой директивы лучше всего, когда оптимизирована с дополнительными настройками .
Примечание: установка error_reporting в E_ALL или -1 покажет все возможные ошибки, но это зависит от вашей версии PHP. Убедитесь, что вы понимаете различия.
Безопасность
register_globals
Это разумно одна из самых опасных директив в PHP. Когда этот параметр включен, он позволяет входным данным, таким как POST или GET, быть доступными через переменную $ _REQUEST. Представьте, например, приложение, которое устанавливает переменную типа «admin» в переменной cookie, и доступ к этому значению осуществляется через $ _REQUEST [‘access_level’]. Если злонамеренный пользователь передаст «? Access_level = admin» в URL-адресе, $ _REQUEST потенциально может прочитать это как уровень доступа. Эта директива перешла из ON в OFF по умолчанию в PHP 4.2 и удалила ее в 5.4, поэтому индустрия сильно отошла от этой опасной практики. Тем не менее, это то, что вы должны знать в устаревшем коде.
magic_quotes_gpc
Я не буду подробно останавливаться на этом, поскольку это устарело с PHP 5.4, но это то, что вы должны отметить в унаследованном коде. Это декларативное объявление автоматически добавляет ‘\’, чтобы избежать экранирования специальных символов. К сожалению, это создало кошмар, когда в вашем коде есть addlashes () и stripslashes (), и вы пытаетесь отследить, когда и как PHP волшебным образом манипулирует вашими данными (каламбур). Короче говоря, выключите это, и забудьте, что это когда-либо существовало. Вы должны вручную экранировать ввод из открытых переменных другими способами, когда это необходимо.
expose_php
Если установлено значение «Вкл.», Это будет показывать общественности, что вы используете PHP и номер версии через X-Powered-By: в заголовке HTTP. Если это включено, вы подвергаете себя угрозам безопасности, которые могут быть раскрыты вашей версией PHP, или тем, что вы используете сам PHP. Держите это в стороне и не позволяйте публике знать, что вы используете под капотом. Чем меньше хакеры знают о вашей среде, тем меньше у них стратегии, как атаковать вас.
Память
output_buffering
Этот параметр контролирует, как ваш HTML отправляется в браузер. Когда этот параметр отключен, HTML-код отправляется в браузер по частям, когда PHP прочесывает последовательность выполнения и объединяет ваш динамический и статический контент. Когда он выключен, ваш HTML превращается в одну переменную и отправляется в браузер одним гигантским фрагментом. Пока вы складываете свой HTML-код, биты находятся в буферной «зоне», и вам все еще предоставляется доступ к данным, прежде чем они, наконец, отправляются в браузер. Таким образом, если вы столкнулись с ошибкой во время выполнения, вы можете отправить пользователю дружественное сообщение об ошибке вместо наполовину интерпретированной неработающей HTML-страницы. Этот параметр полезен, потому что он позволяет вам манипулировать вашим HTML так же, как вы бы манипулировали строкой в PHP, так что вы имеете больший контроль. В парадигме MVC,Вы можете извлечь выгоду из сшивания частичных модульных компонентов, составляющих окончательный вид.
max_execution_time
Когда приходит запрос и PHP начинает выполнять ваш код, для завершения транзакции требуется время. В некоторых ситуациях у вас может быть стек выполнения, который занимает слишком много времени. Это может произойти по разным причинам, таким как плохой код, зависшая база данных или медленные ответы от сторонних API веб-сервисов. В качестве отказоустойчивого PHP позволяет вам снизить этот риск, ограничивая время выполнения любым значением, которое вы здесь задаете. Если у вас высокий порог, ваши клиенты, естественно, будут страдать от низкой производительности. Я бы порекомендовал установить для этого значения достаточно времени, чтобы разумно собирать диагностические данные для блокировки, но не слишком долго, чтобы клиент мог ждать минуты, пока страница загрузится, потому что, конечно, они этого не сделают. Если вы обнаружите, что ваш код выполняется слишком долго, возможно, пришло время собрать диагностические данные с помощьюАгент AppDynamics для PHP .
Примечание: Вы можете установить это значение на 0 на бесконечное время, но это не очень хорошая идея в производстве по очевидным причинам. Не делайте этого. Существует встроенная функция, которая позволяет вам переопределить это значение. Если вам нужно переопределить его в определенных сценариях, вы можете изучить функцию set_time_limit (), которая эффективно выполняет ту же функцию ad hoc.
memory_limit
В дополнение к тому, сколько времени потребуется для выполнения вашего PHP-скрипта, есть также объем памяти, который ваш скрипт будет использовать. Этот параметр установит максимально допустимое количество памяти, которое будет выделено для сценария, так что если ваш сценарий выполняет хаос, вы можете ограничить его и защитить ресурсы сервера.
Примечание: я видел некоторые случаи, когда memory_limit установлен в -1, что позволяет неограниченную память. Это тоже, конечно, плохая идея. Используйте параметр -1 только в средах разработки и тестирования, если и когда это необходимо.
upload_max_filesize
Это декларативное описание допускает максимальный размер файла, который может быть загружен с сервера. В качестве хорошей практики, я думаю, что жюри уже вынесло решение по этому вопросу: не полагайтесь на один сервер для проверки размера файла; сначала проверьте это на стороне клиента. Исторически, форма загружала на сервер весь файл, прежде чем он был принят или отклонен. Это означает, что пользователь может загрузить файл размером 500 Мб, связать ресурсы сервера, рассчитывать на скорость загрузки в Интернет, а затем, наконец, отклонить свои входные данные. Представьте, что их форма не прошла проверку из-за неправильного адреса электронной почты: им придется повторить процесс. Хороший программист кэширует загруженный файл на стороне сервера, чтобы не ждать повторной загрузки файла, но если пользователь загружает другой файл, время ожидания должно будет повториться.Это опасная практика и потенциальная лазейка для хакеров.
post_max_size
Это устанавливает максимальный размер всех отправляемых данных POST. Разница между этим и upload_max_filesize заключается в том, что он регулирует весь размер данных, отправляемых на сервер, тогда как последний управляет размером отдельного файла. Отрегулируйте это соответственно.
max_input_time
Это максимальное количество времени, в течение которого скрипту разрешается анализировать входные данные, POST или GET. По сути, это максимальное количество времени, которое вы позволяете завершить загрузке. Например, если вы установите значение 60, загрузка должна завершиться в течение 1 минуты. Это проблема для пользователей с медленным интернет-соединением, но преимущество для вас состоит в том, чтобы убедиться, что ресурсы вашего сервера имеют надежную меру, чтобы избежать привязки.
include_path
Это определяет все различные системные пути, которые PHP должен искать при включении файлов в PHP (например, require (), include () и т. Д.). Чем короче этот список, тем выше ваша производительность, поскольку вам не придется тратить так много времени на поиск файлов.
Вывод
В дополнение к декларативам php.ini, упомянутым в этом посте, существуют десятки других декларативов, которые могут помочь в дальнейшей настройке и адаптации вашей экосистемы PHP, чтобы найти идеальный баланс безопасности, производительности, масштабируемости и оптимального взаимодействия с пользователем. Это всего лишь введение в возможности, предоставляемые вам настройками php.ini и предназначенные для того, чтобы вы освоились с различными конфигурациями, которые могут оказать на вас критическое влияние. Однако, когда вы настраиваете свой PHP, всегда помните, что ваша цель — найти правильный баланс, не жертвуя опытом конечного пользователя. Производительность приложений — движущаяся цель, и чем лучше вы будете осведомлены и обеспечены средствами достижения оптимального взаимодействия с пользователем, тем счастливее вы и ваши клиенты.
Проверьте AppDynamics для PHP, загрузите бесплатную пробную версию сегодня!