1. Главная страница » Компьютеры » Php cgi или модуль apache

Php cgi или модуль apache

Автор: | 16.12.2019

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

GGI — самый старый способ запуска скриптов (в том числе и php). В этом случае на каждый хит запускается интерпретатор php как самостоятельное приложение и ему отдаётся скрипт для запуска. Скрипт должен вернуть заголовки, затем код html страницы. После этого интерпретатор прекращает свою работу.

Модуль Apache — в этом случае php постоянно находится в памяти веб сервера, не тратится время на запуск интерпретатора.

FastCGI — эволюция CGI интерфейса, в этом случае php запускается отдельным процессом, но после выполнения скрипта не прекращает свою работу.

Действительно ли он такой быстрый, этот FastCGI? Проверим!

На одной машине установлен Apache 2.2 + MySQL 5, а также демонстрационный сайт "Битрикс Бизнес". Кеширование компонентов битрикс отключил чтобы случайное пересоздание кеша не повлияло на результаты.
Здесь я умышленно не акцентирую внимание на аппаратной части и конфигурации т.к. повторюсь, задача не получить абсолютные величины, а сравнить разные режимы работы php.
Другая машина по локальной сети создаёт имитацию нагрузки на сервер. Для этого я использовал JMeter .
Он написан на Java и сам создаёт приличную нагрузку , поэтому для чистоты эксперимента мне пришлось его "отделить" от сервера.

План тестирования состоял из 6 страниц, по 2 параллельных запроса. Постарался выбрать наиболее динамически загруженные страницы, для удобства дал им условные названия по контенту. Не следует ассоциировать скорость отдачи страниц с одноимёнными модулями.
Загружался только динамический код страниц без статики, соответственно nginx не использовал (подробности в учебном курсе ).

Итак, всё готово, приступаем к тестированию.

Тестирование без акселератора php

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

Синий — среднее время отдачи на каждом хите в мс
Пурпурный — статистическое среднее
Красный — отклонение от среднего
Зелёный — скорость отдачи страниц

В итоге имеем среднее время 5,5 секунды на страницу, скорость отдачи страниц — 105 в минуту.
Обратите внимание, здесь время на страницу — это время, которое реально ждёт пользователь, а не среднее по всем параллельным запросам (во втором случае мы получим 105/60 = 1,75 сек на страницу).

Отдельно по страницам получилась такая диаграмма (среднее время ответа):

Здесь уже результат получше — 122 страницы в минуту. И соответственно, диаграмма:

Совсем неплохой результат по сравнению с традиционным CGI: 120 страниц в минуту, чуть медленнее, чем модуль.
Диаграмма:

Но как изменится картина если установить акселератор php?

Результаты тестирования с установленным EAccelerator

CGI — EA
Известно, что акселератор не работает в CGI режиме т.к. ему нужен доступ к общей памяти из всех процессов. Но в phpinfo есть информация о том, что eaccelerator загружен и создаётся ощущение, что он работает. Давайте проверим.

108 страниц в минуту. Это практически тот же результат что и был. Диаграмма:

309 страниц в минуту, среднее время ожидания ответа 1 секунда. Я бы сказал, это уже что-то. Ну и соответственно по страницам:

294 страницы в минуту, т.е. примерно на 5% медленнее, чем модуль. Но всё равно не идёт ни в какое сравнение с традиционным и неторопливым CGI режимом.

В среднем по страницам также прослеживается небольшое отставание от модуля.

А есть ли другие проблемы?

  • Как CGI, так и FastCGI работают независимо от веб сервера. А это значит что если происходит какая-то ошибка, веб сервер не получает заголовки от скрипта и возвращает нам в ответ " Ошибка 500 на стороне сервера". Чтобы узнать какая произошла ошибка, надо смотреть логи сервера, к которым далеко не всегда есть прямой доступ у пользователя. В случае модуля Apache ошибка может сразу отобразиться на экране (если включен вывод ошибок) и отладка скриптов осуществляется гораздо проще и быстрее.
  • В CGI/FastCGI режимах есть проблема с авторизацией HTTP, как следствие — проблема с интеграцией с 1С, есть и другие специфические проблемы.
  • При загрузке в Apache модуля php мы получаем замечательную возможность менять на лету некоторые настройки php через .htaccess, в CGI/FastCGI опять же получим ошибку 500.
  • Основной довод сторонников CGI/FastCGI — это безопасность. Т.к. php работает как отдельное приложение — пользователи хостинга на системном уровне отделены друг от друга, а в режиме модуля существует гипотетическая возможность ломать соседние сайты на хостинге. Отчасти это так, но на сегодняшний день существуют определённые механизмы защиты и по опыту техподдержки могу сказать, что основную проблему безопасности пользователей представляют трояны, которые воруют пароли ftp и вживляют паразитный код на сайты.

Хостеры часто используют CGI т.к. в этом случае гораздо удобнее управлять [читать: резать] ресурсами пользователей. И в итоге получаем "непонятные ошибки".

Хочу упомянуть ещё об одном важном моменте: сегодня php идёт одним файлом для CGI и FastCGI режимов, в phpinfo видим:

Server API: CGI/FastCGI

А значит слабо представляется возможным на пользовательском уровне выяснить, как на самом деле работает php. Учитывая скудную документацию по настройке FastCGI очень может быть, что вы будете введены в заблуждение.

Читайте также:  Olap системы предназначены для

Выводы или "Как же выбрать хостера?"

Если вы простой пользователь, вероятно, прокрутили весь технический груз чтобы сразу найти ответ на вопрос.

  • Выбирайте CGI режим если ваш сайт посвящён восточной философии и время загрузки страниц посетителей сайта не волнует.
  • FastCGI даёт хорошие результаты по производительности, но ему присущи проблемы CGI режима, а это постоянные ошибки сервера "500".
  • В остальных случаях рекомендую использовать php как модуль Apache . Особенно если речь идёт о выделенном сервере или VPS.
  • Обязательно обращайте внимание на акселератор php . К сожалению, многие хостеры не уделяют этому вопросу должного внимания.
  • И вот ещё важный момент: не выбирайте в качестве хостера соседа по лестничной клетке, порой элементарное неумение настроить систему приносит больше проблем, чем всё остальное. Выбирайте профессионалов .
  • Рекомендуем перед долговременной покупкой хостинга тестировать его нашим скриптом . Мы периодически обновляем скрипт с учётом новых проблем.

Смотрите сами и делайте выводы. К сожалению, пользователь начинает понимать важность "правильного" хостинга только после того как столкнулся с чередой проблем.

К сожалению, пользователь начинает понимать важность "правильного" хостинга только после того как столкнулся с чередой проблем.

>Хорошо если есть возможность.
У нас вот как раз другой случай. Я именно и хотел отметить, что мы "не имели возможность" (сейчас конечно имеем), а "были вынуждены" самим заморачиваться. И это был хоть и проблемный, но полезный опыт.
А началось все с того, что один из проектов, которым я занимаюсь, переехал на выделенный сервер, арендованный у одного хостера. (я позже скажу кто это) Сервер взяли с администрированием, т.е. они должны были все поддерживать и следить за сервером. После некоторых переговоров с ТП хостера, и ихних заверений, что сделаем все как надо (я им скидывал ваши рекомендации), мы оплатили и перенесли сайт. И начались проблемы. Сайт лежал по два часа в день. Перечислять что и как все решалось, сколько времени я убил на разговоры почти со всеми из их ТП и т.д. — мне пол дня понадобится.
Я, тем временем болея за проект, сам вникал во всю вашу документацию по настройке (я то как раз мат. часть хорошо знаю — т.е. теорию и все технологии. и мне все понятно, но вот где ручками что сделать надо, увы — нет практики) и вместе с ТП хостера пытался выяснить в чем проблема.
В итоге они нас "развели" на гиг памяти, хотя надо признаться он реально был нужен. После этого вроде стало все стабильно работать, но прошла неделя стабильной работы и опять начались проблемы такие же. Хотя посещаемость не выросла, нагрузка тоже. Начались опять дебаты, в процессе которых они начали опять говорить про еще два гига памяти. Причем аренда гига памяти у них стоит 350 рублей в месяц, при стоимости самого гига в 800 р Я сразу понял, что дело тут не чисто. я человек прямой, и когда я понимаю, что мне пудрят мозги, я просто посылаю открытым текстом в жопу (а то еще дальше, но рядом), что я и сделал.
Естественно они это перенести не смогли и даже пообещали в одностороннем порядке расторгнуть договор (чего они не сделали, конечно,ибо были бы юридически не правы).

После такого поворота событий я был вынужден искать помощи, кстати в первую очередь обратился здесь на форуме. Откликнулся Евгений Педан, за что ему отдельное спасибо. Он нам там "подкрутил некоторые гайки", и кстати он и обнаружил, что там даже не стояло (. ) php-акселератора. Вообщем хостер реально плевать хотел на те ваши рекомендации, которые я им скидывал, кстати, они потом прокомментировали это так: битрикс кто? пишет цмс? ну вот и пусть пишет — они нам не показатель, а мы хостинг компания — нам лучше знать.

Нафига нам было обещать тогда рекомендации выполнить до заключения договора. Непонятно..

Евгений нам помог, но решить полностью проблему не смог, т.к. сервер на FreeBSD, а Евгений опытен в Linux. Вообще пришлось открывать свою записную книжку старую, и искать контакты бывших однокашников и прочих, кто мне мог помочь. После чего, вышел на очень профессиональных людей, один из которых за два дня привел все в порядок. Сервер стал работать стабильно.

На момент проблем нагрузка была около 7000. Сейчас бывает и по 20000. И сервер справляется без проблем. Но мы уже глядя в будущее собрали свой сервер более мощный. За весь период общения с профессионалами, я многое узнал. С теми с кем я общаюсь, работают в серьезных организациях, например в РЖД, где обеспечивают работу систем безопасности — серьезные ребята вообщем (многие бородатые ).

Так вот они поведали, что режим mod_php при грамотной сборке должен быть производительней в среднем на 20% чем FastCGI. Причем если нужно отделить пользователей, то даже использование виртуальных ОС, на каждую из которых естественно тратятся ресурсы, дает фору режиму FastCGI. Но использование виртулов требует больше памяти.

Надо отметить у Вас даже получились неплохие результаты в пользу FastCGI.

Та не, не сломаешь, в принципе. Но и DLE не будет работать нормально.

На всякий случай просто сохрани текущий конфиг, до переключения.

Просто ISP бывает глючит, когда слишком сильно модифицируешь дефолтный конфиг. А в случае с DLE его нужно модифицировать очень сильно, либо подключать инклюдом (самый верный вариант).

Читайте также:  Network genie что это за программа

А если не будешь руками лазить в конфиг, и уверен, что DLE работает с дефолтным конфигом Apache — то можно и туда-обратно тыкать, ничего не сломаешь.

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

Что касается CGI — не совсем так, CGI точно так же через апач работает.

Годный пост. На сервере держу пока старую сборку с апачем, а вот на локалке поставил без него. Пока еще не юзал толком. Как я понял .htaceess в этой связке не работает? ЧПУ как здесь делать или все там так же работает?

Точно, .htaccess не пашет, ибо этот костыль умеет только апач. ЧПУ, соответственно, тоже не пашет. В этом обычно и заключается загвоздка при переключении на эту связку.
Если какая-то сложная CMS, то нужно рисовать и отлаживать конфиг под неё в Nginx.
Если обычный wordpress, то там решается довольно просто. Добавляется в конфиг такая строчка:
try_files $uri $uri/ /index.php?$args;
В блок location / <. Вот так:

Для некоторых других CMS тоже подходит этот вариант. А для того же DLE, например, надо рисовать большую портянку правил.

«Чтобы иметь преимущества php 7 его нужно обновить общесистемный. Тогда и высокопроизводительный сервис PHP-fpm станет работать на этой же версии. Но чего делать пока не рекомендуется, да и нету его еще в стабильных репозиториях большинства OS.»

Спасибо за эту статью и видео! Видео кстати также будет полезно тем, кто интересуется темой «как надо работать в терминале» )

Вопросики:
1. Если хочется php7, то на чистую ОС (как я понял сейчас мейнстрим CentOS для обычных сайтиков) сначала ставим из репозитариев php 5.5 (актуально на 06.2017) и потом еще ставим из не официальных репозитариев php7 ?
2. Или все-же на продакшн 5-ый ставят? )
3. Если Ставим Nginx то получается что apache можно вовсе не ставить…

P.S. Php7 сам по себе должен быть быстрее 5-го, т.к. в нем обновлен движок Zend и выброшено много устаревшего

Ну на самом деле тут в этой статье инфа немного уже устарела, ибо писалась на форуме более чем полгода назад. По крайней мере применительно к использованию php 7 в режиме php-fpm, особенно на сервере под управлением панельки ISPmanager 5. В нем можно в любом режиме удобно юзать любую версию PHP. И 7, и даже 7.1. Это я как раз и показывал на видео. И в другой статье http://vpsadm.ru/php-7-ispmanager-5-kak-ustanovit/

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

В том же centos такую возможность не знаю как вкорячить. Технически это разумеется возможно, просто я пока не знаю как)

Далее по версиям OS. Это зависит исключительно от удобства администрирования, от привычки работы с ними. Для большинства задач и сайтов мне видится Centos удобней. В Debian 8 легко можно поставить обе версии параллельно. По-умолчанию там ставится из стабильных официальных репов 5.6 версия. Но можно установить дополнительно 7ю версию и переключаться между ними. В режиме php-fpm можно запускать сайты параллельно на разных версиях, в режиме модуля апача можно юзать либо ту либо другую, легко между ними переключаться. В режиме CGI тоже можно, но его вообще не стоит юзать. Если только для отладки.

На продакшн ставят то, что нормально работает) Поэтому перед продакшном надо погонять в тестах &#128578; Буквально на прошлой неделе переводил на php 7 как раз самый что ни на есть продакшн — огромную онлайн-библиотеку с трафом 200к в сутки, работающую на кластере из трёх серваков. В паре с разрабом, так задолбались, несколько дней по ночам. Оно работало на debian 7, в который вообще нет технической возможности поставить толком php 7 в режиме апача. Пришлось апгрейдить OS до debian 8, и потом только ставить php 7. Переключить у нас получилось только с третьей попытки, первые две была нестабильность, тормоза, глюки и отвалившийся функционал. Причем, это с учетом того, что до этого было протестировано на PHP 7.

По поводу Nginx — да, верно. Можно его использовать без апача в связке с php-fpm. Но обычно под него надо пилить и отлаживать конфиг, редко так сразу заработает. Особенно если какая-то неизвестная CMS или самопис. На основе htaccess пишется такой конфиг. Есть онлайн-конвертеры с .htaccess в правила nginx, но они в чистом редко выдают то что надо. Обычно их просто как подсобный инструмент можно использовать, брать какие-то куски, из них уже лепить и отлаживать свой конфиг.

Интерпретатор PHP может работать в нескольких режимах. В этой статье рассматриваются следующие режимы работы:

Каждый из указанных режимов имеет как преимущества, так и недостатки. Те и другие качества в представляем ниже.

Содержание

PHP как модуль Apache (mod_php)

Этот режим предполагает подключение модуля mod_php в настройках веб-сервера Apache. В этом случае каждый процесс веб-сервера будет включать в себя этот модуль. Выбор этого режима особенно подходит для небольших сайтов с малой посещаемостью.

Преимущества:

  • Доступны настройки кэширования, за счет чего можно увеличить производительность.
  • Быстрое исполнение скриптов.
Читайте также:  Dell xps 15z l511z

Недостатки:

  • Конфигурирование можно выполнять только через основной файл php.ini и некоторые параметры можно объявить через файл htaccess.
  • По умолчанию скрипты запускаются с правами пользователя apache. Однако это можно изменить путем использования mod_ruid, который позволяет запускать скрипты от разных пользователей.
  • Подгрузка модуля происходит во все процессы apache даже при отсутствии запросов на тип скрипта, обрабатываемый этим модулем. За счет этого создается бесполезная нагрузка на сервер.
  • Скрипт, имеющий ошибки, может привести к сбою работы веб-сервера.
  • Нет простого способа узнать, каким пользователем было запущено стороннее приложение.
  • Некоторые модули имеют проблемы в совместимости с многопоточным запуском веб-сервера (MPM Worker).

PHP в режиме CGI

В этом режиме запускается интерпретатор php-cgi для всех скриптов, для которых установлен CGI в качестве обработчика. Если большая часть сайта состоит из статического содержимого, то CGI будет хорошим выбором, т.к. будет обеспечено экономичное использование оперативной памяти за счет того, что интерпретатор будет вызываться в случае необходимости. Но и в то же время такой метод замедляет исполнение, т.к. при каждом запросе понадобится загрузка интерпретатора в память.

Преимущества:

  • Обработчик CGI может быть запущен с правами любого пользователя системы (с помощью suexec).
  • Конфигурацию PHP можно сделать индивидуальной для каждого пользователя.
  • CGI использует оперативную память только если это действительно необходимо.
  • Благодаря тому, что PHP интерпретатор работает как независимый процесс, вероятность сбоя работы Apache из-за ошибок в скриптах практически нулевая.
  • Каждый клиент может выбрать индивидуальную версию PHP.

Недостатки:

  • Не высокая производительность.
  • Разработка PHP-авторизации с командой Header имеет ограничения по причине того, что скрипт будет получать не все необходимые серверные переменные.

SuPHP

SuPHP является частным случаем CGI, в котором каждый php скрипт может выполняться с привилегиями разных пользователей.

Преимущества:

  • Можно отследить, от имени какого пользователя запускался скрипт.
  • Пользователь не сможет запустить скрипты, если он не является их владельцем.
  • Для всех файлов, которые будут загружены на сервер через сайт, будет установлен владельцем тот пользователь, от имени которого эти файлы загружались.

Недостатки:

  • Сравнительно с CGI более высокая нагрузка на CPU.
  • Недоступны функции кэширования, например, XCache, APC и др.

PHP в режиме FastCGI (mod_fastcgi)

По своим свойствам FastCGI является золотой серединой между mod_php и CGI режимами. В нём исключены недостатки CGI и присутствуют его достоинства. При включенном FastCGI, в ОЗУ сервера располагается постоянно запущенный процесс-обработчик. Это избавляет от необходимости при каждом запросе запускать новый процесс, как в случае использования CGI. По быстродействию FastCGI аналогичен mod_php.

FastCGI сочитает в себе преимущества всех приведенных выше режимов. В этом случае php-обработчик запускается на постоянной основе, и теперь на каждый запрос не нужно создавать новый процесс, что было свойственно режиму CGI. FastCGI особенно подходит для высоконагруженных сайтов, нагрузка на которые постоянна.

Преимущества:

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

Недостатки:

  • Постоянно запущенный процесс интерпретатора создает нагрузку на оперативную память, хотя её объем меньше, чем при использовании PHP как модуля Apache. Это достигается за счет отсутствия необходимости обращения к интерпретатору PHP при выдаче статического содержимого.

LSPHP

LiteSpeed PHP (LSPHP) — реализован в виде модуля mod_lsapi на веб-сервере Apache и является наиболее производительным вариантом запуска PHP на серверах под управлением сPanel.

  • Увеличение скорости обработки PHP-скриптов, что ускоряет работу всего сайта.
  • Отсутствие 500-ой ошибки при наличии php_flag и подобных директив в .htaccess. Актуально при переезде с хостинга, который по умолчанию работал с mod_php.
  • Уменьшится потребление ресурсов в вашем виртуальном контейнере.
  • Улучшится эффективность работы Opcode Cache

На данный момент недостатков не было обнаружено.

Более подробно о работе LSPHP можно прочитать в нашем блоге в статье «Ускорьте работу своего сайта, перейдя на LSPHP».

Для того чтобы перейти на LSPHP, можно воспользоваться инструкцией из нашей вики.

Каким образом узнать текущий режим PHP?

Способ 1. С помощью функции phpinfo()

  • Создаем на хостинге php-файл c произвольным именем (например, info.php), после чего открываем его для редактирования и копируем в него следующие строки:
  • Сохраняем внесенные изменения, после чего открываем файл в браузере.
  • Если все данные были указаны верно, то в браузере будет выведена страница с развернутой информацией об установленном PHP. В перечне выведенных параметров будет присутствовать параметр Server API, в значении которого и отображается текущий режим PHP.
  • На изображении ниже показано значение параметра Server API в случае использования режима FastCGI.

Способ 2. С помощью функции функции php_sapi_name()

  • По аналогии первого способа, создаем на хостинге файл, например, info.php, затем открываем для редактирования и затем копируем следующий код:
  • После сохранения изменений открываем этот файл в браузере. В итоге должна быть отображена страница в теле которой будет выведено название используемого режима PHP. На изображении ниже представлен пример вывода при использовании режима FastCGI.

Уже знаете, какое доменное имя хотите получить для вашего веб-сайта? У нас вы можете купить домен дешево. Нужен хостинг? HOSTiQ предлагает интересные планы виртуального хостинга, а также вы сможете заказать VPS-сервер или арендовать сервер в Европе или США.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *