Russian Apache Switch to English
Switch to Russian koi8-r
windows=1251
cp-866
iso8859-5
Russian Apache Как это работает Рекоммендации Где взять Как установить Как настроить Статус и поддержка
Краткий обзор FAQ Список рассылки Благодарности Поиск по серверу Powered by Russian Apache
Russian Apache mailing list archive (apache-rus@lists.lexa.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [apache-talk] mod_perl, embed perl, etc...



On Tue, 11 May 1999, Андрей Новиков wrote:

> From: Андрей Новиков <novikov@xxxxxxxxxx>
> Subject: [apache-talk] mod_perl, embed perl, etc...
> X-Mailer: The Bat! (v1.15) S/N ECB2EB0F
> 
> Здравствуйте.
> 
> Еще  один интересный вопрос в догонку. Так уж сложилось, что
> до  сих  пор руки мои не дошли до описаных в сабже крутостей
> (очень  стыдно,  очень). Но вот момент настал, любопытство и
> желание  уменьшить нагрузку на сервер превысило лень, посему
> хочу  спросить  одно это и то же или разные вещи, чем лучше,

Это разные вещи, работающие совместно.

mod_perl это способ встроить интерпретатор perl внутрь Apache.
Используя просто mod_perl можно
1. Выполнять CGI-скрипты внутри процесса HTTPD а не отдельным процессом.
  Перл, как известно язык компилируемый. Поэтому каждый скрипт имеет
  overhead на компиляцию. В случае CGI он компилируется при каждом
  запуске. При использовании Registry (это такая фича в mod_perl,
  эмулирующая CGI) скрипт компилируется при первом запуске после
  изменения, после чего байт-код живет внутри той копии HTTPD, которая его
  выполнила, и
  при следующем запуске overhead отсутствует. Зато растет расход памяти.

  Кроме того, если скрипт работает с базой данных, коннект к БД кешируется
  и экономится время на соединение при следующем запуске. Правда
  соединений к БД будет m*n где m число копий httpd а n - число разных
  коннектов к БД которые бывают

2. Вызывать из Server Side Include перловые процедуры вместо CGI-скриптов
   Здесь экономия намного больше, поскольку процедуры эти обычно живут
   в модулях, которые компилируются при старте httpd а потом байт-код 
   наследуется всеми детишками, и, соответственно, живет в памяти в одном
   экземпляре. Зато при изменении модуля придется httpd передергивать.

3. Писать на перле обработчики различных стадий http-запроса - трансляции 
   URL, разбора параметров, генерации контента, логгинга и т.д.
   Занятие это не слишком простое, но сильно проще чем писание апачевских
   модулей на C. 

4. Использовать скрипты на perl вместо/вместе с апачевсиким конфигом.
   Возможность написать в конфиге
   foreach $host (@virtualhosts) {
   при 30 виртуальных серверах очень заманчива.

5. Воспользоваться немерянным количеством готовых модулей, которые уже
   написаны, например AuthenDBI, который проверяет пароли доступа по базе
   данных, или LogDBI, который логи сразу в SQL-сервер пихает,
  Apache::Include,  который позволяет включать SSI-инклюды в выдачу CGI,
   точнее Registry скриптов.


EMBPerl, eperl и Apache::ASP это все различние способы встраивать перловый
код прямо в web-страницы. Грубо говоря, заменитель php. Каждый из них 
имеет свои преимущества и недостатки. Но, как всегда, встает проблема
кэширования байт-кода. Ограничение на синтаксис они, конечно накладывают - 
весь встроенный в страницы код должен быть написан на perl.
 

Короче говоря, использование mod_perl как правило повышает
производительность ценой роста требований к памяти.
Именно поэтому совместное использование mod_perl и php мне кажется
неразумным. Если мы уж таскаем с собой достаточно толстый интерпретатор
perl, да еще и перловый интерфейс к базе данных (для аутентификации,
логгинга и трансляции URL) то зачем нам еще один интерпретатор скриптового
языка (php) со своими интерфейсами к БД.


> чем   хуже?   Конкретные примеры крутости (success stories)?
> Накладывает  ли  это  какие-нибудь ограничения на синтаксис,
> возможности, к которым я привык? В общем  советуйте. (Только
> очень прошу - не начинайте войн, а то Алекс меня выгонит).
> 
> О  себе  -  сейчас около 30 хостов, есть сильно загруженные,
> есть  не  очень,  куча  всего  на  обычном Перле, начиная от
> простых  редиректоров  и  кончая сложными комплексами, часто
> используются всякие сторонние модули, БД. А еще используется
> PHP :)))
> 
> С уважением, Андрей Новиков
> 
> ------------------------------------------------------------
> Всероссийский Клуб Вебмастеров        http://www.webclub.ru/
> По официальным вопросам пишите     mailto:webclub@xxxxxxxxxx
> 
> 
> =============================================================================
> =               Apache-Talk@xxxxxxxxxxxxx mailing list                      =
> Mail "unsubscribe apache-talk" to majordomo@xxxxxxxxxxxxx if you want to quit.
> =       Archive avaliable at http://www.lexa.ru/apache-talk                 =
> 

--------------------------------------------------
Victor Wagner			vitus@xxxxxx
Programmer			Office:7-(095)-964-0380
Institute for Commerce 		Home: 7-(095)-135-46-61
Engineering                     http://www.ice.ru/~vitus

=============================================================================
=               Apache-Talk@xxxxxxxxxxxxx mailing list                      =
Mail "unsubscribe apache-talk" to majordomo@xxxxxxxxxxxxx if you want to quit.
=       Archive avaliable at http://www.lexa.ru/apache-talk                 =






Спонсоры сайта:

[ Russian Apache ] [ Как это работает ] [ Рекомендации ] [ Где взять ] [ Как установить ] [ Как настроить ] [ Статус и поддержка ] [ Краткий обзор ] [ FAQ ] [ Список рассылки ] [ Благодарности ] [ Поиск по серверу ] [ Powered by Russian Apache ] [ Apache-talk archive ]

"Russian Apache" includes software developed by the Apache Group for use in the Apache HTTP server project (http://www.apache.org/) See Apache LICENSE.
Copyright (C) 1995-2001 The Apache Group. All rights reserved.
Copyright (C) 1996 Dm. Kryukov; Copyright (C) 1997-2009 Alex Tutubalin. Design (C) 1998 Max Smolev.