JustUserR, спасибо большое! А Вы не знаете, есть ли какие-то готовые решения того, что Вы предложили?

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

Так разница только в том что сам интерпретатор всегда висит наготове в памяти. А скрипты то он всеравно обрабатывает ПОСЛЕДОВАТЕЛЬНО. Просто его "поднимать" как процесс (в контексте самой ОС) не нужно каждый раз. Единственный плюс режима Fast-CGI - система не тратит свои ресурсы на инициализацию, отсюда и название. А код исполняемого скрипта НИЧЕМ ОТЛИЧАТЬСЯ НЕ БУДЕТ.

DeepVarvar,

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

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

Если точнее - в какие-то часы каждую минуту, а в какие-то вообще не будет запускаться (например, ночью), а в какие-то часы будет запускаться раз, может быть, в 10 минут. В какие-то дни вообще не будет запускаться. Тут дело не во времени. Оно может быть произвольным. Нет каких-то заранее заданных интервалов, через которые будет запускаться тот или иной скрипт. Все зависит от пользователей, которые пользуются той программой, которая вызывает мои скрипты.

----------

Уважаемые товарищи, вы тут ведете какие-то свои разговоры... Не мог бы мне кто-нибудь сказать конкретно, что я могу сделать? Я понимаю, что это не очень вежливо с моей стороны, но мне правда требуется решение этой проблемы. Спасибо большое.

Вам по сути сказали что сделать надо. Пишете демона который будет работать в CLI-режиме и ждать команды через STDIN или другое (в зависимости от окружения в котором это должно работать).

Спасибо. А на каком языке нужно писать "демона который будет работать в CLI-режиме"? И где можно почитать об этом поподробнее?

Использование FastCGI-интерфейса позволяет осуществить существленное упрощение решения предполагаемой задачи следующим образом - в случае обеспечения запуска серверных приложений на основании классического CGI-интерфейса web-сервер осуществляет предварительную инициализацию отдельного процесса ответственного за формирования верифицируемого или неверифицируемого пользовательского HTTP-документа - таким образом даже в случае сохранения исполнения процесса после завершения формирования HTTP-документа осуществление обработки им дальнейших запросов является невозможным
В то же время использование FastCGI-интерфейса позволяет обеспечить выполнение единого процесса серверного приложения реализующего взаиомдействие с web-сервером на основании функциональных вызовов - что позволяет ему обеспечивать сохранение предшесвующего состояния и выполнять фоновые последовательные операции с расподелением ответа на существующие клиентские соединения

Так, здесь становится всё интереснее. Схожу за пефком.

На PHP...

Вот тебе раз. А ведь FastCGI для PHP доработали. Раньше (с последнего момента как я смотрел в его сторону) он перезапускал интерпретатор каждый раз и почти ничем не отличался от mod_php.
Но если верить
http://habrahabr[dot]ru/blogs/php/64938/
то он "исправился". Это радует. Правда, как заметили выше, все равно код отличаться не будет ничем. Но прирост явно должен быть.

Специально для JustUser:
1. Пишите грамотно. Перепроверяйте сообщение перед тем, как отправить. Особенно это сказывается, так как все Ваши сообщения чрезвычайно длинны.
2. Используйте знаки препинания. Как администратор ресурса я уже требую выполнения этого пункта.
3. Пожалуйста, читайте предыдущие сообщения. в 2/3 случаях Вы дублируете своими сообщениями то, что было сказано выше (то ли от того, что не прочли эти сообщения, то ли от желания разъяснить то, что понятно и так).

В действительности, конкретное функционирование интерфейса FastCGI в существенной мере зависит от конкретной используемой реализации модуля обработки соединений в web-сервере, по этой причине для конечного исполняемого серверного приложения может быть установлен исключительно формат взаимодейтсвия, связанная с описания вызываемых функциональных элементов, для обеспечения приема и передачи информаионных соединений по данной сессии взаимодействия с пользователем
Оригинальное описание FastCGI-интерфейса предоставлено здесь http://fastcgi[dot]com/devkit/doc/fcgi-spec[dot]html

Да, разумеется. С протоколом "правильного" FastCGI я знаком - но, увы, его реализация в php (как выяснилось, до недавнего времени) оставляла желать лучшего.

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