Откуда три секунды?

@kotelok · Регистрация: 08.08.2014

Студворк — интернет-сервис помощи студентам

Есть первая конфигурация:

Code
1
клиент -> nginx (https) -> .net api (http)

И есть вторая конфигурация (физически этот тот же сервис и тот же клиент, на тех же машинах, просто обращение напрямую):

Code
1
клиент -> .net api (http)

Клиент - тестовое консольное приложение на .NET, которое:
1. Запускается.
2. Выполняет (через HttpClient) параллельно несколько десятков/сотен одинаковых GET-запросов к API.
3. Завершается (т.е. приложение выгружается из памяти).

Сценарий тестирования:
1. Запустить тестовое клиентское приложение (любое количество раз подряд, т.е. пара секунд между запусками, и хоть 10, хоть 100 запусков): ОК (на все запросы ответы возвращаются без задержек и в первой, и во второй конфигурации).
2. Подождать 60-90 секунд (после последнего запуска тестового клиентского приложения).
3. Запустить приложение снова, один раз:
3.1. Если первая конфигурация (через nginx), то часть запросов отрабатывает без задержек, а часть - с фиксированной дельтой в +3 секунды. Т.е. nginx соединение от клиента принимает мгновенно, но первый ответный байт выдаёт с задержкой. При этом в логах API-сервиса всё ок, т.е. он, от 'nginx' получает запрос с этой самой дельтой в 3 секунды и отрабатывает штатно (по времени обработки). Если после этого лагнутого запуска снова запускать это же приложение любое количество раз подряд, то всё ок, все запросы без задержек через тот же nginx (как и в п.1).
3.2. Если вторая конфигурация: ОК (на все запросы ответы возвращаются без задержек).

Где может быть проблема и как решить?

Стабильно повторяется в том числе при обращении к этому API со страницы в браузере. Если в Хроме посмотреть 'timing' проблемного запроса, то эти 3 секунды тоже видны:
1. Queueing: 0.7ms.
2. Stalled: 0.46ms.
3. Initial connection: 7.85ms (это подключение к nginx).
4. SSL: 4.85ms.
5. Request send: 0.58ms.
6. Waiting for server response: 3003ms (в обычной ситуации тут время примерно равное времени обработки запроса на целевом API, в проблемной - время обработки запроса в API + примерно 3 секунды).
7. Content download: 0.76ms.

При этом, если из браузера параллельно выполняется сразу два-три запроса к этому API (через этот nginx), то до целевого API проблемные запросы тоже доходят с задержкой.

P.S.: API-сервис максимально стандартный, т.е. он просто запускается как служба (без IIS), а из конфигов у него только порт, на котором он слушает подключения.

@kotelok · 17.12.2025, 13:19 **[ТС]**

В общем, что-то не так с TCP-подключениями.

На примере установки группы параллельных подключений (изначально на сервере на этом порту подключений нет, только прослушка порта, согласно 'netstat'):

1. Если подключаться напрямую из .NET-консольного клиента, то после установки всех подключений (и до их закрытия со стороны клиента), все соединения на сервере отображаются в состоянии 'ESTABLISHED'. Никаких задержек не возникает. После закрытия тестового клиента - все соединения (на сервере) сразу пропадают из списка.

2. Если подключаться через 'nginx' (любым клиентом) или напрямую (в обход 'nginx') из консоли Хрома, то:

2.1. Те соединения, по которым ответ пришёл сразу, отображаются в состоянии 'TIME_WAIT' (и остаются в списке в этом состоянии ещё пару минут, после чего пропадают). И пока они вот так висят, повторные запросы проходят гарантированно без задержек.

2.2. Те соединения, по которым возникла задержка в 3 секунды, в этот самый промежуток в 3 секунды, отображаются в состоянии 'SYN_RECEIVED', после чего переходят в 'TIME_WAIT' (и далее как в п.2.1).

Если тот же API-сервис запустить на другой машине (собрано из тех же исходников на той же сборочной машине с теми же параметрами), то проблема не повторяется ни при каком количестве соединений, ни при каких сценариях. При этом другая машина - это клон (виртуальный) проблемной машины. Версия/билд Windows там точно такие же, .NET тоже идентичный - 7.0.20.

P.S.: в виндовом файрволе правило для сервиса есть (ну и для тестов потом полностью отключил файрвол на этой машине).

@wizard41 · 17.12.2025, 13:33

Сообщение от kotelok

В общем, что-то не так с TCP-подключениями.

Я бы подумал на первичное обновление ARP-таблиц после установления соединений, но 3 сек что-то многовато для этого..

@kotelok · 23.12.2025, 11:54 **[ТС]**

Всё ещё более странно.

Есть API-сервис и прямое подключение с клиента:

Code
1
клиент -> .net api (http)

И есть две клиентские машины (обе физические, находятся в одной подсети):

1. С первой запускаю тестовую утилиту и выполняю хоть 500, хоть 1000 одновременных запросов на этот API - всегда всё ок. Даже если параллельно запустить тестовую утилиту несколько раз и из каждой сделать сотни-тысячи запросов. Ни разу проблемный сценарий не повторился.

2. Со второй машины - запускаю ту же тестовую утилиту, и даже при совсем малом количестве одновременных подключений (вот даже если 3-4 всего) иногда получаю эти самые дополнительные +3 секунды на части подключений в состоянии 'SYN_RECEIVED'.

Копирую этот API-сервис на другой компьютер, запускаю. И всё ок, с обеих (тех же) клиентских машин всегда всё ок, проблемный сценарий не повторился ни разу.

Code
1
2
3
4
Клиент A → Сервер 1: ✅ OK
Клиент B → Сервер 1: ❌ FAIL (SYN_RECEIVED, +3с)
Клиент A → Сервер 2: ✅ OK
Клиент B → Сервер 2: ✅ OK

I can · 23.12.2025, 12:48

kotelok, а антивирус, фаерволл или брандмауэр не могут вмешиваться как-то?

@kotelok · 23.12.2025, 12:53 **[ТС]**

Сообщение от I can

kotelok, а антивирус, фаерволл или брандмауэр не могут вмешиваться как-то?

Могут, наверное. Но в сценарии "клиент B -> Сервер 2" на сервере есть виндовый файрвол, а на клиенте и виндовый, и касперский, и всё ок. На тестовом сервере, где проблема повторяется, касперского нет, а виндовая защита отключена.

I can · 23.12.2025, 13:03

Не по теме:

Сообщение от kotelok

на сервере есть виндовый файрвол, а на клиенте и виндовый, и касперский, и всё ок.

Да хрен знает как они работают. Я в своё время мучился с простым вызовом ffmpeg. Он то работал шустро, то начинал дико тупить, простейшие команды выполнялись по 3-4 секунды. В конце концов оказалось, что это мудит защитник - то не проверяет ничего целые сутки, то начинает поверять программу при каждом вызове, 1000 раз запустишь - 1000 раз проверит.
Вот вспомнилось из-за этой задержки в 3 секунды.

@wizard41 · 23.12.2025, 14:05

kotelok, traccert что говорит?

@kotelok · 23.12.2025, 14:10 **[ТС]**

Сообщение от wizard41

traccert что говорит?

Всё ок, вроде:

Code
1
2
  1     1 ms    <1 мс    <1 мс  [гейт подсети]
  2    <1 мс    <1 мс    <1 мс  [целевой сервер]

@wizard41 · 23.12.2025, 14:18

Т.е. промежуточный узел только один?
Ну задержка явно не в нем.. Тут скорее всего какие-то низкоуровневые дела происходят..

Добавлено через 1 минуту
На глаз тут не определить ничего, наверное. Надо спец-софтом смотреть и протоколировать обмен..

Новые блоги и статьи Все статьи Все блоги /
Кто-нибудь знает, где можно бесплатно получить настольный компьютер или ноутбук? США. Programma_Boinc 26.12.2025 Нашел на реддите интересную статью под названием Anyone know where to get a free Desktop or Laptop? Ниже её машинный перевод. После долгих разбирательств я наконец-то вернула себе. . .	Thinkpad X220 Tablet — это лучший бюджетный ноутбук для учёбы, точка. Programma_Boinc 23.12.2025 Рецензия / Мнение/ Перевод Нашел на реддите интересную статью под названием The Thinkpad X220 Tablet is the best budget school laptop period . Ниже её машинный перевод. Thinkpad X220 Tablet —. . .	PhpStorm 2025.3: WSL Terminal всегда стартует в ~ and_y87 14.12.2025 PhpStorm 2025. 3: WSL Terminal всегда стартует в ~ (home), игнорируя директорию проекта Симптом: После обновления до PhpStorm 2025. 3 встроенный терминал WSL открывается в домашней директории. . .	Как объединить две одинаковые БД Access с разными данными VikBal 11.12.2025 Помогите пожалуйста !! Как объединить 2 одинаковые БД Access с разными данными.	Новый ноутбук volvo 07.12.2025 Всем привет. По скидке в "черную пятницу" взял себе новый ноутбук Lenovo ThinkBook 16 G7 на Амазоне: Ryzen 5 7533HS 64 Gb DDR5 1Tb NVMe 16" Full HD Display Win11 Pro
Музыка, написанная Искусственным Интеллектом volvo 04.12.2025 Всем привет. Некоторое время назад меня заинтересовало, что уже умеет ИИ в плане написания музыки для песен, и, собственно, исполнения этих самых песен. Стихов у нас много, уже вышли 4 книги, еще 3. . .	От async/await к виртуальным потокам в Python IndentationError 23.11.2025 Армин Ронахер поставил под сомнение async/ await. Создатель Flask заявляет: цветные функции - провал, виртуальные потоки - решение. Не threading-динозавры, а новое поколение лёгких потоков. Откат?. . .	Поиск "дружественных имён" СОМ портов Argus19 22.11.2025 Поиск "дружественных имён" СОМ портов На странице: https:/ / norseev. ru/ 2018/ 01/ 04/ comportlist_windows/ нашёл схожую тему. Там приведён код на С++, который показывает только имена СОМ портов, типа,. . .	Сколько Государство потратило денег на меня, обеспечивая инсулином. Programma_Boinc 20.11.2025 Сколько Государство потратило денег на меня, обеспечивая инсулином. Вот решила сделать интересный приблизительный подсчет, сколько государство потратило на меня денег на покупку инсулинов. . . .	Ломающие изменения в C#.NStar Alpha Etyuhibosecyu 20.11.2025 Уже можно не только тестировать, но и пользоваться C#. NStar - писать оконные приложения, содержащие надписи, кнопки, текстовые поля и даже изображения, например, моя игра "Три в ряд" написана на этом. . .

@kotelok 1339 / 919 / 264 Регистрация: 08.08.2014 Сообщений: 2,764
	17.12.2025, 13:19 [ТС]
	В общем, что-то не так с TCP-подключениями. На примере установки группы параллельных подключений (изначально на сервере на этом порту подключений нет, только прослушка порта, согласно 'netstat'): 1. Если подключаться напрямую из .NET-консольного клиента, то после установки всех подключений (и до их закрытия со стороны клиента), все соединения на сервере отображаются в состоянии 'ESTABLISHED'. Никаких задержек не возникает. После закрытия тестового клиента - все соединения (на сервере) сразу пропадают из списка. 2. Если подключаться через 'nginx' (любым клиентом) или напрямую (в обход 'nginx') из консоли Хрома, то: 2.1. Те соединения, по которым ответ пришёл сразу, отображаются в состоянии 'TIME_WAIT' (и остаются в списке в этом состоянии ещё пару минут, после чего пропадают). И пока они вот так висят, повторные запросы проходят гарантированно без задержек. 2.2. Те соединения, по которым возникла задержка в 3 секунды, в этот самый промежуток в 3 секунды, отображаются в состоянии 'SYN_RECEIVED', после чего переходят в 'TIME_WAIT' (и далее как в п.2.1). Если тот же API-сервис запустить на другой машине (собрано из тех же исходников на той же сборочной машине с теми же параметрами), то проблема не повторяется ни при каком количестве соединений, ни при каких сценариях. При этом другая машина - это клон (виртуальный) проблемной машины. Версия/билд Windows там точно такие же, .NET тоже идентичный - 7.0.20. P.S.: в виндовом файрволе правило для сервиса есть (ну и для тестов потом полностью отключил файрвол на этой машине). 0

I can sleep 4916 / 4567 / 838 Регистрация: 13.04.2015 Сообщений: 9,698
	23.12.2025, 12:48
	kotelok, а антивирус, фаерволл или брандмауэр не могут вмешиваться как-то? 1

@wizard41 3389 / 2713 / 574 Регистрация: 04.09.2018 Сообщений: 8,531 Записей в блоге: 3
	23.12.2025, 14:05
	kotelok, `traccert` что говорит? 0

@wizard41 3389 / 2713 / 574 Регистрация: 04.09.2018 Сообщений: 8,531 Записей в блоге: 3
	23.12.2025, 14:18
	Т.е. промежуточный узел только один? Ну задержка явно не в нем.. Тут скорее всего какие-то низкоуровневые дела происходят.. Добавлено через 1 минуту На глаз тут не определить ничего, наверное. Надо спец-софтом смотреть и протоколировать обмен.. 1