Прошло некоторое время с тех пор, как я использовал объекты FastCGI в Rebol, поэтому я не могу ответить на первый вопрос очень хорошо, но я могу помочь по второму вопросу, хотя вам может и не понравится.
Noone воссоздал схему fastcgi:// для R3. Я говорю «воссоздан», потому что R3 имеет совершенно другую модель порта, чем R2, поэтому схемы портов вовсе не переносимы между двумя платформами. И это в дополнение к схеме портов R2/Command, которая является встроенным встроенным кодом, который также не был бы переносимым для R3, даже если бы он был открытым, потому что модель системы R3 тоже отличается. И независимо от его переносимости, R2 содержит много коммерчески лицензионного кода, который Rebol Technologies не имеет права открывать исходный код - почти все, что он мог открыть, превратил его в R3 уже. Поэтому, если его уже нет, можно с уверенностью предположить, что он совсем не совместим или не открыт.
Было бы быстрее и проще начать с нуля в R3 с новой схемой fastcgi://, которая следует за моделью R3. Самое большее, с чем мог бы помочь источник R2, даже если бы он был, заключался бы в документировании протокола FastCGI, и AFAIK протокол лучше документирован в другом месте. В этом случае было бы хорошей идеей сделать порт хоста, оптимизированный для такого рода вещей, что немного легче сделать в R3.
С другой стороны, из того, что я помню, протокол FastCGI не так уж и трудный, и новая модель порта R3 намного лучше подходит для такого рода вещей, поэтому начать с нуля, возможно, не слишком сложно. И если нам повезет, все это можно сделать в пользовательском коде, который просто запускается на обычном интерпретаторе R3, без необходимости адаптации хост-кода. Поэтому новость не должна быть такой плохой.
Теперь попытка ответить на ваш первый вопрос: от этого зависит.
Это действительно зависит от того, что вы пытаетесь сделать, и как у вас есть что-то настроенное. CGI имеет накладные расходы на запуск процесса каждый раз, поэтому он работает только быстро, если издержки на запуск процесса значительно меньше, чем остальная часть служебных данных запроса (например, файловая система или доступ к базе данных). Rebol, особенно R2, имеет значительную часть служебных затрат на запуск процесса, потому что это интерпретатор, который имеет встроенный интерпретируемый код для загрузки при его запуске. Вы можете свести к минимуму затраты на запуск, используя SDK для создания своего приложения только с нужным кодом, но это все равно может не помочь в вашем конкретном случае (не зная, что вы пытаетесь сделать).
FastCGI - это способ избавиться от этого процесса, запускающего служебные данные, запустив сервер приложений вне процесса, вместо того чтобы запускать новый процесс за запрос. Для чего-то вроде Rebol, который имеет значительные накладные расходы на запуск процесса, экономия может быть столь же значительной.
Одна вещь, которую вам нужно учитывать, состоит в том, что R2 имеет модель с одним потоком для процесса, по большей части, поэтому, если вы хотите обрабатывать несколько параллельных запросов, вам либо приходится делать их по частям в одном и том же процессе (например, Node.js) или FastCGI выделяет несколько серверных процессов для обработки нескольких запросов независимо или, возможно, и того, и другого. Обязательно попросите экспертов Rebol дать совет, если перспектива этого пугает, или просто настройте FastCGI, чтобы запустить больше серверов приложений для запуска одновременно.
Итак, сколько запросов, которые вы можете выполнять в секунду с настройкой FastCGI, зависит от того, как вы настраиваете FastCGI, как вы пишете код обработчика FastCGI и сколько и какую работу выполняют ваши запросы.
Это говорит о том, что вы получаете 4-5 запросов в секунду в режиме CGI. Это необычно медленно. Накладные расходы Ребола не так уж и близки к медленному в худшем случае. Это означает, что либо ваши запросы делают много, либо у вас недостаточно ОЗУ, чтобы работать больше, чем несколько процессов CGI за раз, или что у вас CGI настроен плохо. Я не уверен, что FastCGI может помочь в этом случае, просто используя лучшее оборудование или улучшая работу по настройке Apache. Тем не менее, убедитесь, что у вас достаточно рабочих процессов FastCGI и вы можете написать обработчик для обработки нескольких запросов одновременно, и вы сэкономите столько, сколько сможете.
Удачи вам!
Он появился в [чат-комнате для Rebol и Red] (http://chat.stackoverflow.com/rooms/291/rebol-and-red) (пожалуйста, присоединяйтесь, если сможешь), что нам нужен mod_rebol , но и ваш сценарий звучит подозрительно странно с точки зрения производительности, давайте отлаживаем его в чате. – HostileFork