Задержка записи между контролируемой начальной точкой и неконтролируемой конечной точкой

9

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

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

В настоящее время я использую пинг-плоттер или просто старый добрый непрерывный pingилиtracert

Если я пытаюсь установить более реалистичные сквозные числа (программное обеспечение, с которым я работаю, является программным обеспечением базы данных), я иногда буду использовать Fiddler 2 для захвата веб-трафика и сравнения некоторых таймеров (например, ClientDoneRequest-> ServerBeginResponse) с получить полное время до конца.

На что вы, ребята, обращаете внимание при определении чисел для прямой задержки в сети?

troubleshooting latency

— Шон Лонг
источник

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

— jwbensley

Это было довольно открыто, и я получил ответ, который хотел. Я просто не пометил это как таковой. Пинг - это правильный инструмент для того, что я делаю.

— Шон Лонг,

Понятно, пожалуйста, обратите внимание, что открытые вопросы мешают; networkengineering.stackexchange.com/faq#dontask В будущем вы должны попытаться перечислить точки, которые вам нужны, в инструменте измерения, причины, по которым они вам нужны, точки, которые вам не нравятся, и т. д., чтобы придать вопросу дополнительную структуру.

— Jwbensley

7

Вторая половина вашего вопроса, кажется, указывает на то, что вы ищете цифры задержки, которые учитывают процесс формирования данных прикладного уровня, и в этом случае «пинг» не сильно поможет, учитывая, что в пинге не так много данных для формирования пакет.

Сетевые люди обычно полагаются на пинг, потому что это относительно легкий и надежный способ создания определенного количества случайных данных для проверки достижимости и задержки для заданного пути. Например, приложение, которое использует вызовы HTTP, будет вести себя иначе, поскольку HTTP отличается от ICMP.

Если вас интересуют общие показатели задержки в сети, вне какого-либо конкретного контекста приложения (что является лучшим способом проверки), ping работает просто отлично.

— Mierdin
источник

Я больше обеспокоен вещами сетевого уровня здесь. Есть и другие способы изолировать и протестировать прикладной уровень, и я включил информацию о фиддлере в основном в качестве фона. Из остальных комментариев кажется, что Пинг в основном собирается дать мне наилучшую информацию, не обращаясь к конкретному инструменту.

— Шон Лонг,

5

У вас есть возможность использовать IP SLA между двумя маршрутизаторами в каждой точке? Я не уверен насчет вашей топологии на удаленном конце, поэтому не уверен, есть ли у вас сервер на другой стороне или этот сервер подключен к маршрутизатору, который теоретически может выполнять IP SLA

— mellowd
источник

4

Я просто хочу упомянуть пару вещей. Задержка может сильно зависеть от вашего хоста. Убедитесь, что это сервер, с которого вы тестируете, а не ноутбук. В зависимости от операционной системы (Windows или Linux) время задержки пинга может быть разным. У меня был опыт, когда системы Windows показывали более медленную задержку, чем системы Linux в тех же сетевых путях.

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

Вы пытаетесь выяснить, работает ли сеть хорошо или серверы выполняют свою работу?

— Matt
источник

Я пытался понять, как точно измерить сетевой материал, я понимаю, как это может сбить с толку (так как я упомянул Fiddler2). Я могу достаточно легко изолировать и протестировать материал прикладного уровня (это совсем другая история), но мне нужно уметь точно измерять поездки между данной средой и удаленным центром обработки данных, а также внутренне между клиентской рабочей станцией и сервером ( Так через Ethernet / беспроводной).

— Шон Лонг,

4

Задержка может быть забавной вещью для измерения - особенно точно. Ping достаточно хорош для общей идеи о том, какова задержка вашей сети, но когда дело доходит до очень низких цифр, это может стать неподходящим инструментом для работы. Это также ничего не делает для более высокого уровня тестирования (например, время отклика сайта).

Для точного измерения производительности сети (задержка / пропускная способность / потери / и т. Д.) Мне нравится тестирование Exfo . Это просто предпочтение, и, честно говоря, это первое устройство, которое я использовал, поэтому я уверен, что конкурирующие устройства будут работать так же хорошо. JDSU также является крупным поставщиком этого вида оборудования.

Существует также PCHAR, который является инструментом с открытым исходным кодом для измерения задержки более точно, чем ping. Я не использовал это непосредственно, но я знаю людей, которые имеют и любят это.

Эта статья дает вам хороший обзор некоторых вещей, которые ICMP Echo может / не может делать хорошо.

— bigmstone
источник