Mod php: PHP: Арифметические операторы — Manual

По вопросам работы Портала обращайтесь:

cimo2009@mail. ru 

(по вопросам доступа к СДО)

и

По вопросам доступа к материалам кафедр обращаться на кафедры!

You are not logged in. (Log in)

Get the mobile app

This page is: General type: frontpage. Context Site home (context id 2). Page type site-index.

php — Что такое mod_php?

Просматривая учебник по Zend, я наткнулся на следующее утверждение:

Обратите внимание, что настройки php_flag в .htaccess работают, только если вы используете mod_php.

Кто-нибудь может объяснить, что это значит?

• php
• apache

mod_php означает PHP, как модуль Apache .

По сути, при загрузке mod_php в качестве модуля Apache он позволяет Apache интерпретировать файлы PHP (они интерпретируются mod_php ) .

РЕДАКТИРОВАТЬ: Существует (как минимум) два способа запуска PHP при работе с Apache:

• Использование CGI : процесс PHP запускается Apache, и именно этот процесс PHP интерпретирует Код PHP — не сам Apache
• Использование PHP в качестве модуля Apache (называемого mod_php ) : тогда интерпретатор PHP как бы «встраивается» внутрь процесса Apache: внешнего процесса PHP нет — это означает, что Apache и PHP могут общаться лучше.

И повторное редактирование, после комментария : использование CGI или mod_php на ваше усмотрение : это только вопрос конфигурации вашего веб-сервера.

Чтобы узнать, какой способ в настоящее время используется на вашем сервере, вы можете проверить вывод phpinfo() : должно быть что-то, указывающее, работает ли PHP через mod_php (или mod_php5 ) или через CGI .

Вы также можете взглянуть на Функция php_sapi_name() : она возвращает тип интерфейса между веб-сервером и PHP .

Если вы проверяете файлы конфигурации вашего Apache, при использовании mod_php должна быть строка LoadModule , выглядящая следующим образом:

 LoadModule php5_module modules/libphp5.so
 

(Имя файла справа может быть другим — например, в Windows это должно быть .dll )

7

Этот ответ взят с TuxRadar:

При запуске PHP через веб-сервер есть два различных варианта: запуск с использованием PHP CGI SAPI или запуск в качестве модуля для веб-сервера. У каждого есть свои преимущества, но в целом модуль предпочтительнее.

Запуск PHP как CGI означает, что вы в основном сообщаете своему веб-серверу расположение исполняемого файла PHP, и сервер запускает этот исполняемый файл, передавая ему вызванный вами сценарий каждый раз, когда вы посещаете страницу. Это означает, что каждый раз, когда вы загружаете страницу, PHP должен прочитать php.ini и установить его настройки, он должен загрузить все свои расширения, а затем он должен начать работу по разбору скрипта — много повторяющейся работы.

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

Очевидным преимуществом использования PHP в качестве модуля является скорость — вы увидите значительный прирост скорости, если перейдете от CGI к модулю. Многие люди, особенно пользователи Windows, не осознают этого и продолжают использовать php.exe CGI SAPI, что очень обидно — модуль обычно в три-пять раз быстрее.

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

1

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

Если вы используете Ubuntu, вы можете легко сделать это с помощью

 sudo apt-get install apache2
sudo apt-get установить php5
sudo apt-get установить libapache2-mod-php5
sudo /etc/init.d/apache2 перезапустить
 

В противном случае вы можете скомпилировать apache с php: http://dan. drydog.com/apache2php.html

Указание ОС вашего сервера поможет другим ответить более конкретно.

Просто добавим к этим ответам, что mod_php — это самый старый и самый медленный метод, доступный на HTTPD-сервере для использования PHP. Не рекомендуется, если вы не используете старые версии Apache HTTPD и PHP. Предпочтительными методами являются PHP-FPM и proxy_cgi.

Это означает, что PHP должен быть установлен как модуль в Apache, а не запускаться как CGI-скрипт.

mod_php — интерпретатор PHP.

Из документации следует один важный нюанс mod_php:

«mod_php не является потокобезопасным и заставляет вас придерживаться prefork mpm (многопроцессный, без потоков), что является самой медленной из возможных конфигураций»

Зарегистрируйтесь или войдите в систему

Зарегистрируйтесь с помощью Google

Зарегистрироваться через Facebook

Зарегистрируйтесь, используя электронную почту и пароль

Опубликовать как гость

Электронная почта

Обязательно, но не отображается

Опубликовать как гость

Электронная почта

Требуется, но не отображается

— Nginx + php-fpm должен быть намного быстрее, чем Apache + mod-php

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

Что именно быстрее, mod_php или ext-fpm, еще не доказано и, вероятно, будет варьироваться. Что касается производительности, у вас есть три соображения: теория, реализация, вариант использования, ресурсы и нагрузка.

Теоретически mod_php является самым быстрым из достижимых. С mod_php веб-сервер и интерпретатор взаимодействуют напрямую, они используют одни и те же ресурсы и пространство памяти. С ext-fpm у вас есть отдельные процессы, которые взаимодействуют не так напрямую и должны дублировать ресурсы.

Традиционно популярны отдельные процессы, потому что они, как правило, обладают большей гибкостью в отношении таких вещей, как одновременная работа множества разных пользователей, разных версий и т. д. Многие люди также используют системы с несколькими процессами, поскольку их не беспокоит free() , fclose() и т. д.

В то время как ext-fpm с использованием FastCGI является попыткой заставить отдельную модель процесса соответствовать ее максимальной теоретической скорости, максимальная теоретическая скорость все еще медленнее, чем максимальная теоретическая скорость унифицированных процессов.

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

Реализация mod_php не обязательно обеспечивает максимальную теоретическую скорость. Они могут быть не так далеки друг от друга, как можно было бы ожидать, тем более что довольно часто накладные расходы SAPI могут оказаться тривиальными по сравнению со всем остальным, что происходит при обслуживании статического запроса. Многие бенчмарки должны тестироваться с практически нулевыми скриптами, так что разница кажется значительной.

Широко распространено мнение, что ext-fpm «быстрый». Есть много сил, которые упорствуют в этом, некоторые из которых невинны, другие проистекают из некомпетентности, а некоторые прямо манипулируют.

1. Apache httpd не рекомендует использовать mod_php, не работает с многопоточными MPM по разным причинам. Apache httpd с многопоточными моделями или моделями, управляемыми событиями, которые могут оказывать некоторое влияние на производительность запросов, которые не обслуживают PHP. Несмотря на то, что PHP добился значительного прогресса в поддержке моделей, управляемых потоками и событиями, до событийно-ориентированных моделей еще далеко, и его поддержка потоков не была так протестирована в бою, как традиционная поддержка процессов. Многих это смущает. Это не то, что делает PHP быстрее. Это компромисс. Потенциально замедляет PHP, ускоряет статический контент. Apache начал рекомендовать полностью отказаться от mod_php, что может сбить с толку многих людей, а также вероятное происхождение ошибочного мнения о том, что ext-fpm «быстрее».
2. Отвергнутые такими вещами, как рекомендация Apache, многие люди попробовали ext-fpm, а затем использовали свои платформы, такие как выступления на конференциях или блоги, чтобы сообщить о своих анекдотических «успехах», которые затем распространяли феномен среди более широкой впечатлительной аудитории.
3. Иногда, когда результаты лучше при переходе на ext-fpm, причины часто не такие, как ожидают люди. Многие люди при переходе с mod_php на ext-fpm делают больше, чем это, или действуют другие факторы.
4. В технологии слово «быстрый» особенно проблематично. Часто это ничего не значит. Последние несколько систем, которые я использовал и которые были названы быстрыми (очень популярные технологии), оказались противоположными. Многие люди ошибочно принимают быстро за значение самого быстрого. На самом деле это, как правило, не имеет большого значения. Быстрый в плане восприятия? Жесткий диск, вращающийся со скоростью 100 об/мин, покажется большинству людей «быстрым». Жесткий диск, вращающийся со скоростью 1000 об/мин, покажется большинству людей «быстрым». Самый быстрый, как правило, не имеет большого значения.
5. Конфликт интересов. У nginx есть коммерческое предприятие, и еще неизвестно, может ли оно быть источником некоторого маркетинга для ext-fpm. Он служит nginx, чтобы люди поверили, что он быстрее, чем mod_php, который доступен только для конкурирующего веб-сервера. Тем не менее, для nginx и PHP доступен модуль thread party, поэтому не похоже, что он будет вероятным источником, лоббирующим ext-fpm. Однако лучший результат в Google — это маркетинговый блог, пытающийся привлечь трафик к коммерческим хостинговым службам, который пропускает большую часть соответствующих деталей, поэтому есть стороны, которые явно его доят.

Часто, когда люди видят другой результат, они не понимают, почему. Интимные подробности их процесса, измерений и трафика не учитываются. Затем люди часто пытаются повторить эти успехи и терпят неудачу, оставляя бесконечные результаты поиска людей, спрашивающих, почему это не быстрее. Большой из них заключается в том, что люди добиваются успеха при использовании MPM на основе нескольких процессов с mod_php при большой загрузке статического контента. Эти случаи могут быть особенно обманчивы, поскольку нагрузка от статических запросов может вернуться обратно на PHP.

Еще одна распространенная ошибка заключается в том, что люди тестируют две разные конфигурации. Конфигурация для php-fpm может быть более оптимизированной, чем для mod_php. Иногда это может быть так же просто, как люди оптимизируют все в том, что, как они ожидают, будет быстрее, пренебрегая оригиналом. Это особенно актуально, когда люди могут делать такие вещи, как не проверять, были ли запросы успешными, а также изменять такие вещи, как ограничение памяти или максимальное время выполнения. Многое может измениться в конфигурации, когда люди предназначены только для изменения SAPI, иногда даже неизбежно, иногда даже прозрачно. Типичным примером может быть то, что ограничения на веб-сервере могут быть недостаточными для максимального использования ресурсов сервера, когда ext-fpm сможет порождать дополнительные процессы для использования дополнительных ядер. Часто можно увидеть, как люди перемещают такие вещи, как маршрутизация с PHP на веб-сервер для FPM.

По сравнению с mod_php с MPM с несколькими процессами и одним потоком, ext-fpm является хорошим соперником с множеством всесторонних преимуществ, хотя более высокая производительность строго не гарантируется. Хотя, если ваша нагрузка полностью обслуживает PHP-запросы, то Apache уже более или менее делает то, что в противном случае делал бы ext-fpm.

Также существует несоответствие между такими вещами, как задержка и пропускная способность, циклы, байты и ожидания.

Теоретически путь вперед — это php-zts либо с ngx_php, либо с mod_php. Большое предостережение заключается в том, что php-zts не получил почти ни внимания, ни заботы и внимания, как php-nts, так что он вводит накладные расходы на само выполнение PHP, что делает его очень трудным конкурировать с php-fpm в настоящее время. Реализация не приводит его к достижению оптимума. В некоторых случаях субоптимальность может быть преуменьшением. Многие люди обеспокоены надежностью многопоточного PHP, который может повлиять на вас, а может и не повлиять. Это, безусловно, не будет такой большой проблемой, если вы обслуживаете только динамический контент и не используете услугу общего хостинга. Похоже, что потенциально это кампания страха, организованная Apache.