Как FastCGI работает на веб-сервере (например, Apache 2.2+)?

Question

Я посмотрел на источники FastCGI (fcgi-2.4.0) и на самом деле нет никаких признаков разветвления. Если я не ошибаюсь, веб-сервер вращает процесс для модуля FastCGI (скомпилированный в нем или загруженный как SO / DLL) и обрабатывает управление главным сокетом (обычно это порт TCP: 80).

В * nix модуль FastCGI «блокирует» этот сокет, используя блокировку записи файла (libfcgi / os_unix.c: 989) на весь файловый дескриптор (действительно, сокет прослушивания); таким образом, когда новые подключения приносят доход, только модуль FastCGI может их обрабатывать. Блокировка входящего сокета снимается непосредственно перед передачей в обработку запроса HTTP.

Как видно, модуль FastCGI не является многопроцессорным (многопоточным) (нет внутреннее использование fork / pthread_create) Я предполагаю, что одновременная обработка нескольких одновременных соединений получается через spwaning с веб-сервера (через OS_SpawnChild) модуля FastCGI процессов. Если мы, например, порождаем 3 процесса FastCGI (Apache вызывает 3 x OS_SpawnChild), означает ли это, что мы можем одновременно обслуживать не более 3 запросов?

А) Правильно ли мое видение работы FastCGI?

B) Если стоимость ОС для запуска нового процесса / создания соединения с локальной БД может считаться незначительной, каковы преимущества FastCGI по сравнению с старомодным исполняемым подходом?

Спасибо, Эма! : -)

Answer 1

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

Основным преимуществом является отсутствие необходимости создавать новый php / perl / и т. Д. переводчик каждый раз, что занимает удивительное количество времени.

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

Answer 2

Процессы, порожденные FastCGI, являются постоянными, они не уничтожаются после обработки запроса, вместо этого они «объединяются».

Answer 3

B, да, ЕСЛИ стоимость нереста равна нулю, тогда устаревшие CGI были бы довольно хорошими. Так что, если у вас не так много хитов, просто старый CGI в порядке, используйте его. Смысл быстрого cgi заключается в том, чтобы делать вещи, которые выигрывают от большого количества постоянного хранилища, или структур, которые необходимо создавать ДО того, как вы сможете выполнить свою работу, например, выполнять запросы к большим базам данных, где вместо этого вы хотите оставить библиотеки БД в памяти необходимости перезагружать весь shebang каждый раз, когда вы хотите выполнить запрос.

Имеет значение, когда у вас много хитов.

Answer 4

В самом деле,

так как видно (А) в порядке, теперь как насчет (В)? Если я говорю об исполняемых файлах (правильно скомпилированных программах на C / C ++, а не о таких скриптах, как perl / php / ...), и если мы считаем, что стоимость процесса и стоимость подключения к БД незначительны, то этот подход (FastCGI) просто что-то вроде небольшого усиления по сравнению с простыми исполняемыми файлами CGI?

Я имею в виду, учитывая, что Linux очень быстро порождает (разветвляет) процесс, и если БД работает локально (например, на том же хосте MySQL), время, необходимое для запуска нового исполняемого файла и подключения к БД, практически 0. В этом случае без толкования, только модули Apache C / C ++ будут быстрее, чем этот.

Используя подход FastCGI, вы становитесь еще более уязвимыми к утечкам памяти, так как процесс не разветвляется и не перезапускается каждый раз ... На этом этапе, если вам придется разрабатывать CGI на C / C ++, это не будет лучше использовать old school CGI и / или модули Apache C / C ++ напрямую?

Опять же, я не говорю о скриптах (perl / php / ...), я говорю о скомпилированных CGI.

Еще раз спасибо, Ура, Эма! : -)