Содержание:
Веб-серверы могут обрабатывать php-скрипты в разных режимах. Если выбрать подходящий вариант взаимодействия PHP и веб-сервера на сайте, например, PHP как CGI или Apache-модуль, это положительно отразится на его производительности.
Выбрать режим работы PHP можно на VPS с панелью управления ISPmanager и Plesk. На виртуальном хостинге REG.RU по умолчанию используется режим FastCGI.
Подробнее о том, какие режимы PHP поддерживаются на хостинге REG.RU, читайте в статье.
В этой статье мы рассмотрим основные режимы работы PHP.
PHP как модуль Apache (mod_php)
Модуль для веб-сервера Apache, который позволяет ему обрабатывать все запросы PHP, не используя сторонние модули.
Можно вводить переменные PHP в .htaccess.
отдельные пользователи на сервере с mod_php не могут вносить изменения, если у них нет прав доступа на все процессы, с которыми он работает. Иными словами, права веб-сервера должны выдаваться всем пользователям на сервере;
Низкий уровень безопасности, так как нельзя определить пользователя, который запустил конкретный процесс (все процессы выполняются анонимно под пользователем apache);
Ошибки в скриптах могут парализовать работу всего сервера;
Веб-серверы с mod_php медленно обрабатывают статические данные.
PHP в режиме CGI и FastCGI
PHP CGI — один из первых сценариев обработки php-скриптов сервером с помощью модуля mod_cgi. Сейчас он используется редко и считается устаревшим.
В этом режиме каждый php-запрос выполняется отдельным процессом. Из-за этого производительность сайта снижается, и на обработку скриптов требуется больше времени.
При создании сценария FastCGI учли медленную скорость обработки скриптов в CGI, поэтому в этом режиме используется циклическая обработка нескольких запросов одним процессом. FastCGI — это экономия оперативной памяти за счет сокращения количества запущенных процессов.
Пользователь обладает правами на выполнение всех скриптов на своем www-домене;
Безопасность (каждый запрос выполняется под отдельным пользователем, запуск небезопасного php-скрипта не повлияет на файлы других пользователей, которые находятся на одном с ним сервере);
Каждый пользователь на сервере может выбрать персональную версию PHP;
Отсутствие сбоев сервера при наличии ошибок в скриптах;
Обработка правил конфигурационного файла .htaccess, который поддерживается популярными CMS (WordPress, Joomla, 1C-Битрикс и пр.).
Чуть меньшая производительность по сравнению с модулем Apache;
Медленная обработка статических данных без связки с веб-сервером Nginx.
PHP в режиме FPM
FPM (FastCGI Process Manager) — альтернативная реализация PHP FastCGI. PHP FPM — это единственный модуль, который подходит для чистого веб-сервера Nginx.
Как работает PHP FPM:
Быстрая обработка статических данных;
Отсутствует необходимость в веб-сервере Apache;
Меньшее потребление оперативной памяти.
- Отсутствует поддержка конфигурационного файла .htaccess. Это требует самостоятельной настройки аналогичных правил на стороне веб-сервера Nginx.
О выборе режима PHP
Выбор режима PHP зависит от требований ваших сайтов и доступных ресурсов сервера. В большинстве случаев мы рекомендуем использовать клиентам режим FastCGI, так как он подходит для корректной работы большинства CMS и требует меньше действий со стороны пользователя.
Откройте для себя возможности виртуального выделенного сервера на SSD.
PHP в рамках виртуального хостинга может работать в двух режимах — mod_php и mod_cgi.
По умолчанию на новых серверах PHP работает в режиме mod_php, но при желании вы можете подключить режим mod_cgi. Для этого воспользуйтесь предложенной ниже инструкцией.
1. Подключитесь к серверу по SSH.
2. Перейдите в папку cgi-bin сайта командой вида:
3. Создайте символическую ссылку следующей командой (при необходимости замените php5.3 на нужную вам версию обработчика):
4. Находясь в директории cgi-bin, скопируйте файл php.ini:
5. Добавьте в файл .htaccess вашего сайта следующие строки:
php://input возвращает все необработанные данные после HTTP-заголовков запроса, независимо от типа контента.
Данные, могут быть:
- application/x-www-form-urlencoded ( application/x-www-form-urlencoded тип application/x-www-form-urlencoded для простых форм- application/x-www-form-urlencoded ) или
- multipart/form-data-encoded (в основном multipart/form-data-encoded для загрузки файлов)
Это связано с тем, что это единственные типы контента, которые должны поддерживаться браузерами. Поэтому сервер и PHP традиционно не ожидают получения какого-либо другого типа контента (что не означает, что они не могли бы).
Если вы просто отправляете POST-ом обычную HTML-форму, запрос выглядит примерно так:
Но если вы много работаете с Ajax, может понадобиться обмен более сложными данными с типами (строка, int, bool) и структурами (массивы, объекты), поэтому в большинстве случаев JSON является лучшим выбором. Но запрос с JSON-полезной нагрузкой выглядел бы примерно так:
Теперь содержимое будет application/json (или, по крайней мере, ни один из вышеперечисленных), так что $_POST -wrapper из PHP не знает, как с этим справиться (пока).
Данные всё еще там, вы просто не можете получить к нему доступ через $_POST. Поэтому вам нужно получить его с "сыром" виде помощью file_get_contents(‘php://input’) (если он не закодирован в формате multipart/form-data).
Это также способ доступа к XML-данным или любому другому нестандартному типу контента.