Я планирую написать довольно приличное веб-приложение на Rebol (на данный момент CGI на Apache 2), но первоначальные тесты производительности были очень обескураживающими. Я получаю всего 4-5 запросов в секунду, когда запускаю тест Apache в приложении. Я хотел бы знать, были ли у других подобные проблемы и действительно ли им помог FastCGI.
И, на самом деле, Rebol поддерживает FastCGI только в версиях Command и SDK. Изменится ли это в ближайшее время, так как исходный код R3 стал открытым?
Прошло некоторое время с тех пор, как я использовал средства 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, и напишите свой обработчик для одновременной обработки нескольких запросов, и вы сэкономите как можно больше накладных расходов.
Удачи!
Трудно ответить на какие-либо проблемы с производительностью, когда мы понятия не имеем, какой скрипт вы пытаетесь запустить. :-) некоторые из следующих вопросов могут показаться глупыми, но я действительно мало знаю о контексте, в котором вы пробуете Rebol CGI.
4-5 запросов в секунду — это ненормально для CGI-приложения, работающего под Apache. Я могу заверить вас, что с любым типом H / W, которому даже десять лет, вы должны получать НАМНОГО больше, чем это.
какие тесты делаете? Для меня rebol запускается так быстро, что может открыться, показать свою консоль и закрыться между обновлениями (на частоте 60 Гц), так что я даже не вижу его появления.
возможно, какая-то небольшая часть вашего кода (или библиотеки, которую вы используете) имеет задержку или небольшое ожидание (возможно, некоторая сетевая задержка для сервера БД).
Кроме того, вы проверяли скорость исходящего трафика сервера?
вы также можете попробовать cheyenne — веб-сервер, созданный с помощью Rebol, способный обслуживать несколько сотен запросов в секунду, когда сами сценарии, очевидно, не занимают слишком много времени.
На самом деле, cheyenne и apache должны быть в состоянии относительно легко насытить сетевую скорость вашего сервера... если у вас длинные сценарии и вам нужна большая пропускная способность, просто добавьте больше рабочих процессов, чтобы иметь больше параллельных задач (при условии, что использование памяти находится в допустимых пределах). пределы)
Если вы можете получить ~30 об/с на одном и том же компьютере, используя Ruby, и одинаковую производительность между Ruby и Rebol на компьютере с Windows, скорее всего, что-то не так с вашим Rebol CGI и/или конфигурацией.
Попробуйте запустить свой скрипт Rebol CGI из командной строки в цикле, чтобы увидеть, является ли причиной медлительности скрипт или ваша конфигурация Apache.
Некоторые другие способы:
Пусть apache использует прокси для реального веб-сервера rebol, например, cheyenne. Более сложно поддерживать его работу при запуске и т. Д.
Запустите ребол за другим языком через канал. Используйте язык с поддержкой fastcgi.
Запустите rebol как tcp-daemon, пусть с ним свяжется язык fastcgi.
