Насыщение пропускной способности загрузки абонентской линии DSL уничтожит пропускную способность загрузки. Используйте любые опции QoS, доступные в Ваших инструментах выравнивания нагрузки для установки максимального уровня загрузки в 90% пропускной способности.
Во-первых, цель Cloudfront - служить кэшированный контент - если вы попытаетесь обслуживать некэшированный контент из Cloudfront, это будет медленнее, чем обслуживание его напрямую из S3, почти во всех случаях (что-то вроде потокового контента будет исключением). Подумайте на мгновение, что должно произойти для обслуживания контента из Cloudfront - он должен быть получен с исходного сервера в местоположение, которое географически близко к пользователю, что означает, что для запроса, где Cloudfront должен получить контент с исходного сервера , вы добавляете дополнительную задержку в запрос, и пользователь получает контент медленнее. Только когда контент становится доступным на периферии, последующие запросы выполняются быстрее.
Лучший способ решить эту проблему - изменить имена файлов при обновлении страницы - это заставит Cloudfront извлекать новое содержимое. Опять же, имейте в виду, что Cloudfront обычно используется для мультимедийных файлов (включая изображения) и style / javascript - и не столько для html. По сути, ваш HTML-код будет на S3, а ваши изображения - на Cloudfront - с любыми внесенными вами изменениями вы можете изменить имя файла в Cloudfront (например, file-v1.jpg, file-v2.jpg и т. Д.). Другой распространенный способ - это включение строки запроса с информацией о версии.
Также имейте в виду, что Cloudfront не обслуживает сжатый контент, что может привести к более медленному ответу, чем от обычного сервера (хотя в вашем случае S3 не поддерживает t также идентифицировать браузеры, поддерживающие gzip).
Наконец, если вы хотите, вы можете использовать аннулирование, чтобы заставить Cloudfront отказаться от своей существующей копии и получить новую с исходного сервера. Однако обратите внимание, что Cloudfront предоставляет вам только 1000 бесплатных отмен в месяц, после чего стоимость составляет 0,005 доллара США за одно признание.
Минимальное время, в течение которого Cloudfront сохраняет контент, составляет 1 час , хотя, по умолчанию - 24 часа. Поэтому я бы попытался установить max-age как минимум на 3600. Рассмотрим также заголовок s-maxage (для общего, то есть проксированного контента). Amazon рекомендует это руководство по кэшированию.
Недавно возникла проблема , исправленная несколько дней назад
Не знаю, как CloudFront обрабатывает заголовок, как и у вас, но если вы не укажете заголовки, время обновления объектов по умолчанию составляет 24 часа.
Одна из вещей, которые вы можете сделать для обновления объектов, - это сделать контент недействительным. Перейдите по ссылке ниже для получения дополнительной информации. http://blog.cloudberrylab.com/2010/08/how-to-manage-cloudfront-object.html
Я считаю, что ответы на данный момент, хотя и правильные на тот момент, теперь устарели, поскольку Cloudfront теперь поддерживает минимальный TTL, равный 0, а исходная попытка OP использовать cache-age = 0 теперь должен работать.
Вам нужно будет посмотреть, использовать ли эти другие заголовки для управления кешем, с точки зрения того, будут ли они давать желаемый результат - вам может понадобиться только max-age. Вероятно, вы хотите, чтобы Cloudfront проверил S3, чтобы увидеть, изменился ли файл HTML. Если да, Cloudfront может получить и вернуть новый файл. Если нет, он может обслуживать клиента из существующего кеша (сохраняя пропускную способность S3 и обслуживая клиента быстрее и более локально).
Точка Cloudfront состоит в том, чтобы обслуживать кэшированный контент, да, но теперь это включает контент, который иногда меняется, но можно кэшировать, если не менял.
ps Строки запросов теперь также работают с Cloudfront (если вы настроите «поведение» для соответствующего источника - еще одна новая функция), однако некоторые прокси могут по-прежнему не кэшировать какие-либо файлы со строками запроса.
Руководство разработчика Amazon: Срок действия 1