Nettstedet mitt er en statisk blogg med visualiseringer, og jeg serverer den via AWS S3.

Noen av visualiseringene bruker store CSV-er, alt fra 1 megabyte til 20 megabyte.

Jeg har satt opp Cloudfront for automatisk gzip-filer, men av en eller annen grunn er det en maksimal størrelse på 10 megabyte.

Som et resultat tar siden som er avhengig av en 20 megabyte CSV rundt 5 sekunder å laste inn fordi Cloudfront ikke gzipper den.

Jeg har sjekket, og hvis denne filen ble gzippet, ville den bare være rundt 2 megabyte.

Er det noen grunn Cloudfront ikke gzip filer over 10 megabyte, eller er det noen form for løsning jeg kan bruke for å automatisk servere en komprimert versjon av denne filen uten for mye bry?

  • hva kjører opprinnelsesserveren din?
  • @LMartin: det er bare en S3-bøtte, så uansett hva Amazon bruker, antar jeg
  • Er denne grensen justerbar av AWS-støtte? Har noen prøvd å kontakte dem om dette problemet?

Dette er en designbegrensning:

Filstørrelsen må være mellom 1 000 og 10 000 000 byte.

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

Komprimering av filer er ressurskrevende, så designerne av CloudFront plasserte en øvre grense for størrelsen på filene som CloudFront vil bruke ressurser på å komprimere on-the-fly.

Det er ikke en "automatisk" løsning.

Hvis filene dine er så store og komprimerbare, er det sannsynligvis i din interesse å lagre dem komprimert i S3 uansett for å redusere lagringskostnadene.

Gzip filene med gzip -9 (som faktisk kan resultere i litt mindre filer enn generert av CloudFront - gzip har varierende nivåer av komprimering, med -9 er det mest aggressive, og nivået som brukes av CloudFront ser ikke ut til å være dokumentert), fjern deretter .gz utvidelse, og last opp filene til S3, innstilling Content-Encoding: gzip i opplastingsmetadataene.

  • Merk at med en fil komprimert direkte i S3, vil ikke den komprimerte versjonen av fille ikke være tilgjengelig (hvis klienten ikke støtter gzip (uvanlig i disse dager), eller hvis du bruker curl uten parametere). CloudFront vil ikke fjerne komprimering av filen i farta.
  • @YvesM. det er et gyldig poeng. Jeg plaget over det for noen år tilbake da jeg satte opp et system som lagret nesten alt i S3 gzippet, men bortsett fra curls standardoppførsel for ikke å dekomprimere nyttelasten med mindre du spesifiserer --compressed, dette oppsettet har aldri forårsaket meg noen problemer "i naturen." Jeg gjør dette selv for filer som .xlsx, som har veldig lite nytte av gzipping fordi over hundretusener av filer, til og med noen få byte som er lagret på lagring og nedlastinger, virker som en vinner.
  • Jeg kreativ løsning ville være Lambda @ Edge, hvis dette var et problem - du kan skrive om banen før du sender forespørselen til opprinnelsen, slik at du teoretisk kan endre /foo til /uncompressed/foo for forespørsler som mangler Accept-Encoding: gzip header og server den ukomprimerte versjonen osv. (lagrer begge versjonene på forskjellige baner). Lambda @ Edge kan også brukes til å komprimere i farta, men bare dere visste at gzipped-versjonen garantert var <1MB, som er den øvre grensen for "genererte" svar, og dette vil definitivt legge til litt ventetid.

Nettstedet mitt er en statisk blogg

Siden nettstedet ditt er statisk, er det en utmerket kandidat for s3_website, som automatisk gzip filer lokalt før opplasting, og vil også håndtere innstilling av innholdstype og cache-ugyldighet på CloudFront. Det er en "no-brainer" når du har satt den opp, og jeg anbefaler det på det sterkeste. Det er også gratis og åpen kildekode.

Du trenger både Ruby og Java installert for å kjøre det.

For å komme i gang er her en eksempelkonfigurasjonsfil s3_website.yml som jeg bruker for en S3 bucket + Cloudfront-levert statisk side som serveres via HTTPS med HTTP / 2 aktivert:

# 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 
  • Dessverre fungerer s3_website ikke med AWS GovCloud. Dette er hva jeg prøvde først.
  • Ahh, det er synd. Du bør vurdere å legge det til spørsmålet, ettersom det er mange GovCloud-brukere der ute. Og kanskje en løsning kan implementeres hvis du arkiverer en feilrapport for s3_website på GitHub? (dette antar at det er en feil og ikke blokkert med vilje av AWS, noe som kan være det som skjer)

fungert for deg: Charles Robertson | Ønsker du å kontakte oss?