Ваш второй запрос показывает, что объект действительно был кэширован. Я предполагаю, что вы это видите, но вопрос не проясняет.
Cache-Control: max-age указывает только максимальный возраст ваших объектов в Cloudfront Cache в любом конкретном пограничном расположении. Не существует минимального интервала времени, в течение которого ваши объекты гарантированно сохраняются... в конце концов, Cloudfront — это кэш, который по определению нестабилен.
Если объект в периферийном расположении запрашивается нечасто, CloudFront может вытеснить объект — удалить объект до истечения срока его действия — чтобы освободить место для более популярных объектов.
— http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html
Кроме того, не существует концепции Cloudfront в целом, имеющей копию вашего объекта. Кэш каждого периферийного расположения работает независимо от других, поэтому нередко можно увидеть несколько запросов на относительно популярные объекты, поступающие из разных периферийных расположений Cloudfront.
Если вы пытаетесь распределить нагрузку на свой внутренний сервер, может иметь смысл разместить перед ним какой-то кеш, который вы контролируете, например, лак, кальмар, другой nginx или специальное решение, как я Добиваюсь этого в своих системах.
В качестве альтернативы вы можете сохранить каждый результат в S3 после обработки, а затем настроить свой существующий сервер для проверки S3, прежде чем пытаться снова изменить размер объекта.
Тогда почему существует задокументированный минимальный TTL?
На той же странице, указанной выше, вы также найдете это:
Если вы добавляете к своим объектам заголовки Cache-Control или Expires для веб-распространений, вы также можете указать минимальное количество времени, в течение которого CloudFront хранит объект в кеше, прежде чем перенаправить другой запрос в источник.
Я понимаю, почему это, и подсказка, приведенная в комментарии ниже...
Минимальное время (в секундах), в течение которого объект находится в кэше CloudFront, прежде чем CloudFront перенаправит другой запрос в ваш источник, чтобы определить, доступна ли обновленная версия.
... казалось бы, противоречит моему ответу. Однако противоречия нет.
Проще говоря, минимальный ttl устанавливает нижнюю границу для внутренней интерпретации Cache-Control: max-age, переопределяя — внутри Cloudfront — любое меньшее значение, отправленное исходным сервером. Сервер говорит, что кеширует его на 1 день, максимум, но настроенный минимальный ttl составляет 2 дня? Cloudfront забывает о том, что он видел в заголовке max-age, и может не проверять источник снова при последующих запросах в течение следующих 2 дней, а не проверять снова через 1 день.
Природа кеша диктует правильную интерпретацию всей очевидной двусмысленности:
Ваша конфигурация ограничивает время, в течение которого Cloudfront МОЖЕТ обслуживать кэшированные копии объекта, и точку, после которой он НЕ ДОЛЖЕН продолжать возвращать объект из своего кеша. Они не определяют, как долго Cloudfront ДОЛЖЕН поддерживать кэшированную копию, потому что Cloudfront МОЖЕТ вытеснить объект в любое время.
Если вы правильно установите заголовок Cache-Control:, Cloudfront будет рассматривать большее из max-age или вашего минимального TTL как максимальное время, в течение которого вы хотите, чтобы они обслуживали кешированную копию без повторных консультаций с исходным сервером.
По мере увеличения посещаемости вашего сайта это должно стать менее проблемой, поскольку ваши объекты будут более популярными, но, по сути, нет никакого способа обязать Cloudfront поддерживать копию объекта.
person
Michael - sqlbot
schedule
29.10.2014
