Прошло некоторое время с тех пор, как я использовал средства FastCGI в Rebol, поэтому я не могу очень хорошо ответить на первый вопрос, но я могу помочь со вторым вопросом, хотя он может вам не понравиться.
Никто еще не воссоздал схему fastcgi://
для R3. Я говорю «воссоздан», потому что R3 имеет совершенно другую модель порта, чем R2, поэтому схемы портов вообще не переносимы между двумя платформами. И это в дополнение к тому, что схема порта R2/Command является встроенным собственным кодом, который также нельзя было бы перенести на R3, даже если бы он был с открытым исходным кодом, поскольку модель системы R3 также отличается. И, несмотря на свою переносимость, R2 содержит много кода с коммерческой лицензией, исходный код которого Rebol Technologies не имеет права открывать — почти все, что она могла открыть, уже попало в R3. Поэтому, если его еще нет, можно с уверенностью предположить, что он вообще несовместим или не открывается.
Было бы быстрее и проще начать с нуля в R3 с совершенно новой схемой fastcgi://
, которая следует модели R3. Максимум, с чем мог бы помочь исходный код R2, даже если бы он у нас был, — это документирование протокола FastCGI, и, насколько мне известно, этот протокол лучше документирован в другом месте. Вероятно, в этом случае было бы неплохо создать хост-порт, оптимизированный для таких вещей, что немного проще сделать в R3.
С положительной стороны, насколько я помню, протокол FastCGI не так уж и сложен, а новая модель порта R3 намного лучше подходит для такого рода вещей, поэтому начать с нуля может быть не так уж сложно. И если нам повезет, все это можно будет сделать в пользовательском коде, который просто работает на обычном интерпретаторе R3, без необходимости адаптации кода хоста. Так что новости не обязательно должны быть такими уж плохими.
Теперь попробуем ответить на ваш первый вопрос: это зависит от обстоятельств.
Это действительно зависит от того, что вы пытаетесь сделать, и как у вас все настроено. CGI имеет накладные расходы на запуск процесса каждый раз, поэтому он быстр только в том случае, если накладные расходы на запуск процесса значительно меньше, чем остальные накладные расходы запроса (например, доступ к файловой системе или базе данных). Rebol, особенно R2, имеет значительные накладные расходы при запуске процесса, потому что это интерпретатор, который имеет некоторый встроенный интерпретируемый код для загрузки при запуске. Вы можете свести к минимуму эти накладные расходы при запуске, используя SDK для создания своего приложения только с тем кодом, который вам нужен, но в вашем конкретном случае этого может быть недостаточно (не зная, что вы пытаетесь сделать).
FastCGI — это способ избавиться от накладных расходов, связанных с запуском этого процесса, путем запуска внепроцессного сервера приложений вместо запуска нового процесса для каждого запроса. Для чего-то вроде Rebol, у которого есть значительные накладные расходы на запуск процесса, экономия может быть столь же значительной.
Одна вещь, которую вам нужно учитывать, это то, что R2 по большей части имеет модель с одним потоком на процесс, поэтому, если вы хотите обрабатывать несколько одновременных запросов, вам нужно либо выполнять их по частям в одном процессе (например, Node. js) или пусть FastCGI выделяет несколько серверных процессов для независимой обработки нескольких запросов, или, возможно, и то, и другое. Обязательно обратитесь за советом к экспертам Rebol, если перспектива этого пугает, или просто настройте FastCGI, чтобы запустить больше серверов приложений для одновременной работы.
Итак, сколько запросов вы можете выполнять в секунду с настройкой FastCGI, зависит от того, как вы настраиваете FastCGI, как вы пишете свой код обработчика FastCGI, а также от того, сколько и какую работу выполняют ваши запросы.
Это говорит о том, что вы получаете 4-5 запросов в секунду в режиме CGI. Это необычно медленно. Накладные расходы Rebol при запуске в худшем случае не так медленны. Это означает, что либо ваши запросы делают много, либо у вас недостаточно оперативной памяти для одновременного запуска нескольких процессов CGI, либо у вас плохо настроена CGI. Я не уверен, что FastCGI может помочь в этом случае так же, как использование более качественного оборудования или более качественная настройка Apache. Тем не менее, убедитесь, что у вас достаточно рабочих процессов FastCGI, и напишите свой обработчик для одновременной обработки нескольких запросов, и вы сэкономите как можно больше накладных расходов.
Удачи!
person
BrianH
schedule
02.03.2013