Моят уебсайт е статичен блог на визуализации и аз го обслужвам чрез AWS S3.

Някои от визуализациите използват големи CSV файлове, вариращи от 1 мегабайта до 20 мегабайта.

Настроил съм Cloudfront автоматично да gzip файлове, но по някаква причина има максимален размер от 10 мегабайта.

В резултат на това страницата, която зависи от 20 мегабайт CSV, отнема около 5 секунди, за да се зареди, защото Cloudfront не я gzipping.

Проверих и ако този файл е gzip, той ще бъде само около 2 мегабайта.

Има ли някаква причина Cloudfront да не gzip файлове над 10 мегабайта, или има някакво заобиколно решение, което мога да използвам за автоматично обслужване на компресирана версия на този файл без твърде много неприятности?

  • какъв е вашият първоначален сървър?
  • @LMartin: това е просто кофа S3, така че каквото и да използва Amazon, предполагам
  • Това ограничение може ли да се променя от Поддръжка на AWS? Някой опитвал ли се е да се свърже с тях по този въпрос?

Това е ограничение на дизайна:

Размерът на файла трябва да бъде между 1 000 и 10 000 000 байта.

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ServingCompressedFiles.html

Компресирането на файлове изисква много ресурси, така че дизайнерите на CloudFront поставиха горната граница на размера на файловете, които CloudFront ще похарчи ресурси за компресиране в движение.

Няма "автоматично" решение.

Ако вашите файлове са толкова големи и сгъваеми, вероятно е във ваш интерес да ги съхранявате компресирани в S3, за да намалите разходите си за съхранение.

Gzip файловете с gzip -9 (което всъщност може да доведе до малко по-малки файлове от генерираните от CloudFront - gzip има различни нива на компресия, с -9 като най-агресивното и нивото, използвано от CloudFront, изглежда не е документирано), след това премахнете .gz разширение и качете файловете в S3, настройка Content-Encoding: gzip в метаданните за качване.

  • Имайте предвид, че при файл, компресиран директно в S3, некомпресираната версия на филла няма да бъде налична (ако клиентът не поддържа gzip (необичайно в наши дни) или ако използвате curl без никакви параметри). CloudFront няма да декомпресира файла в движение.
  • @YvesM. това е валидна точка. Агонизирах над него преди няколко години, когато създадох система, която съхранява почти всичко в S3 gzipped, но освен поведението по подразбиране на curl да не декомпресира полезния товар, освен ако не посочите --compressed, тази настройка никога не ми е създавала проблеми „в дивата природа“. Правя това дори за файлове като .xlsx, които се възползват много малко от gzipping, защото над стотици хиляди файлове, дори няколко байта, запазени в хранилището и изтеглянията, изглеждат победители.
  • Творческото ми решение би било Lambda @ Edge, ако това беше проблем - можете да пренапишете пътя, преди да изпратите заявката до произхода, за да можете теоретично да промените /foo да се /uncompressed/foo за заявки, в които липсва Accept-Encoding: gzip заглавка и обслужва некомпресираната версия и т.н. (съхраняване на двете версии на различни пътища). Lambda @ Edge също може да се използва за компресиране в движение, но само вие знаете, че gzipped версията е гарантирано <1MB, което е горната граница за "генерирани" отговори и това определено би добавило известно забавяне.

Моят уебсайт е статичен блог

Тъй като вашият сайт е статичен, той е отличен кандидат за s3_website, който автоматично ще gzip файлове локално преди качване, а също така ще се справи с настройката на типа на съдържанието и обезсилване на кеша в CloudFront. След като го настроите, това е „безпроблемно“ и горещо го препоръчвам. Освен това е безплатен и с отворен код.

За да го стартирате, трябва да сте инсталирали Ruby и Java.

За да започнете, ето примерен конфигурационен файл s3_website.yml който използвам за сегмент S3 + доставен статичен сайт в Cloudfront, който се обслужва чрез HTTPS с активиран HTTP / 2:

# S3 Credentials s3_id:  s3_secret:  # Site URL s3_bucket: www.example.com # Config options s3_endpoint: eu-west-1 index_document: index.html cache_control: 'assets/*': public, no-transform, max-age=1209600, s-maxage=1209600 '*': no-cache, no-store gzip: - .html - .css - .js - .ico - .svg # CloudFront cloudfront_distribution_id: AABBCC123456 cloudfront_wildcard_invalidation: true cloudfront_invalidate_root: true cloudfront_distribution_config: default_cache_behavior: min_ttl: <%= 60 * 60 * 24 %> http_version: http2 
  • За съжаление s3_website не работи с AWS GovCloud. Това е, което опитах първо.
  • Ааа, това е жалко. Трябва да помислите да добавите това към въпроса, тъй като има много потребители на GovCloud. И може би може да се приложи поправка, ако подадете доклад за грешка за s3_website на GitHub? (това предполага, че това е грешка и не е блокирано умишлено от AWS, което може да се случва)

е работил за вас: Charles Robertson | Искате ли да се свържете с нас?