Můj web je statický blog vizualizací a obsluhuji ho přes AWS S3.

Některé z vizualizací používají velké soubory CSV v rozsahu od 1 megabajtu do 20 megabajtů.

Nastavil jsem Cloudfront tak, aby automaticky gzip soubory, ale z nějakého důvodu je maximální velikost 10 megabajtů.

Výsledkem je, že stránka, která závisí na 20 megabajtovém souboru CSV, se načte přibližně 5 sekund, protože Cloudfront ji nezačal gzipovat.

Zkontroloval jsem to, a pokud byl tento soubor gzipován, pak by to bylo jen kolem 2 megabajtů.

Existuje nějaký důvod, proč Cloudfront soubory gzip nepřesahuje 10 megabajtů, nebo existuje nějaké řešení, které mohu použít k automatickému poskytování komprimované verze tohoto souboru bez přílišných potíží?

  • jaký je váš původní server spuštěný?
  • @LMartin: je to jen kbelík S3, takže předpokládám cokoli, co Amazon používá
  • Je tento limit použitelný Podpora AWS? Pokusil se někdo ohledně tohoto problému kontaktovat?

Toto je konstrukční omezení:

Velikost souboru musí být mezi 1 000 a 10 000 000 bajtů.

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

Komprese souborů je náročná na zdroje, takže návrháři CloudFront umístili horní hranici velikosti souborů, které CloudFront utratí za současnou kompresi zdrojů.

Neexistuje žádné „automatické“ řešení.

Pokud jsou vaše soubory tak velké a komprimovatelné, je pravděpodobně ve vašem zájmu ukládat je komprimované v S3, abyste snížili náklady na úložiště.

Gzip soubory pomocí gzip -9 (což může ve skutečnosti vyústit v o něco menší soubory, než generuje CloudFront - gzip má různé úrovně komprese, s -9 je nejagresivnější a úroveň používaná CloudFrontem se nezdá být zdokumentována), pak odstraňte .gz příponu a nahrajte soubory na S3, nastavení Content-Encoding: gzip v metadatech nahrávání.

  • Všimněte si, že se souborem komprimovaným přímo v S3 nebude k dispozici nekomprimovaná verze souboru (pokud klient nepodporuje gzip (neobvyklé v těchto dnech), nebo pokud používáte curl bez jakýchkoli parametrů). CloudFront nebude průběžně komprimovat soubor.
  • @YvesM. to je platný bod. Před několika lety jsem se nad tím zoufal, když jsem nastavil systém, který ukládal téměř všechno v S3 gzip, ale kromě výchozího chování zvlnění, které nedekomprimovalo užitečné zatížení, pokud neurčíte --compressed, toto nastavení mi nikdy „ve volné přírodě“ nezpůsobilo žádné potíže. Dělám to i pro soubory jako .xlsx, které mají z gzipování jen velmi malý užitek, protože přes stovky tisíc souborů se i několik bajtů uložených na úložišti a stahování jeví jako vítěz.
  • Kreativním řešením by bylo Lambda @ Edge, pokud by to byl problém - před odesláním požadavku do původu můžete cestu přepsat, takže byste mohli teoreticky změnit /foo na /uncompressed/foo pro žádosti, které postrádají Accept-Encoding: gzip záhlaví a obsluhovat nekomprimovanou verzi atd. (ukládání obou verzí na různé cesty). Lambda @ Edge lze také použít ke komprimaci za běhu, ale jen vy jste věděli, že verze gzipped je zaručeně <1 MB, což je horní limit pro „generované“ odpovědi, a to by určitě přidalo nějakou latenci.

Můj web je statický blog

Protože je váš web statický, je skvělým kandidátem s3_website, který před nahráním automaticky lokálně provede gzip soubory a také se postará o nastavení zneplatnění typu obsahu a mezipaměti na CloudFront. Jakmile to nastavíte, je to „ne-nápadné“, a já to velmi doporučuji. Je také zdarma a open-source.

Abyste ji mohli spustit, musíte mít nainstalovanou Ruby i Java.

Pro začátek je zde ukázkový konfigurační soubor s3_website.yml které používám pro kbelík S3 + Cloudfront dodávaný statický web, který je obsluhován přes HTTPS s povoleným 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 
  • Bohužel s3_website nefunguje s AWS GovCloud. To je to, co jsem zkoušel jako první.
  • Aha, to je škoda. Měli byste zvážit přidání toho k otázce, protože existuje mnoho uživatelů GovCloud. A možná lze implementovat opravu, pokud podáte hlášení o chybě pro s3_website na GitHubu? (toto předpokládá, že se jedná o chybu a není úmyslně blokováno AWS, což se možná děje)

Pracoval pro vás: Charles Robertson | Chcete nás kontaktovat?