В данный момент мы пытаемся решить, переместить ли наш центр обработки данных с западного побережья на восточное побережье.
Тем не менее, я вижу некоторые тревожные цифры латентности от моего западного побережья до восточного побережья. Вот пример результата, извлекая небольшой файл логотипа .png в Google Chrome и используя инструменты разработчика, чтобы увидеть, сколько времени занимает запрос:
- От западного побережья до восточного:
задержка 215 мс, время передачи 46 мс, всего 261 мс - От западного побережья до западного:
задержка 114 мс, время передачи 41 мс, всего 155 мс
Имеет смысл, что Corvallis, OR географически ближе к моему местоположению в Беркли, Калифорния, поэтому я ожидаю, что соединение будет немного быстрее ... но я вижу увеличение задержки + 100 мс, когда я выполняю тот же тест для NYC сервер. Это кажется .. чрезмерным для меня. В частности, поскольку время, затраченное на передачу фактических данных, увеличилось только на 10%, а задержка увеличилась на 100%!
Это чувствует себя ... неправильно ... для меня.
Я нашел несколько ссылок, которые были полезны (через Google не меньше!) ...
- Значительно ли влияет расстояние маршрутизации на производительность?
- Как география влияет на задержку в сети?
- Задержка в интернет-соединениях из Европы в США
... но ничего авторитетного.
Так это нормально? Это не чувствует себя нормально. Какую «типичную» задержку я должен ожидать при перемещении сетевых пакетов с восточного побережья на западное побережье США?
источник
Ответы:
Скорость Света:
Вы не собираетесь преодолевать скорость света как интересную академическую точку. Эта ссылка работает из Стэнфорда в Бостон в наилучшее время ~ 40 мс. Когда этот человек сделал расчет, он решил, что интернет работает примерно «в два раза быстрее скорости света», поэтому время передачи составляет около 85 мс.
Размер окна TCP:
Если у вас возникают проблемы со скоростью передачи, вам может потребоваться увеличить размер tcp окна приема. Вам также может понадобиться включить масштабирование окна, если это соединение с высокой пропускной способностью и высокой задержкой (называется «длинная толстая труба»). Поэтому, если вы передаете большой файл, вам нужно иметь достаточно большое окно приема, чтобы заполнить канал, не дожидаясь обновления окна. Я подробно рассказал о том, как рассчитать это в своем ответе « Настройка слона» .
География и латентность.
Недостатком некоторых CDN (сетей распространения контента) является то, что они приравнивают латентность и географию. Google провел много исследований с их сетью и обнаружил в этом недостатки, они опубликовали результаты в официальном документе « Переход от сквозной информации о пути к оптимизированной производительности CDN» :
Одноранговые соединения BGP.
Также, если вы начнете изучать BGP (основной протокол интернет-маршрутизации) и то, как интернет-провайдеры выбирают одноранговые соединения, вы обнаружите, что зачастую это больше касается финансов и политики, поэтому вы не всегда можете найти «лучший» маршрут в определенных географических точках в зависимости от географического местоположения. на вашем провайдере. Вы можете посмотреть, как ваш IP подключен к другим провайдерам (автономным системам) с помощью маршрутизатора с зеркалом . Вы также можете воспользоваться специальным сервисом whois :
Также интересно исследовать их как пиринги с помощью графического инструмента, такого как linkrank , он дает вам представление об интернете вокруг вас.
источник
На этом сайте можно предположить, что латентность между восточным / западным побережьем США составляет около 70-80 мс (например, от Сан-Франциско до Нью-Йорка).
Вот мое время (я в Лондоне, Англия, поэтому мое время на Западном побережье выше, чем на Востоке). Я получаю разницу в 74 мс, которая, кажется, поддерживает значение этого сайта.
Они были измерены с помощью инструментов разработчика Google Chrome.
источник
71 msна нем, так что вы правы - мы не можем ожидать, что будет лучше, чем это.Измерьте сначала с помощью ICMP, если это вообще возможно. Тесты ICMP обычно используют очень маленькую полезную нагрузку по умолчанию, не используют трехстороннее рукопожатие и не должны взаимодействовать с другим приложением в стеке, как это делает HTTP. В любом случае, крайне важно, чтобы результаты HTTP не смешивались с результатами ICMP. Это яблоки и апельсины.
Исходя из ответа Рича Адамса и использования сайта, который он рекомендовал, вы можете видеть, что для магистрали AT & T требуется 72 мсек, чтобы трафик ICMP перемещался между конечными точками SF и NY. Это справедливое число, но вы должны помнить, что это сеть, которая полностью контролируется AT & T. При этом не учитывается переход к домашней или офисной сети.
Если вы выполните пинг против careers.stackoverflow.com из исходной сети, вы должны увидеть что-то не слишком далеко за 72 мс (возможно, +/- 20 мс). Если это так, то вы, вероятно, можете предположить, что сетевой путь между вами обоими в порядке и работает в нормальных диапазонах. Если нет, не паникуйте и измеряйте из нескольких других мест. Это может быть ваш провайдер.
Предполагая, что это пройдено, ваш следующий шаг - заняться прикладным уровнем и определить, есть ли что-то не так с дополнительными издержками, которые вы видите с вашими HTTP-запросами. Это может варьироваться от приложения к приложению из-за аппаратного обеспечения, ОС и стека приложений, но поскольку у вас есть примерно одинаковое оборудование как на восточном, так и на западном побережьях, пользователи Восточного побережья могут получить доступ к серверам Западного побережья, а пользователи западного побережья - Восточный. побережье. Если оба сайта настроены должным образом, я ожидаю, что все числа будут более менее равными, и поэтому продемонстрирую, что то, что вы видите, в значительной степени соответствует грубому.
Если бы эти времена HTTP имели большую разницу, я не удивился бы, если бы была проблема с конфигурацией на медленном сайте.
Теперь, когда вы находитесь в этой точке, вы можете попытаться провести более агрессивную оптимизацию на стороне приложения, чтобы увидеть, можно ли вообще уменьшить эти цифры. Например, если вы используете IIS 7, используете ли вы его возможности кэширования и т. Д.? Может быть, вы могли бы что-то выиграть, а может и нет Когда дело доходит до настройки низкоуровневых элементов, таких как окна TCP, я очень скептически отношусь к тому, что это сильно повлияет на что-то вроде переполнения стека. Но эй - ты не узнаешь, пока не попробуешь и не измеришь.
источник
Некоторые из ответов здесь используют ping и traceroute для своих объяснений. Эти инструменты имеют свое место, но они не надежны для измерения производительности сети.
В частности, (по крайней мере, некоторые) маршрутизаторы Juniper отправляют обработку событий ICMP в плоскость управления маршрутизатора. Это НАМНОГО медленнее, чем плоскость пересылки, особенно в магистральном маршрутизаторе.
Существуют другие обстоятельства, когда ответ ICMP может быть намного медленнее, чем фактическая производительность пересылки маршрутизатора. Например, представьте себе полностью программный маршрутизатор (без специального оборудования для пересылки), который загружен на 99% процессорной мощности, но по-прежнему нормально обрабатывает трафик. Вы хотите потратить много циклов на обработку ответов traceroute или пересылку трафика? Таким образом, обработка ответа является супер низким приоритетом.
В результате ping / traceroute дают вам разумные верхние границы - дела идут, по крайней мере, так быстро, - но они на самом деле не говорят вам, как быстро идет реальный трафик.
В любом случае -
Вот пример трассировки из Мичиганского университета (центральная часть США) в Стэнфорд (западное побережье США). (Это происходит из Вашингтона, округ Колумбия (восточное побережье США), которое находится в 500 милях в «неправильном» направлении.)
В частности, обратите внимание на разницу во времени между результатами traceroute для маршрутизатора стирки и маршрутизатора atla (переходы 7 и 8). сетевой путь идет сначала, чтобы вымыть и затем к атле. для ответа требуется 50-100 мс, для атла - около 28 мс. Очевидно, что атла находится еще дальше, но результаты ее трассировки показывают, что она ближе.
Смотрите http://www.internet2.edu/performance/ для большого количества информации об измерении сети. (Отказ от ответственности, я работал на интернет2). Также смотрите: https://fasterdata.es.net/
Чтобы добавить определенную релевантность к исходному вопросу ... Как вы можете видеть, у меня было 83 мс времени пинга в Стэнфорд, поэтому мы знаем, что сеть может работать по крайней мере так быстро.
Обратите внимание, что путь к научно-образовательной сети, который я выбрал для этой трассировки, скорее всего, будет быстрее, чем обычная интернет-связь. Сети R & E обычно обеспечивают избыточное количество соединений, что делает буферизацию в каждом маршрутизаторе маловероятной. Также обратите внимание на длинный физический путь, более длинный, чем от побережья к побережью, хотя он явно отражает реальный трафик.
Мичиган-> Вашингтон, округ Колумбия, Атланта-> Хьюстон, Лос-Анджелес, Стэнфорд
источник
Я вижу постоянные различия, и я сижу в Норвегии:
Это было измерено с помощью научного точного и проверенного метода использования представления ресурсов Google Chrome и повторного обновления каждой ссылки.
Трассировка на сервер
Проследить к карьере
К сожалению, теперь он начинает входить в цикл или еще много чего и продолжает давать звезды и время ожидания до 30 прыжков, а затем заканчивается.
Обратите внимание, что трассировки от другого хоста, отличного от времени на старте, я должен был выполнить RDP к моему размещенному серверу, чтобы выполнить их
источник
Я вижу задержку около 80-90 мс на хорошо управляемых, хорошо измеренных связях между восточным и западным побережьем.
Было бы интересно увидеть, где вы получаете задержку - попробуйте такой инструмент, как traceroute уровня 4 (lft). Скорее всего, многое получено на «последней миле» (т. Е. У вашего местного широкополосного провайдера).
Следует ожидать, что на время передачи было оказано лишь незначительное влияние - потеря пакетов и дрожание являются более полезными измерениями, которые следует учитывать при исследовании различий во времени передачи между двумя местоположениями.
источник
Просто для удовольствия, когда я играл в онлайн-игру Lineage 2 NA, выпущенную из Европы:
Разница, кажется, подтверждает, что до 100 мс в пределах разумного, учитывая непредсказуемую природу интернета.
Используя известный тест обновления Chrome, я получаю время загрузки документа, которое отличается примерно на 130 мс.
источник
у всех здесь есть кое-что действительно хорошее. и правы в своем собственном POV.
И все это сводится к тому, что здесь нет точного точного ответа, потому что существует так много переменных, что любой ответ всегда можно доказать неверным, просто изменив одну из ста переменных.
Как и задержки в 72 мс от NY до SF, это задержка от PoP до PoP несущей пакета. Это не учитывает любые другие замечательные моменты, которые некоторые здесь указывали о перегрузке, потере пакетов, качестве обслуживания, неупорядоченных пакетах, размере пакета или перенаправлении сети между идеальным миром PoP к PoP. ,
И затем, когда вы прибавляете в последней миле (как правило, много миль) от PoP к вашему фактическому местоположению в двух городах, где все эти переменные становятся гораздо более плавными, вещи начинают экспоненциально расти из разумной способности угадывать!
В качестве примера я провел тест между городом Нью-Йорк и SF в течение рабочего дня. Я сделал это в день, когда не было крупных «инцидентов», происходящих по всему миру, которые могли бы вызвать всплеск трафика. Так что, возможно, это не было средним в сегодняшнем мире! Но тем не менее это был мой тест. Я фактически измерял от одного местоположения бизнеса до другого за этот период и в течение нормальных рабочих часов каждого побережья.
В то же время я следил за номерами провайдеров каналов в сети.
В результате были получены значения задержек от 88 до 100 мс от двери до двери в офисах. Это не включало какие-либо номера задержки между офисами сети.
Задержка в сетях поставщика услуг варьировалась от 70 до 80 мс. Это означает, что время ожидания последней мили могло составлять от 18 до 30 мс. Я не коррелировал точные пики и минимумы между двумя средами.
источник
Нью-Йорк Таймс:
Используя Chrome, на жилой связи.
Использование lft из VPS в датацентре в Ньюарке, штат Нью-Джерси:
источник