Высокая задержка, но пинг показывает низкую задержку

8

Мы наблюдаем задержки ~ 100-300 мс для служб, обращающихся к удаленному ресурсу в той же подсети, однако, когда мы используем ping (размер пинга был такого же размера, что и при обычной отправке пакетов), мы видим ответы 5 мс или меньше. Что-нибудь еще мы должны проверить?

Выдержка из монитора ресурсов

— Миндаугас Мозурас
источник

12

Кроме того, сеть 10.0.0.0/8 зарезервирована для частных сетей и не является публично маршрутизируемой. Поэтому скрывать часть IP-адреса не нужно. Более подробная информация здесь - en.wikipedia.org/wiki/… .

— Buggabill

21

Что означает «задержка»?
Сравниваете ли вы время отклика ICMP с временем обработки заявки?

Если бы вы были, это объяснило бы, а также не сравнивать яблоки и апельсины :)

— adaptr
источник

4

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

— EEAA

3

... но они оба круглые (и это работает для RTT и указанных фруктов!)

— voretaq7

4

..и ICMP-пакеты имеют размер 64 байта. Их общая и измеренная задержка гарантированно будет лучше, чем что-либо, содержащее фактическую полезную нагрузку данных.

— Адаптер

2

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

— TomTom

1

Я бы сказал: проверить сеть, интерфейсы и прочее. Может быть, ваши приложения показывают такую задержку из-за сброса сообщений из-за проблем на интерфейсах

— Alfabravo

8

может быть, у вас есть потери пакетов [которые вызывают повторные передачи], например, для больших пакетов?

может быть, попробуйте ping -s 1400 addressпод Linux или ping -l 1400 addressпод Windows.

если это не помогает попытаться посмотреть на трафик с помощью wireshark - возможно, есть какие-то странные повторные передачи, поврежденные пакеты?

— PQD
источник

3

Такое несоответствие обычно указывает на проблему в приложении / сервере. Хотя возможно, что ваш пинг отличается из-за приоритетов QoS / сети, я смотрю не на первое место, если вы говорите о системах в одной локальной сети.

Каково ваше время ожидания доступа к услуге с того же хоста, на котором она обслуживается? Этот хост предоставляет другие услуги быстрее? Это под большой нагрузкой ввода-вывода?

— Джефф Ферланд
источник

1

Как вы и подозреваете, задержка пинга! = Время прохождения сигнала по TCP, особенно, если передаются данные. Вполне возможно, что все это происходит из-за задержанных ACK (которые могут накладывать ~ 200 мс, общая настройка по умолчанию) или из-за плохого взаимодействия между Nagle / и DACK, которое может увеличить его до ~ 500 мс. Захват пакета в порядке здесь.

Также обратите внимание, что задержанный таймер подтверждения не зависит от потока TCP и создается при загрузке системы. Таким образом, он может срабатывать в любое время между 1-200 мс внутри потока и обычно вызывает задержку в стиле «диапазон», как вы описываете.

— mcauth
источник