Что случилось с CGI, и как FastCGI спас веб от катастрофы?

[Javian]

Открывал прошивку ip камеры - там папка cgi есть.

[pae174]

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

[Oangai]

извините, но у Вас фактологическая ошибка в отношении изоляции процессов - как минимум апач с самого начала реализовывал мультипроцессную модель и предлагал её по дефолту, создавался пулл дочерних процессов для обработки всех запросов где мастер только принимал и делегировал. В случае ошибки падал только один из дочерних, остальных это не касалось, мастер отслеживал пулл и восстанавливал по необходимости, так что обработчики были вполне между собой изолированы. Да и chroot для дочек там был года с 97-го как минимум. Проблемой становились как раз не падения а возможные зависания дочерних обработчиков, могли возникать зомби которых мастер уже не мог контроллировать, приходилось чуть не вручную отслеживать. Но mod_php например достаточно хорошо тестировался и зависаний не допускал, этим страдали скорее всякие самописные модули на C или mod_perl

[ste4lthy24]

mod_perl тоже просто падает обычно. не сталкивался с зависаниями, хотя, наверное возможно всё.

[SrvTrantor]

Спасибо за уточнение, поправил. Я хотел подчеркнуть тот момент, что при переходе от CGI к mod_php/mod_perl изменилась сама модель, но и она была неидеальна.

[beerware]

Посмотрел на счетчики, воспоминания... первый хостинг на Караване, fortunecity.com

[akakoychenko]

Вообще, не раз ловил себя на мысли о том, что, как будто бы, сама парадигма обработки веб запросов, когда разработчик пишет код, который обрабатывает 1 запрос в вакууме, изначально ущербна.

Высокопроизводительные системы, начиная от биржевых роботов, и заканчивая субд тарантул, работают в парадигме буффера и батчевой обработки. Когда бизнес логика не процессит каждый запрос в вакууме, а делает "рейс" за батчем (там есть нюансы, как именно батчевать, но это не важно для сути), и оперирует именно батчем. Это сразу делает ряд "вебных" вызовов вообще бессмысленными. К примеру, запросить что-то вроде

select * from users where id in (10000 ids)

у реляционной СУБД и сделать 10к "разовых" запросов - принципиально разные по нагрузке и требованию к железу задачи (для модифицирующих запросов все ещё жестче).

Лично я вообще прошёл необычный путь, написав свой первый обработчик http запроса, имея годы опыта написания биржевых роботов, где миллисекунда задержки уже вечность. Из-за этого, познакомившись с веб разработкой, долго не мог понять "а как и почему мир решил жить именно так"

[Kahelman]

Не подскажете в какие годы и на каких биржах у вас миллисекунда задержки была вечностью?

[lazyest]

писал когда-то систему управления офисным сервером на REXX под OS/2 :) аккурат CGI

[Kahelman]

Сей час другая крайность «CGI” либо выпилили из новых версий серверов, либо не завозили.

Так что теперь для простой автоматизации приходится огород городить вместо того чтобы по url простой скрипт дернуть. :(

[AndrewSu]

произошёл скачок в производительности — CGI-скрипт упирался в 5–10 запросов в секунду, а FastCGI на момент создания уже выдавал десятки и сотни

Сейчас не так всё страшно.

Недавно столкнулся с необходимостью перенести свой сервис под apache2+cgi. Тестовый ендпоинд, который соединяется с БД и выполняет запрос "SELECT 1" показал 3000 RPS. Для сравнения, на том же железе с кастомным сервером и наличии пула соединений с БД было 30000 RPS на аналогичном ендпоинте.

Но если учесть, что реальные запросы "немного" сложнее, то оверхед из-за перезапуска cgi процесса не так уж сильно влияет.

[vdudouyt]

Это смотря какой CGI-скрипт. С ростом сложности (а так же количества подлежащих парсингу sloc) оверхед на перезапуск может расти весьма ощутимо даже по сравнению с реальными запросами.

[AndrewSu]

У нас был не скрипт, а приложение, написанное на c++.

[Sambash]

Сегодня это какую-то есть Ai (cgi) на сайте или нету...