Чи повинен AWS CloudFront * збільшувати * час завантаження для файлів, які нечасто отримують доступ?


9

Я новачок у CDN та експериментую з CloudFront. Я все налаштував і, здається, все працює нормально. Я можу створити статичне зображення на сторінці та отримати доступ до нього за допомогою мого розповсюдження CloudFront. Я використовую нестандартне походження (тобто не відро s3).

Я переживаю, що мені може бути гірше з точки зору продуктивності. У мене є тестова сторінка, яка завантажує ті ж 20 або більше зображень з і без CDN. Дивлячись на мережеву панель у Firebug, перший раз, коли я завантажую цю сторінку, зображення, які завантажуються безпосередньо з початкового сервера, надходять набагато швидше. На наступних завантаженнях сторінки переваги CDN стають очевидними - після 3-5 оновлень CDN працює краще, ніж сервер-джерело.

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

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

Чи можливо, що в моїх налаштуваннях шкодить продуктивності? Або реальністю є те, що CDN буде лише чистим позитивом для вмісту, до якого в даний час доступ в середньому кожні кілька секунд?

(перехресне повідомлення з форуму AWS, тому що мене назавжди зіпсували повороти SO)

ОНОВЛЕННЯ:

Нижче є два хороших відповіді, які варто переглянути, якщо у вас є питання щодо продуктивності CloudFront. Нещодавно я знайшов одне пояснення моєї конкретної проблеми, проте не згадувався. Я залишив TTL за 5 хвилин як нагляд. Оскільки я також використовую нестандартне походження, є додаткова поїздка до авторитетного сервера імен, щоб вирішити це до фактичного домену Amazon CloudFront. Тепер, коли налаштування TTL повернулося на 12 годин, здається, що довгі навантаження трапляються рідше.


Так, можливо, CloudFront повільніше, ніж просто перейти безпосередньо на швидкий сервер, тому що CloudFront - це один із найповільніших CDN там, завдяки тому, як Amazon реалізував його з декількома шарами роздільної здатності DNS тощо. Запустіть деякі орієнтири від diffnet місцеположення по всьому світу, і вирішіть, чи підходить це вам чи ні - використовуйте веб-сторінку.org для тестування.
Jesper M

Відповіді:


5

Cloudfront встановлює заголовок у відповідях на кшталт "X-Cache: Hit from cloudfront" у відповідях. Імовірно, він скаже "Міс", якщо ваш файл не був у кеші вузла, на який ви були спрямовані.

Можливо, що ваші файли просто недостатньо популярні, тому вони витягуються з кеша CloudFront за допомогою більш популярного контенту, хоча 24 години не минули. Можливо також, що перевантаження IO або якась інша обставина всередині певного вузла CloudFront робить доступ повільним. Cloudfront коштує дуже недорого в порівнянні з Akamai або LimeLight. Найгірші показники продуктивності та гарантований рівень обслуговування є двома причинами використання більш дорогих плеєрів.

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


Я оновив питання з іншим потенційним поясненням проблеми, що я бачив, - це те, що я залишив налаштування TTL на низькому рівні 5 хвилин, але при переключенні на 12 годин я не думаю, що я бачу це періодичні випуски парфумів як часто.
Грег

7

Можливо. Однак однією метою CDN є масштабованість. Ви можете очікувати, що CDN виконає те саме, якщо ви кинете 100 відвідувань одночасно або 1 мільйон відвідувань одночасно.

Що стосується Вашого налаштування, я нічого не можу знати з наданою вами інформацією, але я вважаю, що справа в тому, що робить CDN настільки цінним. Якщо ви створюєте сайт, який не отримує багато трафіку, вам може бути краще без CDN. Однак CDN забезпечить легше навантаження на ваш веб-сервер, якщо ви отримаєте багато трафіку, оскільки ви переносите подачу своїх медіа на інший сервер. Останнє, хороший CDN (і Amazon є) користувач розширить свою мережу, щоб обслуговувати ваш вміст із місця, найближчого до запитувача. У багатьох випадках вони можуть обслуговувати вміст з ISP-запитувача, що означає ДУЖЕ швидкий час завантаження.

Сподіваюся, що це допомагає.


Спасибі Джессі - дуже корисно. Точка щодо масштабування добре прийнята. І у нас є достатній трафік для цього, щоб мати велике значення. Я все одно хотів би знати політику кешування. Я знайшов величезну кількість інформації про те, як створити CDN і дуже мало про його характеристики. Мені цікаво, наприклад, чи слід виключати (із CDN) старий вміст, до якого звертаються дуже рідко.
Грег

Грег - я не бачу аргументів для виключення вмісту, окрім, можливо, з фінансових причин. Однак ви можете керувати заголовками кешу вашого об’єкта в Amazon. Ви можете спробувати вивчити це: stackoverflow.com/questions/269840/…
Jesse Bunch

Це дозволить вам вказати заголовки в майбутньому, що втрачає чинність, як і в будь-якому звичайному ЗМІ веб-сайту.
Джессі Бунч

Знову дякую. Це кеш-керування посиланням не відповідає моїй ситуації, оскільки я використовую користувальницький сервер походження, а не s3. Але головне стосується, і у мене в майбутньому встановлено заголовки, що закінчуються. До речі, документи Amazon говорять, що вміст живе в кеші протягом 24 годин, але мої експерименти свідчать про щось інше.
Грег

1

Я неправильно зрозумів? Чи кеш-керування не керує тим, як довго живуть речі в крайових місцях, перш ніж крайові локації перезавантажать їх з S3? Тож, безумовно, вони стосуються вашої ситуації, чи використовуєте ви S3 чи власне походження? Ні?

Amazon FAQ каже: «Питання : Як довго Amazon CloudFront буде тримати мої файли в місцях країв За замовчуванням, якщо немає заголовка управління кеша не встановлено, то кожен край перевіряє розташування для оновленої версії файлу кожного разу , коли він отримує запит більш Через 24 години після того, як попередній раз він перевіряв походження для змін у цьому файлі, це називається "термін придатності". Ви можете встановити цей термін придатності на короткий час, або на скільки часу ви хочете, встановивши заголовки кеш-керування для своїх файлів у вашому походженні. Amazon CloudFront використовує ці заголовки кеш-керування, щоб визначити, наскільки часто потрібно перевіряти походження для оновленої версії цього файлу. Якщо ваші файли не змінюються дуже часто, найкраще встановити тривалий термін дії та застосувати систему версій для управління оновленнями ваших файлів. "

[Я припускаю, що останнє речення означає "жорстка удача, якщо ви встановите його на 50 років, а потім хочете змінити файл".]

Чи не головний сенс використання CDN, що він розміщує статичний вміст? Якщо так, чи допоможе це використовувати значно довший TTL, ніж один день? Практично для всього (усіх зображень та CSS) я використовую Cache-Control = "max-age = 604800, загальнодоступний, повинен повторно підтверджуватися" (тобто 1 тиждень). На мій досвід, файли, безумовно, знадобляться до тижня, щоб змінити, якщо я завантажую нові версії на S3.

Сподіваюсь, це допомагає. [BTW: Що стосується вашої більш загальної точки зору, мені теж цікаво, чи допомагає CDN настільки ефективно, наскільки ви думаєте, що це буде. Я збираюся перенести весь свій сайт (включений CDN) на надшвидкий спеціалізований сервер і зробити кілька тестів, щоб це з’ясувати.]


Ви впевнені, що кеш-контроль впливає на те, як довго зберігається вміст на краю. Однак TTL - це окрема справа. TTL контролює кешування IP-адреси, призначеної доменному імені. Тож незалежно від того, статичний файл кешований на межі чи ні, сервер вперше бачить URL-адресу файлу, яку він повинен знайти, IP-адресу цього домену. З одноденним TTL, ймовірно, що сусідній сервер має цю інформацію в своєму кеш-пам'яті DNS. З 5-хвилинною TTL це набагато менше, і потрібна повна поїздка до мого початкового сервера (не для файлу, а для вирішення URL-адреси) ..
Грег,

Ну добре дякую. Я плутав DNS TTL і кеш-контроль :)
Chris W

1

Причини використовувати CDN - якщо ви очікуєте

  • Статичний вміст - нечасто або контрольоване оновлення
  • Дивилися на весь світ
  • Доступ часто

На наш веб-сайт звертаються нечасто як у вашому випадку, але ми маємо налаштування служби моніторингу, яка запитує наш веб-сайт у всьому світі. Таким чином він зберігає кеш-пам'ять CDN теплим. Я також хотів би поділитися нашим випадком, який є простим і демонструє можливість CDN.

Крім того, ми очікуємо щомісячної плати в розмірі 2,2 $ на відміну від 7 $ за godaddy сервер (який не може обробляти сплески)

Середній час завантаження сторінки

Середній розподіл часу завантаження сторінки

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.