Уважаемый Kavkaz!

Не могли бы Вы донести до меня идею о том, зачем "иметь возможность писать скрипты прям в *.htm перемешивая с кодом html" (кстати иметь ее можно уже сейчас используя http://search.cpan.org/~grichter/HTML-Embperl-1.3.6/Embperl.pod)?

Я всегда старался разделять обработку данных и отображение (хотя не всегда получается грамотно). Кажушаяся простота совмещенного варианта неминуемо обернется совершенно неподдерживаемой системой. Это из личного опыта написания "велосипедов с квадратными колесами".

Чем стандартные решения не устраивают? Другие-то проекты нормально функционируют.

Игорь Гердлер

не хочу показаться грубым, но хотелось бы услышать не "зачем?"
пусть в некоторых моментах (грубо говоря написав свой обрабтотчик GET-POST а не использовав CGI.pm) изобрету велосипед..
УДОБННО, это просто очень удобно А хочется что еще и побыстрее было.

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

Как бы правильней направить развитие темы в нужное русло:
Больше интересует не возможность и реализация встраивания кода в html а реализация самих cgi скриптов при подключенном модуле fastcgi
мне пока что мало той информации про FastCGI/Perl что я уже прочитал
буржуйские сайты - ну тут как у большинстваа, хромает язык

Уважаемый Kavkaz!

Попробую направить дискуссию в конструктивное русло. Чем не устраивает стандартный вариант повышения производительности приложения, созданного по стандартной схеме - использование кэширования?
Пример: есть скрипт, который делает 3 запроса к БД (скажем, выводит последние 20 сообщений на форуме). Пусть время выполнения скрипта 0.1 сек. Если у нас ограничение в 10 одновременно работающих процессов (что стандартно для fastcgi и нестандартно для apache+mod_perl), то за 1 секунду сервер обработает не более 100 запросов к этому скрипту.
Применяем кэширование: к стандартной связке nginx <-> apache+mod_perl добавляем apache+mod_accel (nginx <=> apache+mod_accel <=> apache+mod_perl). В каждом сообщении форума есть поле last_update, которое хранит дату последнего изменения поля. При создании страницы в ответ добавляем заголовок Last-Modified:. При этом ответ скрипта кэшируется mod_accel. При следующем обращении к скрипту mod_accel передает в запросе заголовок If-Modified-Since:. В случае наличия этого заголовка скрипт сначала делает дополнительный запрос к базе на получение даты последнего изменения сообщений форума. Если дата, полученная из базы не позже даты, указанной в заголовке If-Modified-Since:, то скрипт просто возвращает ответ с кодом 304 (Not Modified) и завершает выполнение. Предположим, что время выполнения скрипта с кешированием - 0.01 с (при включенном кэше в СУБД, оно будет гораздо меньше при последующих идентичных запросах). В результате имеем при тех-же условиях 1000 вместо 100 запросов в секунду.
Производительность можно еще повысить, сохраняя часть данных, полученных из БД (и не только) в memcached (что, вобщем-то, и делают многие разработчики высоконагруженных проектов).

сразу скажу Вам, ginnie, спасибо за внимание
но давайте расставим приоритеты,
- хотим повысить производительность - факт
- apache+mod_perl не рассматриваем, это я использовать точно не буду
- nginx так же оставим в покое
описанная вами схема безусловна достойна внимания, но это не совсем то. Это принесет прирост в производительности в больших проектах, но чёрт возьми, я за другими зайцами бегу

масштабируемость проекта? если я захочу переместить проект на другой сервер, мне там все это настраивать и поднимать? или просто установить модуль fastcgi.

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

Если я правильно понял Вашу схему, Basta.fpl будет выступать в роли "компилятора" скрипта priemnik.fpl. За счет чего в Вашей схеме будет прирост производительности? За счет fastcgi? Да, если сравнивать Вашу схему с вариантом, выполняемым как обычный cgi-скрипт под Apache. Если же сравнивать с производительностью варианта запуска в fastcgi скрипта priemnik.fpl, созданного программистом, а не другим скриптом Basta.fpl, то производительность такого варианта будет выше (точно не ниже).
Если я что-то в Вашей схеме не так понимаю... поясните схему подробнее.

В принципе вы все правильно поняли.
вместо того, чтобы руками создавать priemnik.fpl его будет формировать парсер Basta.fpl
получаю: в демонах будет теперь висеть priemnik.fpl , значит время на запуск интерпретатора тратиться не будет, тот момент, ради которого я и решил заняться данным вопросом. Если мне обоснуете, что "стОящего" прироста производительности не будет, я успокоюсь. Вы вроде как тоже согласны с тем что прирост будет.
Дальше вопрос, создавать скрипты руками или парсером: ну я бы не создаал эту тему, если бы в этом моменте не определился... Парсер будет однозначно.

дальше еще момент, прежде чем скажу, оговорка:
сейчас парсер (обычный cgi скрипт) при обработке файла работает по схеме: увидил кусок perl кода, выполнил его в eval, результат пишет в конечный htm файл, который впоследствии и отдается пользователю.. не будем обсуждать этот принцип работы. Просто отталкиваясь от плюсов и минусов данной схемы хочется сделать более менее правильные выводы, которые использую для создания Basta.fpl
Итак:
мне придержаться подобной техники и просто сканировать поступившие на вход Basta.fpl файлы, попутно выполняя найденный перл код в eval и в дальнейшем вставляя результат в конечную html страницу или как изначально описал, "собирать" fastcgi скрипт priemnik.fpl , запускать его... ?

Basta.fpl {
  1. анализ запрошенной страницы
  2. если запрошена bumbaracha.htm проверяем, есть ли демон priemnik.fpl
  3. если демон не запущен, герерируем код скрипта priemnik.fpl и запускаем процесс priemnik.fpl
  4. запускаем генерацию этим демоном html-кода страницы
  5. выдаем страницу пользователю
}

Если честно, первый раз вижу подобный подход. Уже один этот факт заставляет задуматься. Постараюсь описать, что мне не нравится в этой схеме:
1. Web-разработка обычно подразумевает, что одновременно будет выполняться несколько экземпляров скрипта, обрабатывая запросы разных (в общем случае) пользователей. Если Вы планируете иметь один экземпляр priemnik.fpl для всех экземпляров Basta.fpl, то он будет обрабатывать один запрос в единицу времени. Если каждый экземляр Basta.fpl будет иметь собственный демон priemnik.fpl, очевиден необоснованный расход памяти на дополнительный скрипт с интерпретатором. Производительность упадет из-за памяти и необходимости осуществлять межпроцессное взаимодействие и использование дополнительного кода в priemnik.fpl для его "демонизации".
2. Парсер тоже отрицательно влияет на производительность под fastcgi:
код eval{$parsed_part}; не может быть скомпилировано в байт-код для неизвестного во время компиляции значения $parsed_part. Следовательно для обработчика кода html-perl можно ожидать только компиляции кода самого обработчика, но не кода, который он обрабатывает.

Как обычно делаю я: использую стандартную схему. Пишу код, генерирующий динамическое содержимое страницы (этот код нормально компилируется), вывожу сгенерированные данные с использованием html-шаблона (HTML::Template, тоже компилируется при первом использовании).
Я не говорил, что нестандартно использование fastcgi - нестандартна предложенная Вами схема. Стандартная схема используемая в варианте fastcgi дает большую производительность при меньших (гораздо меньших) затратах (как на разработку, так и на поддержку).

Что то я немного запутался, итак:
-перезагрузили сервер, запустился апач, никакие демоны не загружены
-пошел первый запрос на bumbaracha.htm, апач перенпрвялете его на Basta.fpl
-Basta.fpl срабатывает по описаному вами выше алгоритму, запускает priemnik.fpl
--имеем 1демон Basta.fpl и 1 демон priemnik.fpl
-пошел второй запрос на bumbaracha.htm, апач перенпрвялете его на запущенный демон Basta.fpl
-Basta.fpl перенаправляет на запущенный демон priemnik.fpl
-и тд.

и вот пошли интересные мне тонкости:
1. что происходить будет когда priemnik.fpl не будет справляться с кол-вом запросов в единицу времени (кстати где стоит это ограничение на число возможных обработаных запросов в единицу времнеи)?
2. что происходить будет когда Basta.fpl не будет справляться?

примечание1: насколько я знаю если один демон(экземпляр) начинает несправляться, происходит запуск еще одного демона(экземпляра) - копии, и нагрузка распределяется между ними.
и я подразумеваю ответы на два своих вопроса дает "примечание1"

т.е. если допустим
Basta.fpl может обработать 10 запросов в секунду, а имеем 15 запросов в секунду, то в памяти будут висеть два демона(экземпляра) Basta.fpl
причем из этих 15 могут(допустим) только 7 запросов быть к bumbaracha.htm -> priemnik.fpl
соответсвенно priemnik.fpl также может обработать 10 запросов в секунду, и он обрабатывает пришедших ему 7 запросов от двух демонов Basta.fpl

пока у меня такой ход мыслей, поправьте пожалуста.
вот интересен момент из вопроса 1, где, как указано ограничение на кол-во обрабатываемых запросов, если оно вообще есть (может какая нибудь "очередь" запросов)

Еще раз хочу повторить, что весь функционал priemnik.fpl по получению, обработке запроса и выдаче ответа Вам придется реализовывать самому (готового варианта Basta.fpl->process(priemnik.fpl) никакого нет).

Вот, наверно, те (тот) момент где я не на то расчитывал...
просто вот даже завел на локальном компе apach+fastcgi
запускаю test_modul.fpl
смотрю запущенные процессы

Centurion-3:/scr root# ps -ax | grep test_modul
 6324  ??  S      0:00.04 /usr/bin/perl /opt/local/apache2/cgi-bin/test_modul.fpl
 6336  p1  S+     0:00.00 grep test_modul
Centurion-3:/scr root# ps -ax | grep test_modul
 6324  ??  S      0:00.04 /usr/bin/perl /opt/local/apache2/cgi-bin/test_modul.fpl
 6338  p1  S+     0:00.00 grep test_modul
Centurion-3:/scr root# ps -ax | grep test_modul
 6324  ??  S      0:00.06 /usr/bin/perl /opt/local/apache2/cgi-bin/test_modul.fpl
 6340  p1  R+     0:00.00 grep test_modul

не подскажете где можно "по делу" прочитать про тонкости fastcgi ?

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

кстати о вопросах на будущее: при отладке скриптов, мне каждый раз придется перезапускать веб сервер?
так как допустим загасить запущенный test_modul.fpl у меня не получилось. родился просто новый

если я внесу какие то изменения в test_modul.fpl то увижу изменения в браузере только после перезапуска апача

извиняюсь, именно так и происходит, раньше значит что то не так делал...

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