 |  | | PHP, Python как mod или как CGI на Apache |
|  |
 Posted: Sun Apr 30, 2006 3:37 pm |
 |
|
| leksey |
| Графоман |
 |
|
| Joined: 17 Dec 2004 |
| Posts: 1909 |
| Location: Москва, Тушино |
|
|
|
|
 |
|
Господа, многие из посетителей форума являются администраторами или разработчиками. Не можете ли вы подсказать, какие явные преимущества/недостатки имеет вариант, когда некий скриптовый язык (например PHP или Python) поддерживается на сервере с помощью установленного модуля к Апачу. Или лучше делать поддержку скриптов с использованием CGI. Чтобы апач вызывал обработчик сторонний, а не сам пытался что-то сделать.
Ну и перл, видимо, я забыл. Про него я не спрашиваю. Потому, что, насколько знаю, он является необходимым для установки Апача. Он без него просто не ставиться. Но по смыслу Perl тоже можно добавить к уже заданному вопросу.
Гугль я курил, но это мне мало помогло. |
|
|
|
|
| | | Re: PHP, Python как mod или как CGI на Apache |
| |
| Posted: Sun Apr 30, 2006 5:02 pm |
|
|
| j2a |
| Разработчик |
 |
|
| Joined: 25 Jul 2005 |
| Posts: 124 |
| Location: Омск |
|
|
|
|
|
|
| leksey wrote: | | Не можете ли вы подсказать, какие явные преимущества/недостатки имеет вариант, когда некий скриптовый язык (например PHP или Python) поддерживается на сервере с помощью установленного модуля к Апачу. |
+ меньше накладных расходов на запуск приложения (запуск интерпретатора, подгрузка нужных модулей)
+ доступ к "внутренностям" апача
минусы, естественно, продолжение плюсов:
- каждый процесс апача больше кушает память (загруженный интерпретатор+модули)
- программисту нужно быть более внимательным при разработке приложения -- могут появляться всякие труднодиагностируемые приколы, связанные с небрежно написанным кодом
- для того чтобы измения, внесенные в программу, вступили в силу, нужно перезапустить апач
Поэтому, делают примерно такую: статически контент отдает "легкий" сервер (или "легкий" [безо всяких доп.модулей] апач, либо какой-нибудь nginx, lighttpd и т.д.), а динамический контент -- "тяжелый" с mod_perl/mod_python/mod_php.
| leksey wrote: | | Или лучше делать поддержку скриптов с использованием CGI. Чтобы апач вызывал обработчик сторонний, а не сам пытался что-то сделать. |
По собственному опыту, в perl и python программисты всё же больше лояльны к cgi, а в php -- подавай mod_php.
Всё же я б смотрел на масштабы. При правильном проектировании и прямых руках, с cgi перетащить на mod_perl/mod_python не особо сложная задача. Поэтому, если perl/python -- то лучше начать с cgi. Если php -- imho, сразу mod_php.
| leksey wrote: | | Ну и перл, видимо, я забыл. Про него я не спрашиваю. Потому, что, насколько знаю, он является необходимым для установки Апача. Он без него просто не ставиться. |
Мне кажется, ты ошибаешься. |
|
_________________
:Wq
Not an editor command: Wq |
|
|
|
| | | Re: PHP, Python как mod или как CGI на Apache |
| |
| Posted: Mon May 01, 2006 12:15 am |
|
|
| KRom |
| Разработчик |
 |
|
| Joined: 07 Oct 2005 |
| Posts: 242 |
| Location: Tagan-York, South Russia |
|
|
|
|
|
|
| leksey wrote: | | Господа, многие из посетителей форума являются администраторами или разработчиками. Не можете ли вы подсказать, какие явные преимущества/недостатки имеет вариант, когда некий скриптовый язык (например PHP или Python) поддерживается на сервере с помощью установленного модуля к Апачу. Или лучше делать поддержку скриптов с использованием CGI. Чтобы апач вызывал обработчик сторонний, а не сам пытался что-то сделать. |
IMHO лучше при отлаженом хостинге использовать именно модули к апачу, другое дело, что perl позиционируется, как универсальный скриптовый язык и соответственно используется не только как генератор html страниц, но и для выполнения общих операций в системе (смотри пакет Denwer, где на perl построено практически все, от заглушки sendmail, до автоконфигурирования конфига апача на работу с виртуальными хостами и рестарта всех компонентов), да и в качестве модуля я его не встречал. PHP изначально позицонировался, как средство встриваемое в html код, вот и подключается он как правило в виде модулей. При нестабильной работе обработчиков, их всеж лучше перенести на CGI технологию.
| leksey wrote: | | Ну и перл, видимо, я забыл. Про него я не спрашиваю. Потому, что, насколько знаю, он является необходимым для установки Апача. Он без него просто не ставиться. |
Все прекрасно работает и без перла, вот у меня дома пока что стоит WAMP (Windows+Apache+MySQL+PHP) и все работает, хоть и собираюсь еще и perl прикрутить, другое дело, что, как уже было написано ранее, perl используется для автоматизации процесса работы и в качестве связки всего в единое целое, т.е. он помимо генерации html кода выполняет операции с файлами, процессами (запуск/остановка) и др. Вот и является в некоторых случаем необходимым движком админа. |
|
_________________
Ве?ьма веро?тно на?тупление неверо?тного. |
|
|
|
| | |
| Posted: Tue May 02, 2006 9:49 pm |
|
|
| leksey |
| Графоман |
|
|
| Joined: 17 Dec 2004 |
| Posts: 1909 |
| Location: Москва, Тушино |
|
|
|
|
|
|
| А насчет suPHP есть какие-нить мнения/опыт? ЧТобы запускать скрипты с правами владельца файла, а не правами апача. |
|
|
|
|
| Posted: Mon May 08, 2006 3:20 pm |
|
|
| point212 |
| Разработчик |
 |
|
| Joined: 13 Apr 2005 |
| Posts: 164 |
| Location: Волгодонск |
|
|
|
|
|
|
Все что я хотел сказать, уже J2A высказал.
Модуль - быстрее, и больше возможностей.
Но! Он потенциально делает сервак более уязвимым.
Имхо сейчас лучший вариант - это FastCGI |
|
_________________
Я админ, хреновый админ. Но пока этого никто не знает, можно и за умного сойти  |
|
|
|
| Posted: Mon May 22, 2006 12:18 am |
|
|
| leksey |
| Графоман |
|
|
| Joined: 17 Dec 2004 |
| Posts: 1909 |
| Location: Москва, Тушино |
|
|
|
|
|
|
| Хотели заюзать suPHP, а оказалось, что эта бяка только с PHP, который как CGI собран работает (т.е. как интерпретатор). А CLI-вариант ее никак не устраивает. |
|
|
|
|
| JRuDevels Forum Index » Разработка и проектирование [Devel] |
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
All times are GMT + 3 Hours
Page 1 of 1
|
|
|
|
|
