Я использую NGINX в качестве обратного прокси в сочетании с ngx_http_fastcgi_module.Он передает запросы в пользовательский Golang FastCGI, который выполняет процесс PHP-CGI.
Существуют запросы, которые занимают слишком много времени из-за сложного кода, который используют наши клиенты.Если пользователь нажимает другую ссылку в ожидании запроса, браузер отменяет предыдущий запрос, и NGINX видит его:
[info] 24#24: *1516 client 1.2.3.4 closed keepalive connection
, и это здорово!Но мой основной процесс PHP-CGI продолжает работать до истечения времени ожидания.Это может потреблять много ресурсов, если пользователь продолжает нажимать больше ссылок.Я подозреваю, что моя проблема может заключаться в том, что NGINX явно не отменяет вышестоящий запрос.Я нашел параметр fastcgi_ignore_client_abort , и кажется, что по умолчанию не игнорируется (что хорошо).В нем говорится:
Определяет, должно ли быть закрыто соединение с прокси-сервером, когда клиент закрывает соединение, не ожидая ответа.
Означает ли это, что оно действительно завершаетсяа также запрос в восходящем направлении или просто игнорирование запроса / ответа в восходящем направлении?
И если должен отправлять сигнал в восходящем направлении, есть ли способ в NGINX, чтобы я мог убедиться, что он работаеткак и ожидалось?
На стороне Fast-CGI сервер Golang ожидает Done() от http.Request.Context() во время выполнения запроса.Если NGINX явно завершает запрос восходящего потока, мы думаем, что он должен его обнаружить.Кто-нибудь знает, если это неправильно?