Каковы были основные недостатки веб-разработки на основе CGI-BIN? - PullRequest
5 голосов
/ 08 января 2009

Мне посчастливилось не заниматься веб-разработкой на основе cgi-bin .cgi. Но, как правило, те, кто не скучает по тем дням.

Проект, к которому я недавно присоединился, имеет проблему с производительностью при работе со страницами, которые должны взаимодействовать с устаревшей системой, имеющей API на основе CGI-BIN. Эта система называется COGNOS 7.

Обратная связь, которую я получил на сегодняшний день, заключается в том, что «COGNOS работает медленно», но другие сообщили о большом успехе с COGNOS, я думаю, что это больше связано с доступом через CGI-BIN, а не с производительностью COGNOS самой по себе .

Все это говорит о том, каковы основные проблемы, делающие веб-разработку на основе CGI-BIN неэффективной, сложной и т. Д. *

Ответы [ 4 ]

4 голосов
/ 08 января 2009

Фундаментальная архитектурная проблема систем на основе CGI-BIN заключается в том, что каждый HTTP-запрос требует от сервера запуска нового процесса. Это влияет на производительность несколькими способами:

  • Дорого начинать процесс, так как страницы ОС в программе настраивают процесс и т. Д.
  • Ресурсы не могут быть разделены между запросами, поэтому любые подключения к БД и т. Д. Должны быть установлены с каждым запросом
  • Состояние сеанса пользователя не может быть сохранено в памяти, поэтому оно должно сохраняться при каждом запросе
1 голос
/ 25 января 2009

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

0 голосов
/ 23 сентября 2009

Apache предлагает несколько решений для разных языков (например, mod_perl ), так что скрипт вызывается только один раз, а затем сохраняется в памяти для быстрого поиска. Существует еще множество сайтов, управляемых протоколом GCI, многие из которых работают с достаточно низкой задержкой, если они хорошо кодированы и настроены.

0 голосов
/ 08 января 2009

Основным недостатком, IMHO, был тот же недостаток, что и у всех низкоуровневых кодов - вместо программирования в проблемной области вам пришлось программировать в области реализации. Конечный результат по своей сути был идентичен - HTTP-ответ был отправлен клиенту на основе HTTP-запроса. Тем не менее, получить до этой точки было гораздо сложнее с точки зрения программирования.

...