subject:"Очень медленный ответ после нескольких быстрых ответов"

Re: Очень медленный ответ после нескольких быстрых ответов

2017-10-05 Пенетрантность EugeneNF

Поскольку с помощью опций nginx  нельзя, я сделал отмену предыдущего запроса
в приложении (как многократно рекомендовалось). Работает быстро и без
ошибок. Спасибо всем за рекомендации и прояснения!

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,276486,276726#msg-276726

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

Re: Очень медленный ответ после нескольких быстрых ответов

2017-09-29 Пенетрантность Konstantin Tokarev



28.09.2017, 22:06, "EugeneNF" :
> Так это всё экспериментальные значения, на которые заменялись параметры по
> умолчанию.
> Я получил ровно один прямой ответ на то, что я бы хотел иметь от nginx:
> "Нельзя".

Просто при виде такого вопроса невольно подозреваешь XY problem

>
> Posted at Nginx Forum: 
> https://forum.nginx.org/read.php?21,276486,276609#msg-276609
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

-- 
Regards,
Konstantin
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Очень медленный ответ после нескольких быстрых ответов

2017-09-28 Пенетрантность EugeneNF

Так это всё экспериментальные значения, на которые заменялись параметры по
умолчанию.
Я получил ровно один прямой ответ на то, что я бы хотел иметь от nginx:
"Нельзя".

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,276486,276609#msg-276609

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

Re: Очень медленный ответ после нескольких быстрых ответов

2017-09-28 Пенетрантность Gena Makhomed

On 28.09.2017 11:39, EugeneNF wrote:

error_log  /var/log/nginx/error.log debug;

для того чтобы получить отладочный лог
надо переключить бинарник на nginx-debug
подробнее об этом тут: http://nginx.org/ru/docs/debugging_log.html

для отладки удобно включать только debug_connection
с определенного IP-адреса, чтобы лог не был очень большим.

кроме того, не понятно какая у Вас стоит версия nginx,
что показывает "nginx -V" ?

воспроизводится ли проблема,
если взять nginx из официального репозитория
http://nginx.org/ru/linux_packages.html#mainline ?

 keepalive_timeout  1;

 uwsgi_connect_timeout 1;
 uwsgi_read_timeout 1;
 uwsgi_send_timeout 1;

лучше оставить дефолтовые значения этих параметров.

>  uwsgi_buffers 64 1M;
>  proxy_buffers 64 1M;

слишком большие значения, если выделять по 64 мегабайта памяти
на одно клиентское соединение - то память очень быстро закончится.

лучше использовать дефолтовые значения этих параметров.

--
Best regards,
 Gena

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

Re: Очень медленный ответ после нескольких быстрых ответов

2017-09-28 Пенетрантность Vadim A. Misbakh-Soloviov

1) местами от ваших конфигов возникает чувство что делались по статье "как 
сделать всё в самых bad practices что только есть", но не буду учить, ладно.

2) попробуйте заменить unix-сокет между NgX и uwsgi на tcp
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Очень медленный ответ после нескольких быстрых ответов

2017-09-28 Пенетрантность Vadim A. Misbakh-Soloviov

В письме от четверг, 28 сентября 2017 г. 15:19:26 +07 пользователь EugeneNF 
написал:
> Как было рекомендовано я добавил  $request_time и $upstream_response_time.
> После нескольких запросов и быстрых ответов лог файлы и для nginx и для
> uwsgi не показывают ничего. Через время ~1min вываливаются все накопленные
> длинные запросы и показывают ожидаемое значения ~1 min для $request_time и
> upstream_response_time. Мой вывод - nginx не принимает новых запросов пока
Неправильный вывод.
Правильный - апстрим (бекенд) ковыряет в носу в течение минуты и только после 
этого отвечает. 
> не обработаются старые длительные. Меня это не устраивает. Я хочу отменить,
> сделать reset и т.д.  для старых запросов при получении новых запросов с
> того же самого IP.
Вам уже как минимум трижды сказали: делайте это на бекенде и всё будет 
работать как вы хотите.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Очень медленный ответ после нескольких быстрых ответов

2017-09-28 Пенетрантность EugeneNF

Буду очень признателен, если глянете на мои конфигурационные файлы для nginx
и uwsgi
#
nginx.conf:

user  nginx;
worker_processes  10;

error_log  /var/log/nginx/error.log debug;
pid/var/run/nginx.pid;


events {
worker_connections  1024;
}


http {
include   /etc/nginx/mime.types;
default_type  application/octet-stream;

log_format  main   '$remote_addr| $time_local]| $request| $request_time|
$upstream_response_time| '
  '$status|$body_bytes_sent|$http_referer|'
  '$http_user_agent';

access_log  /var/log/nginx/access.log  main;

sendfileon;

keepalive_timeout  1;
tcp_nopush on;
tcp_nodelay on;

limit_rate 0;

disable_symlinks off;

include /etc/nginx/conf.d/*.conf;
}
###
nf.conf:

server {
listen   80;
server_name  nf.com;
root   /NF;
 charset win-1251;

location / {
index  index.html index.htm;
}

location /fs {
allow all;
include uwsgi_params;
uwsgi_pass unix:/run/uwsgi/FS.sock;
uwsgi_ignore_client_abort on;
uwsgi_connect_timeout 1;
uwsgi_read_timeout 1;
uwsgi_send_timeout 1;

uwsgi_buffers 64 1M;
proxy_buffers 64 1M;

tcp_nopush on;
tcp_nodelay on;
limit_rate 0;
#
uwsgi.conf:
[uwsgi]
module = FS:application
master = true
processes = 12
enable-threads
async = 1000
ugreen

max-requests = 5000
post-buffering = false
post-buffering-bufsize = 8192000

listen = 100

uid = nginx
socket = /run/uwsgi/FS.sock
chown-socket = nginx:nginx
chmod-socket = 660
vacuum = true

die-on-term = true

logto = /NF/uwsgi.log

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,276486,276595#msg-276595

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

Re: Очень медленный ответ после нескольких быстрых ответов

2017-09-28 Пенетрантность EugeneNF

Конечно я трассирую своё приложение. Проблема в том, что при посылке нового
запроса, он не доходит до приложения. Лог файлы и для nginx и для uwsgi
оживляются только после окончания  долгого запроса.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,276486,276593#msg-276593

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

Re: Очень медленный ответ после нескольких быстрых ответов

2017-09-28 Пенетрантность EugeneNF

Как было рекомендовано я добавил  $request_time и $upstream_response_time.
После нескольких запросов и быстрых ответов лог файлы и для nginx и для
uwsgi не показывают ничего. Через время ~1min вываливаются все накопленные
длинные запросы и показывают ожидаемое значения ~1 min для $request_time и 
upstream_response_time. Мой вывод - nginx не принимает новых запросов пока
не обработаются старые длительные. Меня это не устраивает. Я хочу отменить,
сделать reset и т.д.  для старых запросов при получении новых запросов с
того же самого IP.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,276486,276592#msg-276592

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

Re: Очень медленный ответ после нескольких быстрых ответов

2017-09-28 Пенетрантность EugeneNF

Таймаут не подходит, поскольку в отсутствии второго запроса, первый запрос
должен обработаться до конца независимо от его длительности.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,276486,276591#msg-276591

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

Re: Очень медленный ответ после нескольких быстрых ответов

2017-09-27 Пенетрантность Gena Makhomed


On 27.09.2017 10:59, EugeneNF wrote:

Попробую сформулировать по-другому то, что наблюдаю и пробую изменить.
- nginx получает запрос по какому-то IP. Запрос выполняется очень долго.
- посылается второй запрос с того же самого IP, когда предыдыущий запрос ещё
не обработан и ответ не послан. Этот запрос не доходит до приложения, и нет
возможности принять решение внутри приложения, что же делать в таком случае.

В конфиге есть блок upstream
и в этом блоке директива server c параметром max_conns=1 ?

Покажите конфиг на котором воспроизводится эта проблема,
если Вы уверены, что причина проблемы в nginx, а не в бекенде.

Вопрос: можно ли настроить nginx таким образом, чтобы при посылки запроса с
того же самого IP, предыдущий запрос просто обрывался и забывался. Я понимаю
тяжёлые последствия такого сценария, но вопрос сейчас - можно или нельзя с
помощью опции nginx это сделать?

Нельзя.

--
Best regards,
 Gena

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

Re: Очень медленный ответ после нескольких быстрых ответов

2017-09-27 Пенетрантность Maksim Kulik

Могу предположить, что нечто подобное вы получите установив
uwsgi_read_timeout в, например, 1-5 секунд (опытным путем подберете удобное
вам значение). Из документации:
"Задаёт таймаут при чтении ответа uwsgi-сервера. Таймаут устанавливается не
на всю передачу ответа, а только между двумя операциями чтения. Если по
истечении этого времени uwsgi-сервер ничего не передаст, соединение
закрывается."

Т.е. при превышении этого лимита nginx просто закроет соединение с вашим
бэкэндом и пусть он (бэкэнд) сам потом решает что делать с обрабатываемым
запросом.

27 сентября 2017 г., 11:12 пользователь EugeneNF <
nginx-fo...@forum.nginx.org> написал:

>   Мне это реально нужно, поскольку второй запрос не доходит до
> приложения и нет возможности правильно завершить первый долгий запрос.
>
>
>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Очень медленный ответ после нескольких быстрых ответов

2017-09-27 Пенетрантность Andrey Velikoredchanin

А пробовали сделать лог своего приложения что-бы определить на каком
моменте останавливается второй запрос? Тогда перед этим местом вы могли-бы,
например, ставить какой-то общедоступный флаг, за которым следил-бы первый
запрос и отрубался при его обнаружении. Т.е. решение тут вообще nginx не
касается - это чисто прикладная задача.

27 сентября 2017 г., 11:18 пользователь EugeneNF <
nginx-fo...@forum.nginx.org> написал:

> Спасибо за ответ. Может быть 20 вокеров было мало. Попробую увеличить до
> 50.
> Но хотелось бы найти вариант застраховаться от "зависания". Поскольку нет
> гарантии, что и 50 будет достаточно при посылки запросов со многих IP. Я
> хочу для начала просто делать "reset" для зависшего IP и "начинать жизнь
> сначала".
>
> Posted at Nginx Forum: https://forum.nginx.org/read.
> php?21,276486,276566#msg-276566
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Очень медленный ответ после нескольких быстрых ответов

2017-09-27 Пенетрантность Илья Шипицин

привет!

мне кажется, вы сами себя (и всех остальных) загнали в ловушку "я думаю,
что проблема в этом и этом"

не исключено, что это действительно так, но из приведенной диагностики у
меня такой картины не сложилось

можете более подробно объяснить ход вашей диагностики ?

27 сентября 2017 г., 13:12 пользователь EugeneNF <
nginx-fo...@forum.nginx.org> написал:

> Когда веб сервер получает запрос с какого-то IP, он знает и помнит этот IP.
> Если посылается следующий запрос с того же самого IP в тот момент, когда
> предыдущий запрос ещё не обработан и ответ не послан, есть ли возможность
> настроить nginx, чтобы предыдущий запрос был полностью "разрушен и забыт".
> Пока вопрос не о тяжёлых последствия такого сценария, а о принципиальной
> возможности.   Мне это реально нужно, поскольку второй запрос не доходит до
> приложения и нет возможности правильно завершить первый долгий запрос.
>
> Posted at Nginx Forum: https://forum.nginx.org/read.
> php?21,276486,276565#msg-276565
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Очень медленный ответ после нескольких быстрых ответов

2017-09-27 Пенетрантность EugeneNF

Спасибо за ответ. Может быть 20 вокеров было мало. Попробую увеличить до 50.
Но хотелось бы найти вариант застраховаться от "зависания". Поскольку нет
гарантии, что и 50 будет достаточно при посылки запросов со многих IP. Я
хочу для начала просто делать "reset" для зависшего IP и "начинать жизнь
сначала".

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,276486,276566#msg-276566

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

Re: Очень медленный ответ после нескольких быстрых ответов

2017-09-27 Пенетрантность EugeneNF

Когда веб сервер получает запрос с какого-то IP, он знает и помнит этот IP.
Если посылается следующий запрос с того же самого IP в тот момент, когда
предыдущий запрос ещё не обработан и ответ не послан, есть ли возможность
настроить nginx, чтобы предыдущий запрос был полностью "разрушен и забыт".
Пока вопрос не о тяжёлых последствия такого сценария, а о принципиальной
возможности.   Мне это реально нужно, поскольку второй запрос не доходит до
приложения и нет возможности правильно завершить первый долгий запрос.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,276486,276565#msg-276565

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

Re: Очень медленный ответ после нескольких быстрых ответов

2017-09-27 Пенетрантность Andrey Velikoredchanin

С самого начала у меня есть подозрение что приложение запущено в одном
воркере. В таком варианте, если оно не потоковое, запрос и будет
блокироваться до окончания выполнения первого запроса. Может в этом дело?

27 сентября 2017 г., 10:59 пользователь EugeneNF <
nginx-fo...@forum.nginx.org> написал:

> Попробую сформулировать по-другому то, что наблюдаю и пробую изменить.
> - nginx получает запрос по какому-то IP. Запрос выполняется очень долго.
> - посылается второй запрос с того же самого IP, когда предыдыущий запрос
> ещё
> не обработан и ответ не послан. Этот запрос не доходит до приложения, и нет
> возможности принять решение внутри приложения, что же делать в таком
> случае.
> Вопрос: можно ли настроить nginx таким образом, чтобы при посылки запроса с
> того же самого IP, предыдущий запрос просто обрывался и забывался. Я
> понимаю
> тяжёлые последствия такого сценария, но вопрос сейчас - можно или нельзя с
> помощью опции nginx это сделать?
>
> Posted at Nginx Forum: https://forum.nginx.org/read.
> php?21,276486,276563#msg-276563
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Очень медленный ответ после нескольких быстрых ответов

2017-09-27 Пенетрантность EugeneNF

Попробую сформулировать по-другому то, что наблюдаю и пробую изменить.
- nginx получает запрос по какому-то IP. Запрос выполняется очень долго.
- посылается второй запрос с того же самого IP, когда предыдыущий запрос ещё
не обработан и ответ не послан. Этот запрос не доходит до приложения, и нет
возможности принять решение внутри приложения, что же делать в таком случае.
Вопрос: можно ли настроить nginx таким образом, чтобы при посылки запроса с
того же самого IP, предыдущий запрос просто обрывался и забывался. Я понимаю
тяжёлые последствия такого сценария, но вопрос сейчас - можно или нельзя с
помощью опции nginx это сделать?

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,276486,276563#msg-276563

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

Re: Очень медленный ответ после нескольких быстрых ответов

2017-09-26 Пенетрантность Maxim Dounin

Hello!

On Tue, Sep 26, 2017 at 04:07:34AM -0400, EugeneNF wrote:

> Тут-то и возникает противоречие - как приложению узнать, что второй запрос
> блокирован поскольку nginx ждёт окончания первого запроса?

Тут у вас фактическая ошибка на входе, на которой вы строите свои 
рассуждения, и получаете мусор на выходе.  Нет никакого "второй 
запрос блокирован поскольку nginx ждёт окончания первого запроса".  
С точки зрения nginx'а - запросы независимы, и nginx просто 
передаёт их туда, куда указывает конфигурация.

-- 
Maxim Dounin
http://nginx.org/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Очень медленный ответ после нескольких быстрых ответов

2017-09-26 Пенетрантность Evgeniy Berdnikov

On Tue, Sep 26, 2017 at 04:07:34AM -0400, EugeneNF wrote:
> Тут-то и возникает противоречие - как приложению узнать, что второй запрос
> блокирован поскольку nginx ждёт окончания первого запроса?  Решение видится
> в два этапа - первое nginx просто обрывает первый запрос.

 Каким образом? Вместо абстрактных фантазий лучше напишите конкретно
 что значит "обрывает запрос" -- какие системные вызовы используются,
 что отправляется клиенту, что серверу приложений? Почему вы думаете,
 что сервер приложений чего-то ждёт от апстрима, чтобы срочно прервать
 свою работу? А если не ждёт, то как он узнает, что запрос нужно
 прекратить обрабатывать?

> А приложение уже решает, что же делать при потере связи с клиентом,

 Как оно узнает о потере связи? Конкретный механизм, pls. Какие вызовы,
 какие пакеты пересылаются, какие сигналы/ошибки/etc получает процесс.

>  т.е. заканчивает работу
> с закрытием всего открытого - файлов, баз данных и т.д.

 А если базе отправлен запрос, который она будет молотить долгое время,
 как его прервать? Это точно такая же проблема, которая возникает при
 взаимодействии сервера приложений и nginx, между которыми нет никакой
 асинхронной коммуникации.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Очень медленный ответ после нескольких быстрых ответов

2017-09-26 Пенетрантность EugeneNF

Тут-то и возникает противоречие - как приложению узнать, что второй запрос
блокирован поскольку nginx ждёт окончания первого запроса?  Решение видится
в два этапа - первое nginx просто обрывает первый запрос. А приложение уже
решает, что же делать при потере связи с клиентом,  т.е. заканчивает работу
с закрытием всего открытого - файлов, баз данных и т.д.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,276486,276538#msg-276538

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

Re: Очень медленный ответ после нескольких быстрых ответов

2017-09-25 Пенетрантность Evgeniy Berdnikov

On Mon, Sep 25, 2017 at 03:27:54PM -0400, EugeneNF wrote:
> Представить легко - если кто-то долбит по серверу - отменяется предыдущий
> запрос для такого нетерпеливогого клиента. Abort опция. Можно ли что то
> такое уровне  nginx, а не не уровне приложения?

 Такое представить легко и просто лишь в виде комбинации слов, за которой
 нет ничего конкретного (в виде механизма или алгоритма).

 Стоит же задуматься о конкретике -- сразу возникают вопросы. Что значит
 "отменить" запрос? Прервать процесс-обработчик? Или убить его? Оборвать
 коннекцию с сервером приложений? Так процесс может продолжить работать,
 и таких может плодиться множество, пока сервер не завалится под нагрузкой.
 А какой статус-код отправить клиенту? Как на него отреагирует браузер?
 И так далее.

 Вообще, это задача не для nginx, а для сервера приложений. Если он видит,
 что пришёл новый запрос, идентичный тому, который обрабатывается, и может
 детектировать ситуацию "результат предыдущего запроса не нужен", то пусть
 свернёт работу по старому запросу и обработает новый.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Очень медленный ответ после нескольких быстрых ответов

2017-09-25 Пенетрантность Maxim Dounin

Hello!

On Mon, Sep 25, 2017 at 07:44:40PM -0400, EugeneNF wrote:

> Пробовал увеличить число вокеров для nginx до 20 и uwsgi тоже до 20. Это не
> помогло.

Значит, видимо, проблема где-то глубже в бекенде - какие-то 
блокировки на пользователя, или что-то в этом роде.

Ну или можно предположить, что клиент умудряется слать второй 
запрос в то же соединене, что и первый, но это совсем вряд ли (и 
было бы отчётливо видно по малому $request_time на фоне долгого 
ожидания ответа клиентом).

Отмечу также, что увеличивать количество рабочих процессов nginx'а 
совершенно точно не надо, даже один рабочий процесс способен 
обслуживать тысячи одновременных запросов.

-- 
Maxim Dounin
http://nginx.org/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Очень медленный ответ после нескольких быстрых ответов

2017-09-25 Пенетрантность EugeneNF

Да, это понятно. Я бы хотел противоположное. Старый запрос отменяется, а
новый принимается.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,276486,276532#msg-276532

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

Re: Очень медленный ответ после нескольких быстрых ответов

2017-09-25 Пенетрантность EugeneNF

Пробовал увеличить число вокеров для nginx до 20 и uwsgi тоже до 20. Это не
помогло.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,276486,276531#msg-276531

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

Re: Очень медленный ответ после нескольких быстрых ответов

2017-09-25 Пенетрантность Konstantin Tokarev



25.09.2017, 22:28, "EugeneNF" :
> Представить легко - если кто-то долбит по серверу - отменяется предыдущий
> запрос для такого нетерпеливогого клиента. Abort опция. Можно ли что то
> такое уровне nginx, а не не уровне приложения?

http://nginx.org/en/docs/http/ngx_http_limit_req_module.html

Только отменяться будут новые запросы, а не старые

>
> Posted at Nginx Forum: 
> https://forum.nginx.org/read.php?21,276486,276526#msg-276526
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

-- 
Regards,
Konstantin
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Очень медленный ответ после нескольких быстрых ответов

2017-09-25 Пенетрантность EugeneNF

Представить легко - если кто-то долбит по серверу - отменяется предыдущий
запрос для такого нетерпеливогого клиента. Abort опция. Можно ли что то
такое уровне  nginx, а не не уровне приложения?

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,276486,276526#msg-276526

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

Re: Очень медленный ответ после нескольких быстрых ответов

2017-09-25 Пенетрантность Maxim Dounin

Hello!

On Sun, Sep 24, 2017 at 12:06:59PM -0400, EugeneNF wrote:

> После добавления $request_time и $upstream_response_time стало ясно в чём
> проблема. Спасибо!
> Клиет посылает запрос, который долго обрабатывается (с AJAX). Затем клиет
> посылает второй запрос, который по идее, должен обработаться очень быстро.
> Но nginx ждёт пока не закончится первый запрос. Есть ли опция чтобы отменить
> первый запрос при получении второго от того же самого клиента?

Скорее всего речь о том, что у бекенда не хватает рабочих 
процессов, и второй запрос просто некому обрабатывать.  И, 
соответственно, второе соединение к бекенду висит и ждёт, пока 
бекенд не закончит обрабатывать первый запрос.  Добавлений рабочих 
процессов бекенду - должно эту проблему решить.

-- 
Maxim Dounin
http://nginx.org/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Очень медленный ответ после нескольких быстрых ответов

2017-09-25 Пенетрантность Evgeniy Berdnikov

On Mon, Sep 25, 2017 at 10:56:24AM +0300, Alex Vorona wrote:
> 24.09.17 19:06, EugeneNF wrote:
> [...]
> >Но nginx ждёт пока не закончится первый запрос. Есть ли опция чтобы отменить
> >первый запрос при получении второго от того же самого клиента?
> Как вы увидели, что именно nginx "ничего не делает" и просто ждёт ?

 Гораздо интереснее, как человек представляет себе магию "отмены запроса". :)
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Очень медленный ответ после нескольких быстрых ответов

2017-09-25 Пенетрантность Alex Vorona


Hi,

24.09.17 19:06, EugeneNF wrote:
[...]

Но nginx ждёт пока не закончится первый запрос. Есть ли опция чтобы отменить
первый запрос при получении второго от того же самого клиента?

Как вы увидели, что именно nginx "ничего не делает" и просто ждёт ?

--
Alex Vorona
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Очень медленный ответ после нескольких быстрых ответов

2017-09-24 Пенетрантность EugeneNF

После добавления $request_time и $upstream_response_time стало ясно в чём
проблема. Спасибо!
Клиет посылает запрос, который долго обрабатывается (с AJAX). Затем клиет
посылает второй запрос, который по идее, должен обработаться очень быстро.
Но nginx ждёт пока не закончится первый запрос. Есть ли опция чтобы отменить
первый запрос при получении второго от того же самого клиента?

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,276486,276503#msg-276503

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

Re: Очень медленный ответ после нескольких быстрых ответов

2017-09-23 Пенетрантность Evgeniy Berdnikov

On Sat, Sep 23, 2017 at 05:36:19PM -0400, EugeneNF wrote:
> Я попробовал strace для nginx worker: strace -t -c -p 17630. Но ничего не
> печатается до тех пор пока процесс не закончен.

 Флаг -c означает "выводить только статистику", потому системные вызовы
 и не печатаются. Уберите его, и поставьте -T (вывод времени, в течение
 которого процесс находился в сисколе), -t замените на -tt.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Очень медленный ответ после нескольких быстрых ответов

2017-09-23 Пенетрантность Maxim Dounin

Hello!

On Sat, Sep 23, 2017 at 02:45:05PM -0400, EugeneNF wrote:

> Используется nginx + uwsgi приложение на Python. Первый запрос
> обрабатывается медленно в связи с обработкой данных. Но этот запрос не для
> клиентов. Запросы от клиентов обрабатываются очень быстро, меньше 10
> миллисекунд. Однако после нескольких запросов (6-7)  и быстрых/мгновенных
> ответов, после очередного запроса наступает долгая мрачная  тишина на
> несколько секунд. Затем вываливаются все ответы. Картина повторяется. Что
> может задерживать/блокировать запросы и как с этим бороться?

Для начала имеет смысл добавить в логи пременные $request_time и 
$upstream_response_time, их описания тут:

http://nginx.org/r/$request_time/ru
http://nginx.org/r/$upstream_response_time/ru

Подробно о том, как настраивать логгирование, можно прочитать тут:

http://nginx.org/ru/docs/http/ngx_http_log_module.html

По полученным значениям времён будет очевидно, где происходит 
задержка запросов - где-то при общении nginx'а и клиента (время 
$request_time большое, $upstream_response_time - малое), или же 
при общении с бекендом (время $upstream_response_time - большое).

-- 
Maxim Dounin
http://nginx.org/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Очень медленный ответ после нескольких быстрых ответов

2017-09-23 Пенетрантность EugeneNF

Я попробовал strace для nginx worker: strace -t -c -p 17630. Но ничего не
печатается до тех пор пока процесс не закончен. Ничего очень долгого я не
вижу. Всё меньше 0.001 сек. Я такжу запустил nginx-debug.  После тягостной
тишины он печатает информацию такую же как и при быстрых ответах (насколько
я могу судить).  И после быстрых ответов и после тишины печатается
epoll_wait() error on fd... Так что эта ошибка, наверное не является
причиной медленного ответа.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,276486,276494#msg-276494

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

Re: Очень медленный ответ после нескольких быстрых ответов

2017-09-23 Пенетрантность Evgeniy Berdnikov

On Sat, Sep 23, 2017 at 03:35:16PM -0400, EugeneNF wrote:
> Спасибо за ответ.
> Сервер пока ничем не занят кроме этой тестовой задачи. 40 ядер, 2Т диск, 32
> Г памяти. Во время тишины загрузка нулевая. ОС - CentOS 7. Подскажите как
> трассировать nginx. Я - новичок с ним.

 Для CentOS: man strace. В nginx ещё бывает полезен debug log.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Очень медленный ответ после нескольких быстрых ответов

2017-09-23 Пенетрантность EugeneNF

Спасибо за ответ.
Сервер пока ничем не занят кроме этой тестовой задачи. 40 ядер, 2Т диск, 32
Г памяти. Во время тишины загрузка нулевая. ОС - CentOS 7. Подскажите как
трассировать nginx. Я - новичок с ним.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,276486,276488#msg-276488

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

Re: Очень медленный ответ после нескольких быстрых ответов

2017-09-23 Пенетрантность Evgeniy Berdnikov

On Sat, Sep 23, 2017 at 02:45:05PM -0400, EugeneNF wrote:
> Используется nginx + uwsgi приложение на Python. Первый запрос
> обрабатывается медленно в связи с обработкой данных. Но этот запрос не для
> клиентов. Запросы от клиентов обрабатываются очень быстро, меньше 10
> миллисекунд. Однако после нескольких запросов (6-7)  и быстрых/мгновенных
> ответов, после очередного запроса наступает долгая мрачная  тишина на
> несколько секунд.

 Чем при этом занят воркер, на каком сисколе висит?

> Затем вываливаются все ответы. Картина повторяется. Что
> может задерживать/блокировать запросы и как с этим бороться?

 Своппинг на хосте с сервером приложений, например. Посмотрите потребление
 памяти, помониторьте обмен с дисками. Посмотрите, нет ли в сообщений от
 ядра об ошибках диска. Попробуйте локализовать место, где происходят
 ожидания, трассировкой системных вызовов nginx.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Очень медленный ответ после нескольких быстрых ответов

2017-09-23 Пенетрантность EugeneNF

Используется nginx + uwsgi приложение на Python. Первый запрос
обрабатывается медленно в связи с обработкой данных. Но этот запрос не для
клиентов. Запросы от клиентов обрабатываются очень быстро, меньше 10
миллисекунд. Однако после нескольких запросов (6-7)  и быстрых/мгновенных
ответов, после очередного запроса наступает долгая мрачная  тишина на
несколько секунд. Затем вываливаются все ответы. Картина повторяется. Что
может задерживать/блокировать запросы и как с этим бороться?

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,276486,276486#msg-276486

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

38 matches

Mail list logo