Автоматическая оптимизация php.ini для Linux. Оптимизация php ini

Автоматическая оптимизация php.ini для Linux

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

Пользователем github из Германии - perusio опубликован скрипт на awk+bash, который автоматически приводит настройки php в соответствие с ресурсами сервера, включая улучшения безопасности.

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

Итак, скрипт предназначен для более тонкой настройки параметров php для работы как “боевого” сайта - production, так и для разработки - development.

В процессе разработки сайта нужно получать вывод различных ошибок как в лог-файлы, так и при открытии страниц сайта. Тогда как на “боевом” сайте вывод ошибок на экран окажется не только некрасивым, но и небезопасным. С помощью этих данных можно узнать:

путь до скриптов сайта
какие установлены и включены php-расширения
какие настройки используются для сайта
и тому подобное для проведения атак

Какие настройки PHP изменяются и зачем?

Скрипт изменяет следующие настройки:

Логирование ошибок. Для “боевого” сайта все ошибки отправляются в syslog, для разрабатываемого - выводятся на страницы сайта
Использование PHP. Не выводятся данные об использовании php
zlib-сжатие и ее уровень. Если доступно, используется zlib с уровнем сжатия 1.
Ограничение памяти. 512МБ
Максимальный размер запроса и максимальный размер файлов.
Параметр cgi.fix_pathinfo устанавливается равным 0. Сделано для того, чтобы не транслировать автоматически pathinfo. Но к этому параметру следует отнестись внимательней. К примеру, Drupal не использует PATHINFO, но Wordpress - да.
Не позволять открывать файлы по прямой ссылке для функций fopen или include. Только те файлы, что доступны веб-серверу или FastCGI-обработчику в файловой системе. Никаких внешних ресурсов.
Запрет обработки кукисов через DOM, например с помощью JavaScript. Все современные браузеры поддерживают флаг httponly, IE6, IE7 и IE8 так же поддерживают его.

Настройка дополнительной энтропии для генерации токенов сессий с использованием аппаратного генератора чисел /dev/urandom. Требуется php не ниже 5.3.

Установка и использование

Для использования этого скрипта выполните ряд несложных действий:

Склонируйте git-репозитарий или скачайте текущую версию кода и поместите на сервер

Запустите шелл-скрипт php_cleanup. Он поддерживает использование трех параметров:

production / development - указание “боевой” или разрабатываемый сайт
ограничение памяти для PHP. По умолчанию - 512МБ
путь до файла php.ini. По умолчанию ищется в той же директории, где запущен скрипт.

Примеры использования

Произвести обработку php.ini для “боевого” сайта, запустив скрипт в той же директории, где расположен php.ini:

php_cleanup -p

Произвести обработку php.ini для разрабатываемого сайта, запустив скрипт в той же директории, где расположен php.ini:

php_cleanup -d

Произвести обработку php.ini для “боевого” сайта, работающего на php-fpm, указав месторасположение php.ini (по умолчанию, пример для Debian):

php_cleanup -p /etc/php5/fpm/php.ini

Произвести обработку php.ini для “боевого” сайта, работающего на php-fpm, указав месторасположение php.ini (по умолчанию, пример для Debian) и установив ограничение памяти в 2Гб:

php_cleanup -p -m 2G /etc/php5/fpm/php.ini

firstvds.ru

Настройка систем LAMP, Часть 2: Оптимизация Apache и PHP

Настройка систем LAMP, Часть 2

Что замедляет работу Apache и как получить максимум от PHP

Шон ВолбергОпубликовано 05.07.2007

Серия контента:

Этот контент является частью # из серии # статей: Настройка систем LAMP, Часть 2

https://www.ibm.com/developerworks/ru/views/global/libraryview.jsp?series_title_by=Настройка+систем+lamp,+Часть+2

Следите за выходом новых статей этой серии.

Этот контент является частью серии:Настройка систем LAMP, Часть 2

Следите за выходом новых статей этой серии.

Linux, Apache, MySQL и PHP (или Perl) служат основой для архитектуры LAMP для Web-приложений. Многие пакеты с открытыми кодами, базирующиеся на компонентах LAMP, доступны для решения целого ряда задач. Поскольку нагрузка на приложение возрастает, узкие места основной инфраструктуры становятся более явными, что выражается в замедлении реакции на запросы пользователей. В предыдущей статье показано, как настроить систему Linux, и дано описание основ LAMP и измерения производительности. Эта статья сфокусирована на компонентах Web-сервера, как Apache, так и PHP.

Настройка Apache

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

Конфигурирование мультипроцессорных модулей

Приложение Apache является модульным, в том смысле, что вы легко можете добавлять и удалять его элементы. Эту модульную функциональность в ядре Apache -- управление сетевыми соединениями и отправку запросов -- обеспечивают мультипроцессорные модули (Multi-Processing Modules, MPM). Модули позволяют вам использовать thread'ы или даже перемещать Apache в другую операционную систему.

Одновременно может быть активен только один мультипроцессорный модуль и он должен быть скомпилирован статически при помощи --with-mpm=(worker|prefork|event).

Традиционная модель "один процесс на запрос" назвается prefork. Более новая, модель с thread'ами, называемая worker, использует несколько процессов, каждый с несколькими thread'ами, для получения более высокой производительности при более низких накладных расходах. Наконец, event -- экспериментальный модуль, который содержит особые группы thread'ов для различных задач. Чтобы определить, какой мультипроцессорный модуль вы сейчас используете, выполните httpd -l.

Выбор мультипроцессорного модуля зависит от многих факторов. Отключение модуля event до тех пор, пока он имеет экспериментальный статус, -- это выбор между thread'ами и их отсутствием. Внешне кажется, что использовать thread лучше, чем использовать fork, если все основные модули являются безопасными thread'ами, включая все используемые PHP библиотеки. Prefork -- более безопасный выбор; если вы выбрали worker, вы должны провести тщательное тестирование. Рост производительности также зависит от входящих в дистрибутив библиотек и вашего оборудования.

Независимо от того, какой мультипроцессорный модуль вы выбрали, вы должны соответствующим образом сконфигурировать его. Вообще, конфигурирование модуля подразумевает определение, как Apache контролирует количество запущенных worker'ов, являются ли они thread'ами или процессами. В Листинге 1 показаны важные опции конфигурирования модуля prefork.

Листинг 1. Конфигурирование мультипроцессорного модуля prefork

StartServers 50 MinSpareServers 15 MaxSpareServers 30 MaxClients 225 MaxRequestsPerChild 4000

В модуле prefork новый процесс создан при помощи запроса. Резервные процессы простаивают, чтобы общаться с поступающими запросами, что уменьшает время ожидания запуска. Предыдущая конфигурация запускает 50 процессов, как только стартует Web-сервер, и старается поддерживать в наличии от 10 до 20 простаивающих запущенных серверов. Жесткий лимит процессов определяется при помощи MaxClients. Даже если процесс может общаться с множеством последовательных запросов, Apache убивает процессы после 4,000 соединений, что уменьшает риск утечки памяти.

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

Выбор используемых значений подразумевает некий метод проб и ошибок. Наиболее важное значение -- MaxClients. Цель состоит в том, чтобы разрешить достаточное количество процессов worker или thread'ов, чтобы сервер не занимался исключительно свопингом. Если поступает больше запросов, чем может быть обработано, то по крайней мере те, которые поступили, обрабатываются; другие блокируются.

Если MaxClients слишком высок, все клиенты получают недостаточно высокий уровень сервиса, поскольку Web-сервер пробует выгрузить один процесс, чтобы позволить выполняться другому. Установка слишком низкого значения приводит к тому, что вы можете необоснованно отказать в обслуживании. Проверка количества процессов, запущенных в момент повышенной нагрузки, и анализ объема памяти, используемой всеми процессами Apache, дает вам хорошую идею относительно установки этого значения. Если вы устанавливаете значение MaxClients выше 256, вы должны установить то же значение для ServerLimit; внимательно прочтите документацию по мультипроцессорным модулям, чтобы узнать о соответствующих предостережениях.

Настройка числа запускаемых серверов и наличие запасных зависит от роли сервера. Если на сервере выполняется только Apache, вы можете использовать невысокое значение, как показано в Листинге 1, поскольку вы можете использовать машину в полной мере. Если система используется еще и базой данных или другим сервером, вы должны ограничить число запасных запущенных серверов.

Эффективное применение опций и переопределений

Каждый запрос, который обрабатывает Apache, проходит через сложный набор правил, которые диктуют любые ограничения или специальные инструкции, которым должен следовать Web-сервер. Доступ к папке может быть ограничен IP-адресом для определенной папки, или могут быть сконфигурированы имя пользователя и пароль. Эти опции также включают обработку определенных файлов, например, если предоставляется листинг каталога, они определяют, как будут обрабатываться определенные типы файлов, или должен ли быть сжат вывод.

Эти конфигурации имеют вид контейнеров в httpd.conf, например, <Directory> определяет, что конфигурация обращается к местоположению на диске, или <Location> задает отсылку на путь, указанный в URL. В Листинге 2 показан контейнер Directory в действии.

Листинг 2. Контейнер Directory, применяемый к каталогу root

<Directory /> AllowOverride None Options FollowSymLinks </Directory>

В Листинге 2 конфигурация, ограниченная тегами Directory и /Directory, применяется к данному каталогу и его содержимому -- в этом случае к каталогу root. Здесь тег AllowOverride определяет, что пользователям не разрешается отменять любые опции (более подробно об этом позже). Опция FollowSymLinks разрешена, что позволяет Apache видеть прошлые символьные линки для обслуживания запроса, даже если файл не входит в каталог, содержащий Web-файлы. Это означает, что если файл в вашем Web-каталоге является символьным линком на /etc/passwd, Web-сервер успешно обслужит файл, если поступит запрос. Использование -FollowSymLinks отключит эту возможность, и тот же самый запрос будет причиной возврата ошибки клиенту.

Последний сценарий -- повод для беспокойства на двух фронтах. Первый -- вопрос производительности. Если FollowSymLinks отключен, Apache должен проверять каждый компонент имени файла (каталоги и собственно файл), чтобы убедиться, что они не являются символьными линками. Это влечет дополнительные накладные расходы в форме нагрузки на диск. Сопутствующая опция FollowSymLinksIfOwnerMatch следует за символьным линком, если владелец файла тот же, что и владелец линка. Это оказывает такое же воздействие на производительность, как и отключение следования символьным линкам. Для наилучшей производительности используйте опции из Листинга 2.

Читатели, которых волнуют вопросы безопасности, уже должны быть обеспокоены. Безопасность -- всегда компромисс между функциональностью и риском. В этом случае функциональность -- это скорость, и риск предполагает неавторизованный доступ к файлам системы. Смягчающим фактором является то, что серверы приложений LAMP обычно предназначены для определенной функции, и пользователи не могут создавать потенциально опасные символьные линки. Если жизненно необходимо разрешить проверку символьной ссылки, вы можете разрешить это только в определенной области файловой системы, как показано в Листинге 3.

Листинг 3. Ограничение FollowSymLinks для каталога пользователя

<Directory /> Options FollowSymLinks </Directory> <Directory /home/*/public_html> Options -FollowSymLinks </Directory>

В Листинге 3 любой каталог public_html в домашнем каталоге пользователя имеет опцию FollowSymLinks, отключенную для этого и всех вложенных каталогов.

Как вы видели, опции могут конфигурироваться на покаталожной основе через конфигурацию главного сервера. Пользователи могут самостоятельно отменить конфигурацию сервера (если администратором разрешено AllowOverrides), исключив из каталога файл .htaccess. Этот файл содержит дополнительные директивы сервера, которые загружаются и применяются к каждому запросу каталога, в котором содержится файл .htaccess. Несмотря на прежние рассуждения об отсутствии в системе пользователей, многие приложения LAMP используют эту функциональность для осуществления контроля доступа и для перезаписи URL, так что это целесообразно для понимания того, как это работает.

Несмотря на то, что утверждение AllowOverrides препятствует пользователям в совершении тех действий, которые вы хотите им запретить, Apache по-прежнему должен искать файл .htaccess, чтобы выяснить, нужно ли что-нибудь сделать. Родительский каталог может определить директивы, которые должны быть обработаны запросом дочернего каталога, что означает, что Apache должен также исследовать каждый компонент дерева каталогов, ведущий к запрашиваемому файлу. По понятным причинам это является причиной высокой дисковой активности по каждому запросу.

Самое простое решение -- не позволять любые переопределения, которые отменяют необходимость проверки Apache файла .htaccess. Любые специальные конфигурации затем помещаются непосредственно в httpd.conf. В Листинге 4 показано, что нужно добавить в httpd.conf, чтобы позволить проверку пароля для пользовательского каталога project, вместо того чтобы помещать информацию в файл .htaccess и надеяться на AllowOverrides.

Листинг 4. Перемещение конфигурации .htaccess в httpd.conf

<Directory /home/user/public_html/project/> AuthUserFile /home/user/.htpasswd AuthName "uber secret project" AuthType basic Require valid-user </Directory>

Если конфигурация помещена в httpd.conf и AllowOverrides отключен, интенсивность использования диска может уменьшиться. Каталог пользователя project может не привлечь большого количества обращений, но учитывайте мощь этого метода применительно к сайту, работающему с большой нагрузкой.

Иногда невозможно исключить использование файлов .htaccess. Например, в Листинге 5, где выбор ограничен определенной частью файловой системы, возможность отмены также может быть ограничена.

Листинг 5. Ограничение проверки .htaccess

<Directory /> AllowOverrides None </Directory> <Directory /home/*/public_html> AllowOverrides AuthConfig </Directory>

После того как вы выполните операции из Листинга 5, Apache все же ищет файлы .htaccess в родительском каталоге, но прекращает поиск в каталоге public_html, поскольку становится невозможным функционирование остальной части файловой системы. Например, если запрашивается файл /home/user/public_html/project/notes.html, то его успешное отображение произойдет только в том случае, если каталоги public_html и project будут найдены.

Уместно сделать одно последнее замечание относительно относящихся к отдельным каталогам конфигураций. Любой документ о настройке Apache дает указание запретить DNS lookup через директиву HostnameLookups off, поскольку попытки обратно разрешить соединения всех IP-адресов с вашим сервером -- излишняя трата ресурсов. Однако любые ограничения, базирующиеся на имени хоста, вынуждают Web-север выполнять обратный lookup на IP-адресе клиента и прямой lookup на основании результата проверки подлинности имени. Поэтому благоразумно избегать использования средств контроля доступа, базирующихся на имени хоста, и, когда они необходимы, проверять их, как описано.

Постоянные соединения

Когда клиент соединяется с Web-сервером, разрешается порождение множественных запросов по одному и тому же TCP-соединению, что уменьшает время ожидания, связанное с многократными соединениями. Это полезно, когда Web-страница содержит несколько изображений: клиент может запросить страницу и затем все изображения в течение одного соединения. Обратная сторона состоит в том, что процесс worker на сервере должен ожидать закрытия сеанса клиентом, прежде чем он сможет перейти к следующему запросу.

Apache позволяет вам определять, как будут обработаны постоянные соединения, называемые keepalives. KeepAlive 5 на глобальном уровне httpd.conf позволяет серверу обработать 5 запросов на соединение, прежде чем соединение будет насильственно прервано. Установка этого числа в 0 запретит использование постоянных соединений. KeepAliveTimeout, тоже на глобальном уровне, определяет, как долго Apache будет ожидать другого запроса, прежде чем сессия закроется.

Обработка постоянных соединений не является конфигурацией типа "один-размер-годится всем". Некоторые Web-сайты функционируют лучше, если keepalives запрещены (KeepAlive 0), и в некоторых случаях их включение может принести огромную пользу. Единственное решение -- попробовать оба варианта и выяснить все самостоятельно. Тем не менее разумно использовать низкий таймаут, например, 2 секунды, при помощи KeepAliveTimeout 2, если вы разрешили keepalives. Это даст гарантии, что любой клиент, желающий сделать другой запрос, будет иметь достаточное количество времени, и что процессы worker не останутся без работы, пока будут ждать другого запроса, который может никогда не поступить.

Сжатие

Web-сервер может сжимать вывод, прежде чем он возвратить его клиенту. В результате уменьшается объем страницы, посылаемой по Интернету, за счет циклов CPU на Web-сервере. Для тех серверов, которые могут позволить себе высокую нагрузку на CPU, это отличный способ создания быстро загружаемых страниц — размер страницы может после сжатия уменьшиться втрое.

Изображения обычно уже сжаты, поэтому необходимо сжимать только текстовый вывод. Apache предусматривает сжатие при помощи mod_deflate. Несмотря на то, что mod_deflate может быть просто отключен, он содержит множество сложных моментов, которые руководство стремится объяснить. Эта статья не касается темы конфигурирования сжатия, за исключением предоставления ссылки на соответствующую документацию (см. раздел Ресурсы).

Настройка PHP

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

Кеширование кода операции

Когда запрашивается скрипт PHP, PHP читает скрипт и собирает его в то, что называется код операции Zend, бинарное представление кода, который будет выполнен. Этот код операции затем выполняется движком PHP и теряется. Кэш кода операции сохраняет его и в следующий раз при запросе страницы вновь использует. Это экономит немало времени. Некоторые кэши кода операции доступны; я успешно использовал eAccelerator.

Инсталляция eAccelerator требует наличия в компьютере библиотек разработки PHP. Поскольку разные дистрибутивы Linux помещают файлы в разные места, получите инструкции по инсталляции непосредственно с Web-сайта eAccelerator'а (см. ссылку в разделе Ресурсы). Также возможно, что ваш дистрибутив уже упаковал кэш кода операции, и вы должны просто установить соответствующий пакет.

Независимо от того, каким образом вы установили на своей системе eAccelerator, есть несколько вариантов конфигурации. Конфигурационным файлом обычно бывает /etc/php.d/eaccelerator.ini. eaccelerator.shm_size определяет размер кэша совместно используемой памяти, где хранятся скомпилированные скрипты. Значение измеряется в мегабайтах. Определение подходящего размера зависит от приложения. eAccelerator предоставляет скрипт для показа статуса кэша, который включает использование памяти; 64 мегабайта -- хорошее значение для начала (eaccelerator.shm_size="64"). Вы также можете настроить максимальный размер для shared memory, если выбранное вами значение не было принято. Добавьте kernel.shmmax=67108864 в /etc/sysctl.conf и запустите sysctl -p, чтобы настройки вступили в силу. Значение kernel.shmmax измеряется в байтах.

Если превышен объем выделяемой shared memory, eAccelerator должен удалить из памяти старые скрипты. По умолчанию это отключено; eaccelerator.shm_ttl = "60" устанавливает, что когда eAccelerator исчерпывает размер shared memory, любой скрипт, доступ к которому не был получен в течение 60 секунд, должен быть удален.

Другая популярная альтернатива eAccelerator -- Alternative PHP Cache (APC). Создатели Zend также имеют коммерческий кэш кода операции, включающий оптимизатор для дальнейшего повышения эффективности.

php.ini

Вы конфигурируете PHP в php.ini. Четыре важных параметра настройки определяют, какое количество системных ресурсов может потреблять PHP, как показано в Таблице 1.

Таблица 1. Параметры настройки php.ini, связанные с ресурсами

ПараметрОписаниеРекомендуемое значение

max_execution_time	Сколько CPU-секунд может потреблять скрипт	30
max_input_time	Как долго (в секундах) скрипт может ждать входных данных	60
memory_limit	Какое количество памяти (в байтах) может расходовать скрипт, прежде чем он будет убит	32M
output_buffering	Какое количество данных (в байтах) накапливается в буфере, прежде чем они будут отправлены клиенту	4096

Размер этих значений обычно зависит от приложения. Если вы принимаете от пользователей большие файлы, max_input_time может быть увеличен или в php.ini, или путем его переопределения в коде. Подобным образом, для программ, потребляющих большое количество CPU или памяти могут потребоваться более высокие значения. Цель состоит в том, чтобы уменьшить воздействие "прожорливой" программы, поэтому глобальная отмена этих настроек не рекомендуется. Другое замечание относительно max_execution_time: это относится ко времени, затраченному CPU на процесс, а не к абсолютному времени. Таким образом, программа, совершающая большое количество вводов/выводов и небольшое количество вычислений, может выполняться намного дольше, чем max_execution_time. max_input_time также может быть больше, чем max_execution_time.

Количество записей, которые может сделать PHP, может настраиваться. В промышленной эксплуатации экономят место на диске, отменяя все журналы, кроме самых критических. Если журналы необходимы для диагностики проблем, вы можете вернуть то журналирование, которое необходимо. error_reporting = E_COMPILE_ERROR|E_ERROR|E_CORE_ERROR включает журналирование, достаточное для выявления проблем, но удаляет из скриптов лишнюю информацию.

Заключение

Эта статья сфокусирована на настройке Web-сервера, как Apache, так и PHP. С Apache главная идея состоит в том, чтобы исключить лишние проверки, которые должен делать Web-сервер, например, обработку файла .htaccess. Вы также должны настроить мультипроцесорный модуль (MPM), который позволит сбалансировать используемые системные ресурсы и простаивающие worker'ы для входящих запросов. Лучшее, что вы можете сделать для PHP, -- установить кэш кода операции. Наблюдение за несколькими параметрами настройки ресурсов также гарантирует, что скрипты не завладеют ресурсами и не замедлят работу системы.

Следующая, заключительная статья из этой серии рассмотрит настройку базы данных MySQL. Не теряйте настрой!

Ресурсы для скачивания

PHP 7 – настройка файла PHP.INI

Конфигурационный файл php.ini является основным инструментом настройки ядра PHP. Он считается каждый раз при инициализации PHP. Если изменение не отображается, не забудьте остановить и перезапустить httpd. Если внесенные изменения до сих пор действуют, используйте функцию phpinfo(), чтобы проверить, php ini где лежит.

Файл конфигурации хорошо прокомментирован и подробно проработан. Параметры чувствительны к регистру, значения ключевых слов – нет; пробелы и строки, начинающиеся с точки с запятой, игнорируются. Логические значения могут быть представлены как 1/0, Yes/No, On/Off или True/False. Значения по умолчанию в php.ini повлияют на установку PHP, которую позже можно будет настроить.

В этой статье мы рассмотрим важные настройки в файле php.ini, которые могут потребоваться для PHP парсера.

short_open_tag = Off

Короткие открытые теги выглядят так: <? ?>. Для этого параметра должно быть установлено значение Off, если вы хотите использовать функции обработки XML.

safe_mode = Off

Если этот параметр имеет значение ON, вероятно, вы скомпилировали PHP с флагом enable-safe-mode. Безопасный режим наиболее важен для использования CGI.

safe_mode_exec_dir = [DIR]

Эта опция имеет значение только в том случае, если включен безопасный режим. Она также может быть установлена с флагом —with-exec-dir во время процесса сборки Unix. PHP в безопасном режиме выполняет внешние двоичные файлы только из этого каталога. По умолчанию используется каталог /usr/local/bin. Это не имеет ничего общего с обслуживанием обычной PHP/HTML веб-страницы.

safe_mode_allowed_env_vars = [PHP_]

Эта опция php ini задает, какие переменные окружения пользователи могут изменить в безопасном режиме. По умолчанию, только те переменные, к которым добавлено «PHP_». Если эта директива пуста, то большинство переменных можно изменять.

safe_mode_protected_env_vars = [LD_LIBRARY_PATH]

Параметр устанавливает, какие переменные окружения пользователи не могут изменить в безопасном режиме, даже если опция safe_mode_allowed_env_vars включена.

disable_functions = [function1, function2…]

Довольно полезным дополнением в конфигурации PHP4, которое сохранилось и в версии PHP5, является возможность отключения выбранных функций по соображениям безопасности. Раньше это требовало ручной правки кода на языке C, на котором был написан интерпретатор PHP. Функции файловой системы, операционной системы и сети должны быть первыми в этом списке, потому что возможность записи файлов и изменения системы через HTTP не является безопасным.

max_execution_time = 30

При настройке php ini нужно знать, что функция set_time_limit() не будет работать в безопасном режиме. Поэтому это основной способ реализовать задержку выполнения скрипта в безопасном режиме. В Windows вы должны выполнить принудительное завершение, основываясь на максимальном уровне потребляемой памяти, а не на времени. Также можно использовать настройку таймаута Apache для реализации задержки. Но она будет применена и к файлам сайта, не являющимся PHP.

error_reporting = E_ALL & ~E_NOTICE

Значением по умолчанию является E_ALL & ~E_NOTICE, все ошибки кроме уведомлений. Для серверов должно быть установлено, как минимум, значение по умолчанию. И только на основных серверах можно использовать меньшее значение.

error_prepend_string = [«»]

Вместе с error_append_string этот параметр позволяет выделить сообщения об ошибках другим цветом.

warn_plus_overloading = Off

Этот параметр выдает предупреждение, если оператор «+» используется со строками, как при формировании значения поля формы.

variables_order = EGPCS

Заменяет gpc_order. Обе версии устарели вместе с register_globals. Он устанавливает порядок различных переменных: Environment, GET, POST, COOKIE и SERVER (или Built-in). Вы можете изменить этот порядок. Переменные будут последовательно перезаписаны слева направо, при этом самый правый всегда «выигрывает». Это означает, что если оставить значение по умолчанию и использовать одно имя для переменной среды, переменной POST и переменной COOKIE, то, в конце концов, имя будет принадлежать переменной COOKIE.

register_globals = Off

Этот параметр php ini set позволяет определить, нужно ли регистрировать переменные EGPCS как глобальные. В настоящее время этот способ устарел, и, начиная с PHP 4.2, этот флаг по умолчанию установлен в значение Off. Вместо него используйте суперглобальные массивы.

gpc_order = GPC

Этот параметр устарел.

magic_quotes_gpc = On

Экранирует кавычки во входящих данных GET/POST/COOKIE. Если вы используете много форм, которые отправляют данные сами себе или другим формам, и отображают значения форм, нужно активировать эту директиву или использовать функции addslashes() для данных строкового типа.

magic_quotes_runtime = Off

Этот параметр экранирует кавычки во входящих строках базы данных и текстовых строках. Помните, что SQL добавляет слеш в одинарные кавычки и апострофы при сохранении строк и не убирает их при возвращении строк. Если этот параметр выключен, необходимо использовать функцию stripslashes() при выводе любых типов строковых данных из БД SQL. Если для magic_quotes_sybase установлено значение On, то этот параметр должен быть Off.

magic_quotes_sybase = Off

Экранирует одиночные кавычки во входящих строках базы данных и текстовых строках с одиночными кавычками в стиле Sybase, а не обратным слешем. Если для параметра magic_quotes_runtime установлено значение On, данный параметр должен быть отключен.

auto-prepend-file = [path/to/file]

Если в этом параметре php ini указан путь, PHP должен автоматически добавить конструкцию include() в начало каждого PHP-файла. Следует учитывать ограничения для путей включаемых файлов.

auto-append-file = [path/to/file]

Если в этом параметре указан путь, PHP должен автоматически ввести конструкцию include() в конец каждого PHP-файла, кроме случаев, когда осуществляется выход с помощью функции exit (). Следует учитывать ограничения для путей включаемых файлов.

include_path = [DIR]

Если установить это значение, вам будет разрешено включать или запрашивать файлы только из указанных каталогов. Каталог include обычно находится под корневым документом. Это необходимо, если вы работаете в безопасном режиме. Установите для параметра значение .in, чтобы включить файлы из каталога, в котором находится ваш скрипт. Несколько каталогов разделяются двоеточиями: .:/usr/local/apache/htdocs:/usr/local/lib.

doc_root = [DIR]

При настройке php ini если вы используете Apache, то в файле httpd.conf корневой каталог документа для этого сервера или виртуального хоста уже задан. Установите это значение здесь, если используете безопасный режим или хотите разрешить PHP только для части сайта (например, только в одном подкаталоге).

file_uploads = [on/off]

Активируйте этот флаг, если загружаете файлы с помощью PHP-скрипта.

upload_tmp_dir = [DIR]

Не удаляйте комментарии из этой строки, если не понимаете, что такое HTTP-загрузка!

session.save-handler = files

За исключением редких случаев изменять этот параметр не нужно.

ignore_user_abort = [On/Off]

Определяет, что произойдет, если посетитель сайта нажмет в своем браузере кнопку «Остановить». По умолчанию установлено значение On, которое означает, что скрипт продолжит работать до завершения или таймаута. Если изменить значение данного параметра на Off, скрипт будет прерван. Этот параметр работает только в режиме модуля, а не в CGI.

mysql.default_host = hostname

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

mysql.default_user = username

Этот параметр php ini задает имя пользователя по умолчанию, используемое при подключении к серверу базы данных, если другое имя не указано.

mysql.default_password = password

Пароль по умолчанию, используемый при подключении к серверу базы данных, если не указан другой пароль.

Перевод статьи «PHP 7 — PHP.INI File Configuration» был подготовлен дружной командой проекта Сайтостроение от А до Я.

www.internet-technologies.ru

Оптимизация Apache 2, PHP и MySql в среде Windows

Как то я обещал, что напишу, о том как настроить на локальном хостинге под Windows связку Apache, PHP и MySql для получения максимальной производительности.

Многие программисты при разработке и тестировании сайтов используют локальный персональный компьютер под управлением OS Windows на котором эмулируют работу реальном хостинге. Можно самому установить Apache, PHP и MySql на компьютер, можно воспользоваться готовыми пакетами инсталяций типа Denver, XAMPP и другие. Настроки по умолчанию установленных пакетов оставляют желать лучшего и вот почему.

У меня довольно мощные персоналки, но удивило то, что разность генерации одних и техже страниц на реальном хостинге при примерно одиноаковой конфигурации железа с локальным сервером составляет 10-100 раз! Неужели Windods настолько плох для Apache, PHP и MySql? Но ведь работает же достаточно быстро и эффективно IIS и ASP на серверах и на локальном сервере у меня на IIS все шустро шевелится. Оказывается все дело в "кривых руках" так сказать :)

Анализируя проблему и сравнивая всевозможными методами замеры производительности маркеров в скриптах, внимательно изучая конфигурационные файлы как серверов Apache и MySql так и IIS и MS Sql Server, рыская по многочисленным форумам нашел причины. По умолчанию включенные в дистрибутивы Apache, PHP и MySql настройки предназначены скорее всего под Linux/Unix платформы. Отсюда и растут грабли.

Оптимизация Apache 2 и PHP.

Основная проблема в производительности Apache+PHP на Windows платформе, это медленные файловые операции. Linux/Unix с файлами работает очень шустро и все это настроено на уровне операционной системы. Каких либо настроек по оптимизации файловой системы в Windows я не знаю, может быть они и есть но о них мне неизвестно. (позже я нашел одну такую настройку)

При малом количестве файлов участвующих в генерации страниц практически незаметна разница генерации между Unix и Windows, однако часто сайты используют всевозможные движки или библиотеки, а они состоят из сотен, а то и тысяч фалов. Например Joomla 1.5 состоит из более чем 6000 файлов мелкого размера. В основном это скрипты PHP. На доступ к ним и считывание по мере генерации страницы и тратится основное время.

Что делать?

Опытным путем было установлено что нужно оптимизировать файловый кеш и кеш памяти. Что меняем?

php.ini

realpath_cache_size=16000k (default - 16k) realpath_cache_ttl=1200 (default - 120)

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

Оптимизация MySql.

С базой данных MySql основное время занимает установка соединения. Как оказалось по умолчанию соединение идет через tcp/ip порт. Каково же было мое удивление, когда я увидел что на установку соединения с базой MySql из PHP уходит порядка 0.7-0.5 сек! Причем при последующих запросах это время практически не уменьшается. Для ускорения на Unix серверах при локальном подключении рекомендуют использовать socket=mysql (специальный прямой поток), но на Windows этого нет. Зато есть

named-pipe. При использовании именованного канала время подключения составляет менее 0,01 - 0,005 сек, и при последующих запросах практически стремится к нулю. Но о том как его использовать и настроить написано очень мало на форумах, я с трудом нашел на форумах у буржуев, как настроить и как правильно использовать именованный канал потом при подключении.

Включаем его в конфигурации my.cnf и при обращении из скриптов PHP в данном случае нужно обращаться к серверу локальному как ".". Также рекомендую в php.ini прописать mysql.default_host=".", чтобы по умолчанию при неуказанном имени сервера в соединении использовать именованный канал вместо порта tcp/ip.

my.cnf

[mysqld] enable-named-pipe

php.ini

Используя выше приведенные параметры у меня ускорилась генерация страниц под управлением CSM Joomla 1.5 c 2.1 - 1.8 сек до 0.8 - 0.3 сек на локальном хостинге. На реальном платном хостинге под unix те же страницы генерируются 0,3 - 0,14 сек.

carmind30.blogspot.com