Швидкість завантаження CloudFront в Європі: очікувана порівняно з репортажною

Як користувач в Європі, яку швидкість завантаження я повинен очікувати від служби, що працює на базі AWS / CloudFront? У який момент я повинен повідомити про повільність і кому?

Для WeTransfer з прикладу посилання я переходжу до прикладу URL-адреси для завантаження (знайдено в мережевій консолі, F12). Потім я використовую, iftopщоб побачити, який хост обслуговує файл для мене, і mtrпобачити, чи не виявляється якась очевидна проблема (хоча трасування з їх хосту на мою машину може відрізнятися від іншого).

Вчора файл надходив із Мадридського краю CloudFront , щось подібне server-54-192-61-242.mad50.r.cloudfront.net, і швидкість мого завантаження не перевищувала 300 Кб / с, більшу частину часу залишаючись на рівні 150-200 КіБ / с. Це страшенно повільно. * Я не врятував трасування, але не було очевидних втрат або затримки пакетів; Пакети IIRC пройшли через Телію.

Сьогодні файл подається з server-54-240-166-250.lhr5.r.cloudfront.net(Лондон), і я отримую вдома 1,1 МіБ / с, середній показник - 13 МіБ / с (і пік 25 МіБ / с) на сервері Північної Європи. Це я очікую.

Зважаючи на те, що Amazon / AWS змінив хоста з вчорашнього дня, і зараз все працює, здається, навіть більше ймовірності, що проблема була в них. Однак клієнт AWS у розділі "Швидкість завантаження повільний" говорить, що вони нічого не робитимуть. Документи CloudFront та форуми AWS не мають інформації про те, як повідомляти про проблеми в мережі / маршрутизації / пірінгу. Що робити у таких випадках тоді? Я думаю, що лише клієнт AWS може щось зробити, але тільки якщо особа, яка отримує звіт, може зрозуміти мережу.

Моє переслідування до CloudFront Мадрида виглядає приблизно так:

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

Тепер traceroute є приблизно таким:

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. Однак А-1 і В-1 були дуже швидкими, А-2 і В-2 дуже повільними.

Це все більше схоже на проблему з якістю обслуговування / QoS, так само дроселювання. Чи може CloudFront замовчувати мене з помилками кешу, чи ми повинні звинувачувати лише їх клієнта?

(*) Примітка. У мене FSTTH-з'єднання від 10 Мб / с із Fastweb. Наявна пропускна здатність ніколи не перевищує цю гарантовану швидкість. Як відомо, провайдер не застосовує QoS дроселювання, але іноді виникають проблеми з маршрутизацією за межами Італії. Коли я спостерігав за проблемою, у мене не було проблем із насиченням пропускної здатності іншими службами.

Якщо ви не є представником облікового запису AWS, який належить розповсюдженню CloudFront, - і фразові фрази, які використовуються у запитанні, здаються, ніби ви не є, - ваш відповідний контактний пункт - веб-сайт, де ви відчуваєте себе погано виконання.

Тоді було б їх відповідальність відкрити підтримку інцидент з підтримкою AWS, якщо вони вважатимуть це за доцільне, так як вони клієнти CloudFront в.

CloudFront призначений для перенаправлення вашого запиту до найбільш оптимального місця розташування краю CloudFront (де "оптимальне" часто, але не завжди означає географічне близьке) у межах цінового рівня, обраного власником дистрибуції (власники можуть вирішити не платити за більш дорогі краї, де Amazon витрати вище, і в такому випадку запити на цей сайт дозволять уникнути цих країв або, принаймні, уникнуть преміум-ціни, навіть якщо CloudFront, за їх вибором, може використовувати місце з більш високою вартістю, але виставити рахунок за нижчою ставкою).

Оптимальна грань для певного місця завантаження з часом зміститься через безліч факторів, включаючи затримку, затори, розміри хмелю та AS, розміри пропускної здатності та будь-яку кількість інших факторів ... які не є загальнодоступною інформацією, але враховуються алгоритмами маршрутизації CloudFront, які визначають, яку відповідь DNS ви отримуєте під час підключення до сайту, що працює на CloudFront. Відповідь DNS залежить від IP-адреси клієнта.

Із однієї вихідної IP-адреси в Південному Огайо (США) я бачу маршрут свого тестового веб-сайту CloudFront через крайове місце, яке змінюється між Саутом Бендом (ІН, США), Чикаго (Іллінойс, США) та Ешберном (штат Вашингтон, США) на досить регулярно - без фактичної IP-адреси я прошу сторінку навіть змінити. З аналогічної установки, що знаходиться менш ніж в 5 милях, але з іншою статичною IP-адресою джерела, використовуючи інший провайдер, я отримую подібні зміни, але часто різні відповіді.

Це найпростіше пояснити алгоритмами CloudFront, що намагаються вибрати найбільш відповідний край, виходячи з факторів, які не очевидні ззовні.

З усього, що ви можете знати, ваша повільна поведінка під час підключення до CloudFront вчора, можливо, була виявлена ​​і запустила алгоритм вибору для вибору іншої стратегії, тим самим спричиняючи питання про продуктивність "виправити себе". Можливо також, що край Мадриду використовувався як неоптимальний вибір через проблеми з доступністю при кращому виборі місця.

Можливо, також виникли проблеми між CloudFront та початковим сервером. Заголовки відповідей із CloudFront дали б вам трохи більше інформації ... Якщо X-Cache: Hit from Cloudfrontце є, вам подають з крайового кешу, і Age:заголовок повідомляє про те, як довго об’єкт кешований на краю. ЯкщоX-Cache: Miss from Cloudfront, тоді ваше завантаження не було кешоване на межі, і файл, який ви отримуєте в даний час, виймається з початкового сервера і одночасно ставиться для кешу і передається вам назад. Дозволяючи завантаженню повністю закінчитися, після цього повторне завантаження з однаковим запитом має отримати кешовану копію, якщо припустити, що наступний запит потрапить на той самий край, а різниця швидкостей, якщо така є, приблизно вказує на швидкість з'єднання назад до початкового сервера . CloudFront - це перехідний CDN; Об'єкти не реплікуються до країв, вони зберігаються лише в тих місцях, де вони просили, після початкового запиту.

Як клієнт CloudFront, мені ніколи не було необхідності повідомляти про повільні завантаження. Це не означає, що він ідеальний, але сервіс, здається, дуже надійно розроблений для продуктивності та стійкості.