15%

Сэкономьте 15% на всех хостинговых услугах

Проверьте свои навыки и получите скидку на любой тарифный план

Используйте код:

Skills
Начать
04.01.2024

LiteSpeed Хостинг и управление версиями PHP: Полное техническое руководство для пользователей AlexHost

Выбор правильной версии PHP для вашей хостинговой среды — одно из наиболее важных решений при развёртывании веб-приложений. Неверная версия может незаметно снизить производительность, создать уязвимости безопасности или полностью нарушить совместимость с фреймворком. Общий хостинг AlexHost на базе LiteSpeed поддерживает PHP 7.3, 7.4, 8.0 и 8.1 одновременно, позволяя назначать разные версии PHP для каждого домена через MultiPHP Manager в cPanel — без изменения файлов конфигурации сервера и без обращения в службу поддержки.

В этом руководстве рассматривается, что каждая версия PHP реально обеспечивает на уровне движка, как правильно переключать версии в инфраструктуре AlexHost и как избежать распространённых ошибок, приводящих к сбоям приложений после смены версии.

Почему выбор версии PHP важнее, чем думает большинство разработчиков

PHP — не монолитная среда выполнения. Каждый мажорный и минорный релиз изменяет поведение Zend Engine, объявляет функции устаревшими, меняет правила приведения типов и модифицирует взаимодействие OPcache и JIT-компилятора с вашим кодом. Запуск кода PHP 7.3 на PHP 8.1 без тестирования — это не безопасное обновление, а риск для вашей производственной среды.

LiteSpeed Web Server выполняет PHP через LSAPI (LiteSpeed Server Application Programming Interface), который архитектурно отличается от mod_php или FastCGI в Apache. LSAPI поддерживает постоянные рабочие процессы PHP, устраняя накладные расходы на создание процессов для каждого запроса, характерные для традиционных конфигураций. Результат — заметно меньшее время до первого байта (TTFB) и значительно сниженное потребление CPU на запрос, что особенно важно для PHP-интенсивных приложений, таких как WordPress, Magento или Laravel.

Сочетание LSAPI LiteSpeed с MultiPHP Manager в cPanel обеспечивает изоляцию версий PHP на уровне процессов для каждого домена, а не только на уровне конфигурации. Это принципиальное различие для агентств или разработчиков, размещающих сайты нескольких клиентов на одном аккаунте общего веб-хостинга.

Сравнение версий PHP: матрица функций и безопасности

Функция / АтрибутPHP 7.3PHP 7.4PHP 8.0PHP 8.1
Официальная поддержка безопасностиЗавершена дек. 2021Завершена ноя. 2022Завершена ноя. 2023Завершена ноя. 2024
JIT-компиляторНетНетДа (экспериментальный)Да (улучшенный)
Типизированные свойстваНетДаДаДа
Стрелочные функцииНетДаДаДа
Union-типыНетНетДаДа
Именованные аргументыНетНетДаДа
Выражение matchНетНетДаДа
Атрибуты (аннотации)НетНетДаДа
Перечисления (Enums)НетНетНетДа
Файберы (корутины)НетНетНетДа
Readonly-свойстваНетНетНетДа
Пересекающиеся типыНетНетНетДа
Nullsafe-операторНетНетДаДа
Предзагрузка OPcacheНетДаДаДа
Относительная производительность к 7.3Базовая+~5-10%+~15-20%+~20-25%

Ключевой вывод из этой таблицы: PHP 7.3 и 7.4 вышли за пределы официального срока поддержки. Их следует использовать только тогда, когда устаревшее приложение имеет жёсткие зависимости, которые невозможно устранить, — но не в качестве выбора по умолчанию для новых развёртываний.

PHP 7.3: устаревшая стабильность с известными ограничениями

PHP 7.3 был выпуском, ориентированным на обслуживание, который представил array_key_first(), array_key_last(), гибкий синтаксис heredoc/nowdoc и функцию is_countable(). Он представлял собой стабильную платформу для приложений, работавших на PHP 5.x и нуждавшихся в пути миграции без масштабного рефакторинга.

Критическая операционная реальность: PHP 7.3 достиг конца жизненного цикла в декабре 2021 года. Он не получает патчей безопасности от проекта PHP. Использование его в производственной среде означает, что любая вновь обнаруженная уязвимость в Zend Engine или основных расширениях останется неисправленной. Единственная законная причина использовать PHP 7.3 на AlexHost сегодня — поддержка устаревшего приложения в период активной миграции на PHP 8.x.

Типичный сценарий использования: старые установки Joomla 3.x, устаревшие приложения CodeIgniter 3 или пользовательские кодовые базы эпохи PHP 5.6, которые не были обновлены для использования современных объявлений типов.

PHP 7.4: последний из ветки 7.x — полезен для переходных развёртываний

PHP 7.4 стал финальным релизом ветки PHP 7 и представил несколько функций, которые сделали код значительно более удобным в обслуживании и производительным без необходимости вносить критические изменения, появившиеся в PHP 8.0.

Типизированные свойства класса позволяют применять ограничения типов на уровне класса:

class User {
    public int $id;
    public string $email;
    public ?DateTime $lastLogin;
}

Это устраняет целую категорию ошибок времени выполнения, которые ранее проявлялись только при определённых путях выполнения.

Стрелочные функции сокращают многословность коротких замыканий, особенно полезны в операциях с массивами:

$multiplied = array_map(fn($n) => $n * 2, $numbers);

Предзагрузка OPcache (введённая в 7.4) архитектурно значима: она позволяет PHP загружать и компилировать набор файлов в общую память при запуске сервера, делая эти файлы доступными для всех рабочих процессов без повторной компиляции. На LiteSpeed с LSAPI это усиливает преимущество производительности, поскольку постоянные рабочие процессы уже устраняют накладные расходы на создание процессов.

PHP 7.4 достиг конца жизненного цикла в ноябре 2022 года. Он подходит для установок WordPress, работающих со старыми плагинами с известными несовместимостями с PHP 8.x, или для развёртываний Drupal 7, ожидающих миграции.

PHP 8.0: архитектурная точка перегиба

PHP 8.0 не был инкрементальным релизом. Он представил изменения, которые фундаментально изменили способ написания, выполнения и осмысления PHP-кода. Ряд давно существовавших поведений был изменён или удалён, что сделало его критическим обновлением для кодовых баз, полагавшихся на нестрогое приведение типов или устаревшие функции.

JIT-компиляция

JIT-компилятор в PHP 8.0 компилирует часто используемые пути кода в нативный машинный код во время выполнения, минуя повторную интерпретацию. В нагрузках, ограниченных CPU, — математических вычислениях, обработке изображений, конвейерах преобразования данных — JIT может обеспечить существенное ускорение. Однако для типичных веб-приложений, ограниченных I/O (запросы к базе данных, чтение файлов, вызовы API), преимущество JIT зачастую незначительно, поскольку узким местом является не выполнение CPU, а ожидание внешних ресурсов.

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

Union-типы и именованные аргументы

Union-типы позволяют параметру функции или возвращаемому значению явно принимать несколько типов:

function processInput(int|string $input): int|false {
    // ...
}

Именованные аргументы отделяют порядок аргументов от сигнатур функций, значительно улучшая читаемость функций с несколькими необязательными параметрами:

array_slice(array: $data, offset: 2, length: 5, preserve_keys: true);

Выражение match

Выражение match заменяет switch со строгим сравнением типов, без сквозного выполнения и с возвратами на основе выражений:

$status = match($code) {
    200, 201 => 'success',
    404 => 'not found',
    500 => 'server error',
    default => 'unknown',
};

В отличие от switch, match выбрасывает UnhandledMatchError, если ни одна ветка не совпадает и не предусмотрено значение по умолчанию — что делает скрытые сбои невозможными.

Атрибуты (структурированные метаданные)

Атрибуты PHP 8.0 заменяют аннотации в docblock, используемые такими фреймворками, как Doctrine и Symfony. Они разбираются самим движком, а не пользовательскими регулярными выражениями:

#[Route('/api/users', methods: ['GET'])]
public function listUsers(): Response { ... }

Это имеет существенные последствия для производительности фреймворков и точности инструментов IDE.

PHP 8.1: современный PHP производственного уровня

PHP 8.1 — версия, на которую большинство новых проектов должны ориентироваться на момент написания этой статьи. Она строится на основе PHP 8.0 и добавляет функции, устраняющие давние пробелы в системе типов языка и модели параллелизма.

Перечисления

Enums решают проблему «магических констант», преследовавшую кодовые базы PHP на протяжении десятилетий:

enum Status: string {
    case Active = 'active';
    case Inactive = 'inactive';
    case Pending = 'pending';
}

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

Файберы: кооперативная многозадачность

Файберы вводят низкоуровневый примитив параллелизма в PHP. В отличие от потоков, файберы кооперативны — они явно передают управление. Это основа, которую асинхронные PHP-фреймворки (такие как ReactPHP и Amp) используют для реализации неблокирующего I/O без необходимости в расширениях вроде Swoole:

$fiber = new Fiber(function(): void {
    $value = Fiber::suspend('first suspension');
    echo "Resumed with: " . $value;
});

$value = $fiber->start();
$fiber->resume('hello');

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

Readonly-свойства

Readonly-свойства обеспечивают неизменяемость после инициализации, что необходимо для объектов-значений и доменных сущностей в архитектурах DDD (Domain-Driven Design):

class OrderId {
    public function __construct(
        public readonly string $value
    ) {}
}

После установки в конструкторе $value не может быть изменено. Любая попытка выбрасывает Error. Это устраняет целый класс шаблонного защитного кода.

Пересекающиеся типы

Там где union-типы говорят «это ИЛИ то», пересекающиеся типы говорят «это И то» — требуя, чтобы значение реализовывало несколько интерфейсов одновременно:

function processEntity(Serializable&Countable $entity): void { ... }

Это особенно ценно в архитектурах контейнеров сервисов и конвейеров промежуточного программного обеспечения.

Как изменить версии PHP на хостинге AlexHost LiteSpeed через cPanel

Среды VPS с cPanel и общего хостинга AlexHost предоставляют управление версиями PHP через MultiPHP Manager в cPanel. Вот точная процедура:

Шаг 1: Войдите в панель управления cPanel

Войдите в свой аккаунт AlexHost и перейдите в раздел Данные для входа, чтобы получить учётные данные cPanel. Откройте cPanel напрямую по предоставленному URL (обычно yourdomain.com:2083 или прямой IP с портом).

Шаг 2: Перейдите в MultiPHP Manager

В cPanel найдите раздел Программное обеспечение. Нажмите MultiPHP Manager. В этом интерфейсе перечислены все домены и поддомены, связанные с вашим аккаунтом, каждый с отображаемой текущей назначенной версией PHP.

Шаг 3: Выберите целевой домен и версию PHP

Установите флажок рядом с доменом или поддоменом, который хотите изменить. Используйте раскрывающийся список Версия PHP, чтобы выбрать из доступных версий — PHP 7.3, 7.4, 8.0 или 8.1 в зависимости от конфигурации вашего тарифного плана. Нажмите Применить.

Шаг 4: Проверьте изменение

После применения изменение вступает в силу немедленно для новых запросов. Проверьте, создав временный файл phpinfo.php в корневом каталоге документов домена:

<?php phpinfo(); ?>

Подтвердите версию PHP в выводе, затем немедленно удалите этот файл — оставление phpinfo() в производственной среде является уязвимостью безопасности, раскрывающей конфигурацию вашего сервера злоумышленникам.

Шаг 5: Протестируйте функциональность приложения

Не считайте изменение версии PHP безопасным без тестирования. Проверьте журнал ошибок вашего приложения (/home/username/logs/ или через инструмент Ошибки в cPanel) на наличие уведомлений об устаревании, фатальных ошибок или вызовов неопределённых функций, указывающих на несовместимость.

Переопределение версии PHP для отдельного каталога через .htaccess

Для детального управления — например, запуска устаревшего подкаталога на PHP 7.4, пока основной сайт работает на PHP 8.1 — вы можете переопределить версию PHP на уровне каталога с помощью .htaccess:

<FilesMatch ".php$">
    SetHandler application/x-httpd-ea-php81
</FilesMatch>

Формат имени обработчика — application/x-httpd-ea-phpXX, где XX соответствует номеру версии без десятичной точки. Это соглашение EasyApache 4, используемое в средах cPanel.

Матрица решений по выбору версии PHP

СценарийРекомендуемая версия PHPОбоснование
Новый проект на Laravel 10+ или Symfony 6+PHP 8.1Требует минимум PHP 8.1; полная поддержка функций
WordPress 6.x (все плагины обновлены)PHP 8.1Официальная рекомендация; прирост производительности
WordPress с устаревшими плагинами (до 2022 г.)PHP 7.4 или 8.0Проверьте совместимость перед обновлением
Magento 2.4.6+PHP 8.1Официальная матрица поддержки требует 8.1
Drupal 10PHP 8.1Минимальное требование
Устаревший Joomla 3.xPHP 7.3 или 7.4Joomla 3.x не полностью совместима с PHP 8.x
Пользовательское устаревшее приложение (до 2018 г.)PHP 7.3Мигрируйте как можно скорее
Новый API-микросервис или CLI-инструментPHP 8.1Доступны Enums, Fibers, readonly-свойства

Последствия для безопасности при использовании версий PHP с истёкшим сроком поддержки

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

  • CVE, обнаруженные после EOL, не исправляются в затронутой ветке версии.
  • Среды общего хостинга особенно уязвимы, поскольку скомпрометированный PHP-процесс потенциально может затронуть соседние аккаунты в зависимости от конфигурации изоляции.
  • Соответствие PCI DSS явно запрещает использование программного обеспечения, вышедшего за пределы срока поддержки поставщика. Если вы обрабатываете платежи, использование PHP 7.3 или 7.4 является нарушением требований соответствия.
  • Брандмауэры веб-приложений (WAF) могут снизить некоторые риски, но не могут исправить уязвимости на уровне движка.

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

Особенности производительности PHP в LiteSpeed

Ряд особенностей LiteSpeed взаимодействует с выбором версии PHP способами, которые не очевидны:

LiteSpeed Cache (LSCache): плагин LSCache для WordPress работает на уровне веб-сервера, а не PHP. Однако улучшенные показатели попаданий в OPcache в PHP 8.x означают, что промахи кэша обслуживаются быстрее, снижая штраф за производительность при незакэшированных запросах.

Постоянство рабочих процессов LSAPI: LiteSpeed сохраняет рабочие процессы PHP между запросами. Это означает, что JIT-компилятор PHP 8.1 имеет больше возможностей для прогрева и оптимизации часто используемых путей кода по сравнению с традиционной настройкой CGI, где каждый запрос запускает холодный процесс.

PHP-FPM против LSAPI: на панелях управления VPS, где вы самостоятельно настраиваете стек, вы можете выбирать между PHP-FPM и LSAPI. LSAPI стабильно превосходит PHP-FPM в тестах производительности для сред LiteSpeed, поскольку использует специально разработанный протокол связи, а не универсальный интерфейс FastCGI.

Лимиты памяти и количество рабочих процессов: PHP 8.x имеет несколько более высокий базовый объём потребляемой памяти по сравнению с PHP 7.x из-за дополнительных структур времени выполнения для JIT и системы типов. Если вы работаете в среде с ограниченной памятью, отслеживайте настройки memory_limit после обновления.

Практический контрольный список ключевых выводов

Перед изменением или выбором версии PHP на хостинге AlexHost LiteSpeed проработайте этот контрольный список:

  • Проверьте официальную матрицу совместимости PHP вашего приложения — не угадывайте. Laravel, WordPress, Magento и Drupal публикуют минимальные и максимальные поддерживаемые версии PHP.
  • Проверьте установленные плагины и расширения — сторонний код является наиболее распространённым источником несовместимости с PHP 8.x. Запустите composer check-platform-reqs, если используете Composer.
  • Сначала протестируйте изменение — используйте поддомен или промежуточную среду для тестирования изменения версии PHP перед применением в производственной среде.
  • Немедленно проверьте журналы ошибок после переключения — ищите записи E_DEPRECATED, E_NOTICE и E_FATAL, указывающие на нарушение совместимости.
  • Удалите все файлы phpinfo(), созданные во время проверки.
  • Не используйте версии PHP с истёкшим сроком поддержки в производственной среде, если у вас нет задокументированного плана миграции с ограниченными сроками и компенсирующих мер безопасности.
  • Используйте MultiPHP INI Editor (также в разделе «Программное обеспечение» cPanel) для настройки директив PHP для каждого домена, таких как memory_limit, upload_max_filesize и max_execution_time, после смены версии — значения по умолчанию различаются между версиями.
  • Если вашему приложению требуется PHP 8.2 или 8.3, рассмотрите переход на тариф VPS, где вы контролируете полный программный стек и можете установить любую версию PHP через репозитории, такие как Remi или ondrej/php.

Часто задаваемые вопросы

Могу ли я запускать разные версии PHP на разных доменах в рамках одного аккаунта общего хостинга AlexHost?

Да. MultiPHP Manager в cPanel применяет настройки версии PHP на уровне каждого домена. Каждый домен или поддомен в вашем аккаунте может независимо работать на разной версии PHP, управляемой через тот же интерфейс без влияния на другие домены.

Требует ли переключение версий PHP в MultiPHP Manager перезапуска сервера или вызывает простой?

Нет. Изменение вступает в силу немедленно для новых входящих запросов. Существующие длительные PHP-процессы могут продолжать работать на старой версии до завершения, но для типичных веб-запросов этот переход незаметен и не вызывает измеримого простоя.

Автоматически ли JIT-компилятор PHP 8.1 ускорит мой сайт на WordPress?

Не значительно для стандартных развёртываний WordPress. JIT выгоден для нагрузок, ограниченных CPU. Производительность WordPress в первую очередь ограничена временем выполнения запросов к базе данных и операциями I/O, которые JIT не ускоряет. Более значимые улучшения PHP 8.x для WordPress — лучшая эффективность OPcache и сниженные накладные расходы на вызовы функций.

В чём разница между MultiPHP Manager и MultiPHP INI Editor в cPanel?

MultiPHP Manager управляет тем, какая версия PHP назначена каждому домену. MultiPHP INI Editor управляет директивами конфигурации PHP (настройками php.ini) для каждой комбинации домена и версии PHP. Оба инструмента необходимы для полного управления средой PHP — выбор версии сам по себе не настраивает лимиты памяти, тайм-ауты выполнения или загрузку расширений.

Что делать, если моё приложение перестаёт работать после обновления до PHP 8.x?

Сначала откатитесь к предыдущей версии PHP в MultiPHP Manager для восстановления работы. Затем изучите журналы ошибок на предмет конкретных сообщений об ошибках. Распространённые проблемы включают удалённые функции (each(), create_function()), изменённое поведение приведения типов и устаревшие методы конструктора класса. Устраните каждую проблему в промежуточной среде перед повторной попыткой обновления. Если приложение является CMS или фреймворком, проверьте, существует ли обновлённая версия с официальной поддержкой PHP 8.x.

15%

Сэкономьте 15% на всех хостинговых услугах

Проверьте свои навыки и получите скидку на любой тарифный план

Используйте код:

Skills
Начать