Почему я должен избегать использования CGI?

Question

Я пытался создать свой сайт с помощью CGI и ERB, но когда я ищу в Интернете, я вижу, что люди всегда должны избегать использования CGI и всегда использовать Rack.

Я понимаю, что CGI будет вилять много рубиновых процессов, но если я использую FastCGI, будет создан только один постоянный процесс, и он также будет принят на PHP-сайтах. Плюс интерфейс FastCGI создает только один объект для одного запроса и имеет очень хорошую производительность, в отличие от Rack, которая одновременно создает 7 объектов.

Есть ли какая-либо конкретная причина, по которой я не должен использовать CGI? Или это просто ложное предположение, и вполне нормально использовать CGI/FastCGI?

Answer 1

CGI, под которым я подразумеваю как интерфейс, так и общие библиотеки и методы программирования вокруг него, был написан в другое время. Он имеет вид обработчиков запросов как отдельных процессов, связанных с веб-сервером через переменные среды и стандартные потоки ввода-вывода.

Это было современное состояние в свое время, когда на самом деле не существовали «веб-фреймворки» и «встроенные серверные модули», как мы думаем о них сегодня. Таким образом, ...

CGI имеет тенденцию быть медленным

Опять же, модель CGI порождает один процесс для каждого соединения. В то время как нерестовые процессы per se дешево в эти дни, тяжелая инициализация веб-приложений - чтение и анализ множества модулей, создание соединений с базами данных и т. Д. - делает это довольно дорогостоящим.

CGI имеет тенденцию к слишком низкому уровню (ИМХО) дизайну

Опять же, модель CGI явно упоминает переменные окружения и стандартный ввод в качестве интерфейса между запросом и обработчиком. Но кого это волнует? Это намного ниже, чем обычно должен думать дизайнер приложений. Если вы посмотрите на библиотеки и код, основанные на CGI, вы увидите, что основная его часть поощряет «бизнес-логику» наряду с разбором форм и генерированием HTML, что в настоящее время широко рассматривается как опасное смешивание проблем.

Контраст с чем-то вроде Rack :: Builder, где прямо сейчас кодер думает о сопоставлении пространства имен с действием и что это означает для более широкого веб-приложения. (Вдруг мы можем спорить о семантической сети и достоинствах REST и тому подобное, потому что мы не думаем о создании радиокнопок, основанных на вводимом пользователем вводе.)

Да, что-то вроде Rack :: Builder может быть реализован поверх CGI, но вот в чем смысл. Это должен быть слой абстракции, построенный поверх CGI.

CGI имеет тенденцию быть насмешливо уволен

Несмотря на CGI отлично работает хорошо в пределах его ограничений, несмотря на его простое и широкое понимание, CGI часто уволен из рук. Вы тоже можете быть уволены из-под контроля, если CGI - это все, что вы знаете.

Answer 2

Не используйте CGI. Пожалуйста. Это не стоит. Еще в 1990-х, когда никто не знал лучше, это казалось хорошей идеей, но это было тогда, когда скрипты были нечастыми, использовались для особых случаев, таких как обработка форм, а не для целых сайтов.

FastCGI - это попытка «лучшего CGI», но она по-прежнему недостаточна для многих способов, особенно потому, что вам нужно управлять рабочими процессами FastCGI.

Стойка - это намного лучшая система, и она работает очень хорошо. Если вы используете Rack, у вас есть широкий выбор хостинговых систем на выбор, даже Passenger, который действительно прост и надежен.

Я не знаю, что означает, когда вы говорите, что стойка создает «7 объектов одновременно», если вы не имеете в виду, что существует 7 разных процессов в стойке, или вы допустили ошибку в своей реализации.

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

Answer 3

Существует много путаницы о том, что такое CGI, Rack и т.д. Как я описываю here, Rack - это API, а FastCGI - это протокол. CGI также является протоколом, но в его узком смысле также реализация, и за то, о чем вы говорите, совсем не то же самое, что и FastCGI. Итак, давайте начнем с фона.

Еще в начале 90-х годов веб-серверы просто читали файлы (HTML, изображения и т. Д.) С диска и отправляли их клиенту. Люди начали делать некоторую обработку во время запроса, и раннее решение, которое появилось, состояло в том, чтобы запустить программу, которая приведет к возврату результата клиенту, а не просто чтению файла. «Протокол» для этого был для того, чтобы веб-серверу был предоставлен URL-адрес, который он был настроен для выполнения в качестве программы (например, /cgi-bin/my-script), где веб-сервер затем установил набор переменных среды с различной информацией о запросе и запустить программу с телом запроса на стандартном входе. Это упоминалось как «Common Gateway Interface».

Учитывая, что это отклоняет новый процесс для каждого запроса, это явно неэффективно, и вы почти наверняка не хотите использовать этот стиль обработки динамических запросов на высокообъемных веб-сайтах. (Начало всего нового процесса относительно дорого в вычислительных ресурсах.)

Одним из решений для повышения эффективности является то, что вместо запуска нового процесса отправить информацию о запросе в уже существующий процесс. Это то, о чем говорит FastCGI; он поддерживает очень похожий интерфейс с CGI (у вас есть набор переменных с большей частью информации запроса и поток данных для тела запроса). Но вместо того, чтобы устанавливать фактические переменные среды Unix и запускать новый процесс с телом на stdin, он отправляет запрос, похожий на HTTP-запрос, на сервер FCGI, уже запущенный на машине, где он указывает значения этих переменных и содержимое тела запроса ,

Если веб-сервер может иметь встроенный в него программный код, это становится еще более эффективным, поскольку он просто запускает сам код. Два классических примеров того, как вы могли бы сделать это было бы:

• Have PHP встроен в Apache, так что «код сервера Apache» просто называет «код сервера PHP», который является частью одного и того же процесса; и

• Не запускайте Apache вообще, но у вас есть веб-сервер в Ruby (или Python или что-то еще), а также загрузите и запустите еще один код Ruby, который был настроен для обработки запроса.

Итак, где же стойка? Rack - это API, который позволяет коду, который обрабатывает веб-запросы, получать его обычным способом, независимо от веб-сервера.Поэтому, учитывая некоторый Ruby, код для обработки запроса, который использует Rack API, веб-сервер может:

• Будьте веб-сервер на Ruby, который просто делает вызовы функций в своем собственном процессе в Rack-совместимый код, который он загружен;
• Быть веб-сервером (написанным на любом языке), который использует протокол FastCGI для разговора с другим процессом с кодом сервера FastCGI, который снова вызывает вызовы функций для совместимого с Rack кода, который обрабатывает запрос; или
• Будьте сервером, который запускает новый процесс, который интерпретирует переменные среды CGI и стандартный ввод, передаваемый ему, а затем вызывает соответствующий Rack-код.

Таким образом, независимо от того, используете ли вы CGI, FastCGI, другой протокол между процессами или протокол внутрипроцесса, не имеет значения; вы можете использовать любой из тех, кто использует стойку, пока сервер знает об этом или разговаривает с процессом, который может понимать CGI, FastCGI или что-то еще, и вызывать Rack-совместимый код на основе этого запроса.

Итак:

Для масштабирования производительности, вы определенно не хотите быть с помощью CGI; вы хотите использовать FastCGI, аналогичный протокол (например, Tomcat) или прямой вызов кода в процессе.

Если вы используете Rack API, вам не нужно беспокоиться на ранних этапах, какой протокол вы используете между вашим веб-сервером и вашей программой, потому что все точки API, такие как Rack, это то, что вы можете изменить его позже ,