Скорость загрузки CloudFront в Европе: ожидаемая и отчетная
Как пользователь в Европе, какую скорость загрузки мне следует ожидать от сервиса на платформе AWS/CloudFront? В какой момент я должен сообщить о медлительности и кому?
Для WeTransfer из примерной ссылки я получаю примерный URL-адрес загрузки (находится в сетевой консоли, F12). Я тогда использую iftop чтобы увидеть, какой хост обслуживает файл для меня и mtr чтобы увидеть, если какая-либо очевидная проблема выделяется (хотя трассировка от их хоста к моей машине может отличаться от других способов).
Вчера файл был доставлен из мадридского края CloudFront, что-то вроде server-54-192-61-242.mad50.r.cloudfront.net и моя скорость загрузки не превышала 300 КиБ / с, большую часть времени оставаясь на уровне 150-200 КиБ / с. Это ужасно медленно.* Я не сохранил трассировку, но не было очевидной потери пакетов или задержки; Пакеты IIRC прошли через Telia.
Сегодня файл подается с server-54-240-166-250.lhr5.r.cloudfront.net (Лондон) и я получаю 1,1 МБ / с дома, в среднем 13 МБ / с (и 25 МБ / с) на сервере в Северной Европе. Это то, что я ожидаю.
Учитывая, что Amazon/AWS изменил хост со вчерашнего дня, и теперь все работает, кажется, еще более вероятно, что проблема была с ними. Тем не менее, клиент AWS на скорости загрузки медленный говорит, что они ничего не будут делать. Документация CloudFront и форумы AWS не содержат информации о том, как сообщать о проблемах с сетью / маршрутизацией / пирингом. Что делать в таких случаях тогда? Я полагаю, что только клиент AWS может что-то сделать, но только в том случае, если человек, который получает отчет, способен понять работу сети.
Мой маршрут к CloudFront Madrid выглядит примерно так:
10.|-- 62-101-124-129.fastres.net 0.0% 50 4.6 13.8 3.5 101.1 20.3
11.|-- 89.96.200.21 0.0% 50 17.6 16.6 2.6 92.9 22.0
12.|-- mno-b2-link.telia.net 4.0% 50 52.6 26.3 13.1 69.2 13.7
13.|-- mei-b1-link.telia.net 0.0% 50 23.7 30.3 20.4 87.7 11.3
14.|-- bcn-b2-link.telia.net 0.0% 50 47.5 53.7 30.2 92.9 16.4
15.|-- mad-b2-link.telia.net 0.0% 50 62.7 57.7 36.1 102.2 14.4
16.|-- mad-b1-link.telia.net 0.0% 50 37.7 42.1 34.3 59.8 5.6
17.|-- a100-ic-314004-mad-b1.c.telia.net 0.0% 50 70.2 58.5 39.7 87.2 12.5
18.|-- ??? 100.0 50 0.0 0.0 0.0 0.0 0.0
19.|-- ??? 100.0 50 0.0 0.0 0.0 0.0 0.0
20.|-- ??? 100.0 50 0.0 0.0 0.0 0.0 0.0
21.|-- server-54-192-61-242.mad50.r.cloudfront.net 2.0% 50 71.1 83.5 56.4 156.2 19.5
Трассировка маршрута теперь выглядит примерно так:
10.|-- 62-101-124-94.fastres.net 0.0% 50 68.6 79.5 36.1 108.8 15.4
11.|-- 89.96.200.110 0.0% 50 75.9 94.8 46.0 141.8 17.6
12.|-- ??? 100.0 50 0.0 0.0 0.0 0.0 0.0
13.|-- 54.239.4.248 2.0% 50 107.2 112.9 71.6 146.7 18.2
14.|-- 54.239.41.135 0.0% 50 112.8 108.7 72.8 147.6 15.0
15.|-- 178.236.3.22 0.0% 50 115.8 102.3 58.4 127.9 16.9
16.|-- 176.32.106.11 4.0% 50 95.8 103.2 73.7 130.7 14.2
17.|-- 176.32.106.11 40.0% 50 110.6 108.6 80.4 136.1 14.7
18.|-- ??? 100.0 50 0.0 0.0 0.0 0.0 0.0
19.|-- ??? 100.0 50 0.0 0.0 0.0 0.0 0.0
20.|-- server-54-240-166-250.lhr5.r.cloudfront.net 60.0% 50 88.7 100.0 57.6 131.9 18.0
Как отмечается в первом ответе, очень важно, был ли файл уже кэширован на границе CloudFront или нет. Вот пример пропадания кеша (которому сейчас удается насытить мою пропускную способность):
$ LANG='en' wget -S 'https://download.wetransfer.com/wetransfer-eu1/f7a2031249f56fdeeda9040adda5a26f20160224143804/wetransfer-f7a203.zip?expiration=1456605646&escaped=false&signature=3d916716d49e415f637b4f824c7709f7483b67a8f02588caece30d6c2a3ed0ea&filename=wetransfer-f7a203.zip'
--2016-02-27 21:34:39-- https://download.wetransfer.com/wetransfer-eu1/f7a2031249f56fdeeda9040adda5a26f20160224143804/wetransfer-f7a203.zip?expiration=1456605646&escaped=false&signature=3d916716d49e415f637b4f824c7709f7483b67a8f02588caece30d6c2a3ed0ea&filename=wetransfer-f7a203.zip
Resolving download.wetransfer.com (download.wetransfer.com)... 54.192.61.62, 54.192.61.196, 54.192.61.80, ...
Connecting to download.wetransfer.com (download.wetransfer.com)|54.192.61.62|:443... connected.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Content-Type: application/octet-stream
Content-Length: 1449534395
Connection: keep-alive
Server: nginx
Date: Sat, 27 Feb 2016 20:34:39 GMT
Content-Transfer-Encoding: binary
Content-Encoding: none
Cache-Control: private, no-transform, no-store
Allow: GET, HEAD
Accept-Ranges: bytes
Content-Disposition: attachment; filename="wetransfer-f7a203.zip"
X-Transfer-Id: f7a2031249f56fdeeda9040adda5a26f20160224143804
X-Cache: Miss from cloudfront
Via: 1.1 943ab292a0096b706fe263560805857e.cloudfront.net (CloudFront)
X-Amz-Cf-Id: 4hEZcZL56GWMBn8z1T2txF-O3TTdrAC6OxCtqVDZUoJREUd9_EBo6A==
Length: 1449534395 (1.3G) [application/octet-stream]
При дальнейшем тестировании я всегда gewt X-Cache: Miss from cloudfront Даже в 6-й раз я запрашиваю тот же ресурс, поэтому кажется, что WeTransfer ничего не кэширует в CloudFront (или нет файлов такого размера). Интересно, что X-Transfer-Id: f7a2031249f56fdeeda9040adda5a26f20160224143804 заголовок всегда один и тот же, хотя фактический URL-адрес загрузки, который я получаю, нажимая кнопку загрузки, меняется; Via а также X-Amz-Cf-Id Заголовки также различаются. Начиная с этого обновления, первый раз, когда я запрашиваю заданный URL-адрес для загрузки, очень быстро, второй - очень медленно, третий - 404. Я попробовал, и у меня может быть две одновременные загрузки, одна со второй попытки и одна с первой попытки: первая будет очень медленной, а вторая очень быстрой, хотя сетевые условия явно одинаковы.
См. https://paste.debian.net/408552/ для теста с моего сервера в Северной Европе: загрузка A* - это один URL, B* - другой; A-2 - после A-1, а B-2 - после B-1, но B * запущен во время работы A-2. Все же A-1 и B-1 были очень быстрыми, A-2 и B-2 очень медленными.
Это все больше похоже на проблему с качеством обслуживания /QoS или сокращением. Может CloudFront задушить меня из-за промахов кеша, или мы должны винить только их клиента?
(*) Примечание: у меня есть соединение FTTH 10/10 Мбит / с с Fastweb. Доступная пропускная способность никогда не идет под этой гарантированной скоростью. Интернет-провайдер, как известно, не применяет регулирование QoS, но иногда имеет некоторые проблемы с маршрутизацией за пределами Италии. Когда я увидел проблему, у меня не было проблем с насыщением полосы пропускания другими службами.
1 ответ
Если вы не являетесь представителем учетной записи AWS, владеющей дистрибутивом CloudFront, - и из фразы, использованной в вопросе, создается впечатление, что это не так, - тогда вашим подходящим контактным лицом является веб-сайт, на котором вы испытываете трудности. спектакль.
В этом случае они будут обязаны открыть службу поддержки с поддержкой AWS, если они сочтут это целесообразным, поскольку они являются клиентом CloudFront.
CloudFront предназначен для направления вашего запроса в самое оптимальное пограничное местоположение CloudFront (где "оптимальное" часто, но не всегда означает географически близкое) в пределах ценового уровня, выбранного владельцем дистрибутива (владельцы могут не платить за более дорогие ребра, где Amazon затраты выше, и в этом случае запросы на этот сайт позволят избежать этих ограничений или, по крайней мере, избежать премиальных цен, хотя CloudFront может, по их выбору, использовать более дорогое местоположение, но выставлять счета по более низкой ставке).
Оптимальный фронт для определенного местоположения загрузчика будет сдвигаться со временем из-за множества факторов, включая задержку, перегрузку, размеры прыжков и пути AS, полосу пропускания канала и любое количество других факторов... которые не являются общедоступной информацией, но учитываются алгоритмами маршрутизации CloudFront, которые определяют, какой ответ DNS вы получите, когда подключаетесь к сайту с поддержкой CloudFront. Ответ DNS зависит от IP-адреса запрашивающего клиента.
С одного исходного IP-адреса в Южном Огайо (США) я вижу маршрут моего испытательного сайта CloudFront через периферийное местоположение, которое меняется между Саут-Бенд (IN, США), Чикаго (Иллинойс, США) и Ашберном (VA, США) на довольно регулярно - без фактического IP-адреса я запрашиваю, чтобы страница даже не менялась. Из аналогичной установки, расположенной на расстоянии менее 5 миль, но с другим статическим IP-адресом источника, использующим другого провайдера, я получаю одинаково разные, но часто разные ответы.
Это легче всего объяснить с помощью алгоритмов CloudFront, которые пытаются выбрать наиболее подходящее ребро, основываясь на факторах, которые не очевидны извне.
Насколько вы знаете, ваше медленное поведение на вчерашних подключениях к CloudFront могло быть обнаружено и вызвало алгоритм выбора, чтобы выбрать другую стратегию, что привело к тому, что проблема с производительностью "исправилась". Также возможно, что Мадридский край использовался как неоптимальный выбор из-за проблем доступности в лучшем местоположении.
Также могла быть проблема между CloudFront и исходным сервером. Заголовки ответа от CloudFront дадут вам немного больше информации... Если X-Cache: Hit from Cloudfront присутствует, вы обслуживаетесь из пограничного кэша, а Age: В заголовке будет указано, как долго объект кэшируется на границе. Если X-Cache: Miss from Cloudfront, тогда ваша загрузка не была кэширована по краю, и файл, который вы получаете в настоящее время, извлекается с исходного сервера и одновременно помещается в кэш и передается обратно вам. Разрешение этой загрузки полностью завершиться, а затем повторная загрузка с идентичным запросом должна получить кешированную копию, при условии, что ваш следующий запрос достигнет того же края, а разница в скорости, если она есть, приблизительно указывает на скорость соединения с исходным сервером., CloudFront - это сквозной CDN; объекты не реплицируются по краям, они хранятся только в тех местах, где они были запрошены, после первоначального запроса.
Как клиент CloudFront, у меня никогда не было необходимости сообщать о медленных загрузках. Это не значит, что он идеален, но сервис, похоже, очень надежно спроектирован для обеспечения производительности и отказоустойчивости.