К вашему сведению, первоначальный вопрос, который я разместил, здесь, не нужно его читать, поскольку изначально я был далеко:
Мне удалось его выследить, чтобы сохранить жизнь.
Помните, что когда я говорю о keep alives в этом вопросе, я имею в виду USER <-> NGINX keep alives. НЕ NGINX <-> BACKEND (в данном случае php-fpm).
Сценарий три - это проблемный сценарий, я только что включил один и два, чтобы было ясно, что я выполнил все необходимое тестирование.
Итак, вот что происходит:
Сценарий 1 [функция поддержки активности включена]:
A) Выполняется запрос к статическому контенту [запрос не на основе fastcgi, простой доступ к файловой системе]
Б) Сохраняйте жизнь на
C) Контент отправляется без проблем, 100% времени
Сценарий второй [функция поддержания активности отключена]:
A) Запрос динамического контента на основе php-fpm
Б) Сохраняйте жизнь выключен
C) Контент отправляется без проблем, 100% времени
Сценарий третий [поддержка активности]:
A) Запрос динамического контента на основе php-fpm
Б) Сохраняйте жизнь на
C) Контент отправлен, но браузер будет зависать в «состоянии загрузки» до тех пор, пока не будет достигнуто keepalive_timeout. Это состояние выглядит по-разному в разных браузерах. Например, хром будет отображать контент, но будет «крутиться» в верхнем браузере. По достижении keepalive_timeout вращение останавливается, и запрос отображается красным цветом в отладчике, даже если на самом деле содержимое отображается нормально. В IE страница остается пустой до тех пор, пока не истечет время ожидания сохранения активности, а затем отобразится содержимое. Глядя на инструменты разработчика IE, можно увидеть, что содержимое занимает «keepalive_timeout» секунд, обозначенное «синим», что в случае инструментов разработчика IE означает «получение».
Совершенно озадаченный, попытался вернуть conf к самой простой форме, но это все еще происходит.
Подводя итог, кажется, что существует какая-то проблема, связанная с сетью (стек tcp / ip?) При обслуживании результатов на основе php-fpm с включенным сохранением активности.
Любые идеи?
Здесь, вероятно, есть одна или две ошибки.
http://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_keep_conn
syntax: fastcgi_keep_conn on | off;
default:
fastcgi_keep_conn off;
context: http, server, location
По умолчанию сервер FastCGI закрывает соединение сразу после отправки ответа. Если установлено значение on, nginx проинструктирует сервер FastCGI о необходимости держать соединения открытыми. Это, в частности, необходимо для работы соединений keepalive с серверами FastCGI.
или
http://wiki.nginx.org/HttpUpstreamKeepaliveModule
upstream default {
server 10.0.0.1:80;
keepalive 1024 single;
}
Включает поддерживающие соединения для восходящего потока.
Num указывает максимальное количество подключений, которые должны оставаться открытыми до того, как будет достигнуто максимальное количество, закроет наименее недавно использованные подключения.
Single рассматривает все как единый хост. С этим флагом соединения с разными серверными модулями считаются равными.
Оба действительны для Nginx 1.1.4 или новее.