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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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