Комментарии 16
Открывал прошивку ip камеры - там папка cgi есть.
извините, но у Вас фактологическая ошибка в отношении изоляции процессов - как минимум апач с самого начала реализовывал мультипроцессную модель и предлагал её по дефолту, создавался пулл дочерних процессов для обработки всех запросов где мастер только принимал и делегировал. В случае ошибки падал только один из дочерних, остальных это не касалось, мастер отслеживал пулл и восстанавливал по необходимости, так что обработчики были вполне между собой изолированы. Да и chroot для дочек там был года с 97-го как минимум. Проблемой становились как раз не падения а возможные зависания дочерних обработчиков, могли возникать зомби которых мастер уже не мог контроллировать, приходилось чуть не вручную отслеживать. Но mod_php например достаточно хорошо тестировался и зависаний не допускал, этим страдали скорее всякие самописные модули на C или mod_perl
Посмотрел на счетчики, воспоминания... первый хостинг на Караване, fortunecity.com
Вообще, не раз ловил себя на мысли о том, что, как будто бы, сама парадигма обработки веб запросов, когда разработчик пишет код, который обрабатывает 1 запрос в вакууме, изначально ущербна.
Высокопроизводительные системы, начиная от биржевых роботов, и заканчивая субд тарантул, работают в парадигме буффера и батчевой обработки. Когда бизнес логика не процессит каждый запрос в вакууме, а делает "рейс" за батчем (там есть нюансы, как именно батчевать, но это не важно для сути), и оперирует именно батчем. Это сразу делает ряд "вебных" вызовов вообще бессмысленными. К примеру, запросить что-то вроде
select * from users where id in (10000 ids)
у реляционной СУБД и сделать 10к "разовых" запросов - принципиально разные по нагрузке и требованию к железу задачи (для модифицирующих запросов все ещё жестче).
Лично я вообще прошёл необычный путь, написав свой первый обработчик http запроса, имея годы опыта написания биржевых роботов, где миллисекунда задержки уже вечность. Из-за этого, познакомившись с веб разработкой, долго не мог понять "а как и почему мир решил жить именно так"
писал когда-то систему управления офисным сервером на REXX под OS/2 :) аккурат CGI
произошёл скачок в производительности — CGI-скрипт упирался в 5–10 запросов в секунду, а FastCGI на момент создания уже выдавал десятки и сотни
Сейчас не так всё страшно.
Недавно столкнулся с необходимостью перенести свой сервис под apache2+cgi. Тестовый ендпоинд, который соединяется с БД и выполняет запрос "SELECT 1" показал 3000 RPS. Для сравнения, на том же железе с кастомным сервером и наличии пула соединений с БД было 30000 RPS на аналогичном ендпоинте.
Но если учесть, что реальные запросы "немного" сложнее, то оверхед из-за перезапуска cgi процесса не так уж сильно влияет.
Сегодня это какую-то есть Ai (cgi) на сайте или нету...
Странная статья. Дескать в модулях apache накапливались утечки памяти, они превращались в неконтролируемые зомби, которые было трудно контролировать. А в FastCGI утечки памяти уже не накапливались, и в зомби они не превращались, и с контролем было все ок?
MaxConnectionsPerChild в apache, mod_status, ProxyTimeout, RequestReadTimeout - это все трудно контролировать потому что документацию и примеры настройки прочитать нужно? Ну наверное да, читать, думать и настраивать обычно больно.
Про виртуальный хостинг одним httpd демоном - ну это такое. Что мешало запустить даже в пределах одной виртуальной машины для каждого клиента свой отдельный httpd по chroot, поставив сверху балансировщик в виде haproxy или того-же nginix, на этой или и вовсе на другой машине? cgroups там тоже можно было, хоть и не сразу.
Скорее всего FastCGI появился как костыль для nginx для запуска PHP просто потому что там по-другому никак, а затем в силу сетевого эффекта он и стал популярен в массах, делай как я/как все, иначе проиграешь! А по сути просто раньше было два процесса apache/php + mysql|pg, а теперь их стало три - nginx, fastcgi/php, mysql|pg и это назвали новой парадигмой.
Что мешало просто поставить перед apache тот-же haproxy или тот-же nginx, или даже еще один apache reverse proxy, и прикрутить мониторинг зависших workerов (который нужен и даже обязателен и для fastcgi) - просто загадка. Наверное просто никто не показал в статьях как надо.
Вечер наверное прошел не зря.
Клиентская часть: libfcgi для С/C++ существует только в epel, компания автор много лет как уже не существует, изначальный сайт прикопали в архивах на git. Но клиентская библиотека пока еще вполне работоспосбна, сборка примеров прошла без проблем.
Серверная часть:
Apache 2.4
mod_fast_cgi - изначальный авторский модуль от авторов libfcgi, похоже заброшен и более не поддерживается и не поставляется в RHEL или epel
mod_proxy_fcgi - работает, если закрывать каждый TCP/IP запрос после ответа, но наглухо виснет при включенной опции connection reuse в TCP/IP; не умеет connection reuse в Unix domain socketы. В замерах показал не более 2000 rps. Замеры тут и далее ab -n 100000 -c 10 -k. В статике этот же сервер отдает 190000rps.
mod_fcgid - интересный комбайн от китайских производителей, имеет встроенный process monitor, (re)spawner, работает правда через sdin/stdout pipes, но показал до 9000 rps. Сonnection reuse включен штатно и работает стабильно. Клиентская часть переводится на FastCGI добавлением всего четырех строк в изначальную CGI версию кода, что очень удобно. Практически успех и возможно даже production ready, выглядит вполне зрелым в части богатства настроек и функционала.
Nginx: штатно умеет FastCGI в TCP/IP и в domain sockets, а вот в stdin/stout pipes похоже не умеет. Но умеет по умолчанию выключенную опцию connection reuse, и при ее включении работает нестабильно, при повышении нагрузки ab может зависнуть и уйти в таймауты. Без connection reuse показывает до 2000 rps, при connection reuse до 5000 rps, если аккуратно быть с числом одновременных коннектов в -c. Но настроек больше, чем у всех остальных вместе взятых :) Похоже всего его так и используют для PHP-FPM, т.е. на каждый request открывают и закрывают новое TCP/IP соединение, что несколько печально.
Интереса ради этот-же helloworld код на apache httpd 2.4 и архаичном CGI, т.е. просто stdin/stdout и fork()/exit() каждый раз - показал до 1500 rps. Т.е. цифры одного порядка.
Вывод? Не такой уж он и fast, этот ваш FastCGI. И списывать apache httpd, да и самого дедушку CGI - возможно все еще сильно рано, или и вовсе не нужно вообще.
Что случилось с CGI, и как FastCGI спас веб от катастрофы?