On 01-04-20 13:58, Evgeniy Berdnikov wrote:
> On Wed, Apr 01, 2020 at 01:06:27PM +0200, Valery Kholodkov wrote:
>> FastCGI использовался в прошлом для ускорения комуникации между веб-сервером
>> и апп-сервером.
>
> Разве? Запросы, упакованные в FastCGI, бегут по сети между серверами
> быстрее, чем те же запросы в виде HTTP?

См. https://en.wikipedia.org/wiki/FastCGI -> Implementation details

>> Сейчас, когда можно с легкостью написать событийно-ориентированное
>> приложение отвечающее по HTTP, преимущество использования FastCGI
>> представляется сомнительным.
>
> Возможность писать простые однопоточные приложения как раз является
> преимуществом. К тому же запрос в FastCGI доступен приложению в
> уже разложенном по хедерам виде.

А как насчет кук, параметров, разбора тела, поддержки сессий? libfcgi-то
отдает только голый запрос.

Далее, зачем в 2020 году писать многопоточное приложение с кучей
блокирующих библиотек, если можно писать приложение с кучей
неблокирующих библиотек?

>> Если есть задача сделать приложение на C++ и подключить к nginx с помощью
>> libfcgi, то это несложно. А вот выжать из него максимум производительности,
>> реализовать поддерджку всех фич HTTP и поддерживать его в течении
>> длительного времени -- это гораздо сложнее, чем на то же самом node.js.
>
> 1. О каких фичах http речь?
> 2. Где можно выжать максимум производительности, за счёт чего?
> 3. Приведите примеры, pls, где что-то выжимается большим трудом на FastCGI
> и легко и просто на Node.js.

Давайте решим этот спор следующим образом: если Вам требуется некоторое
приложение на FastCGI и C++, я готов Вам его разработать и поддерживать,
если Вы готовы за это заплатить.

--
Val
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru