Minu veebisait on staatiline visualiseeringute ajaveeb ja teenindan seda AWS S3 kaudu.

Mõnes visualiseerimises kasutatakse suuri CSV-sid, ulatudes 1 kuni 20 megabaidini.

Olen seadistanud Cloudfront failide gzipimiseks automaatselt, kuid mingil põhjusel on selle maksimaalne suurus 10 megabaiti.

Seetõttu kulub 20-megabaidisest CSV-st sõltuva lehe laadimiseks umbes 5 sekundit, kuna Cloudfront ei paku seda.

Olen kontrollinud ja kui see fail oleks gzipitud, oleks see ainult umbes 2 megabaiti.

Kas on mingil põhjusel, miks Cloudfront ei paki faile üle 10 megabaidise, või on mingisugust lahendust, mida saaksin kasutada selle faili tihendatud versiooni automaatseks edastamiseks ilma liigse vaevata?

  • mis töötab teie päritoluserver?
  • @LMartin: see on lihtsalt S3 ämber, nii et ma arvan, et mida iganes Amazon kasutab
  • Kas see piir on muudetav AWS-i tugi? Kas keegi on proovinud temaga selles küsimuses ühendust võtta?

See on disaini piirang:

Faili suurus peab olema vahemikus 1 000 kuni 10 000 000 baiti.

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

Failide tihendamine on ressursimahukas, seetõttu seadsid CloudFront'i disainerid ülemise piiri failide suurusele, mida CloudFront kulutab ressursse lennult kokku pakkides.

Ei ole "automaatset" lahendust.

Kui teie failid on nii suured ja tihendatavad, on tõenäoliselt teie huvi salvestada need S3-s tihendatud kujul, et teie salvestuskulusid vähendada.

Gzip failid gzip -9 (mis võib tegelikult põhjustada veidi väiksemaid faile kui CloudFront genereerib - gzip on erineva tihendustasemega koos -9 on kõige agressiivsem ja CloudFront'i kasutatav tase ei näi olevat dokumenteeritud), seejärel eemaldage .gz laiendus ja laadige failid S3-sse üles Content-Encoding: gzip üleslaaditud metaandmetes.

  • Pange tähele, et failiga, mis on tihendatud otse S3-s, pole faili tihendamata versioon saadaval (kui klient ei toeta gzip (tänapäeval ebatavaline) või kui te kasutate curl ilma parameetriteta). CloudFront ei tühista faili käigu pealt.
  • @YvesM. see on kehtiv punkt. Mõni aasta tagasi oli mul selle pärast piin, kui seadistasin süsteemi, mis salvestas peaaegu kõik faili S3 gzip-kujuliselt, kuid kõrvale loki vaikekäitumisest, mille kohaselt ei tohi dekompresseerida kasulikku koormust, kui te ei määra --compressed, see seadistus pole mulle kunagi looduses probleeme tekitanud. Ma teen seda isegi selliste failide jaoks nagu .xlsx, mis saavad gzipimisest väga vähe kasu, sest üle sadade tuhandete failide tundub võitjana isegi mõni talletus- ja allalaadimissalvestatud bait.
  • Minu loominguline lahendus oleks Lambda @ Edge, kui see oleks probleem - te saate tee enne päringu saatmist päritolule ümber kirjutada, nii et teoreetiliselt saaksite seda muuta /foo kuni /uncompressed/foo taotluste puhul, millel puudub Accept-Encoding: gzip päise ja serveerige tihendamata versiooni jne (mõlema versiooni salvestamine erinevatel radadel). Lambda @ Edge'i sai kasutada ka lennult tihendamiseks, kuid ainult teie teadsite, et gzipitud versioon on garanteeritud <1MB, mis on "genereeritud" vastuste ülempiir ja see lisaks kindlasti mõningast latentsust.

Minu veebisait on staatiline ajaveeb

Kuna teie sait on staatiline, on see suurepärane kandidaat s3_website, mis enne failide üleslaadimist failid automaatselt kohapeal gzipib, samuti haldab CloudFrontis sisutüübi ja vahemälu kehtetuks tunnistamist. Kui olete selle seadistanud, pole see enam mõtet ja ma soovitan seda väga. See on ka tasuta ja avatud lähtekoodiga.

Selle käitamiseks on vaja installida nii Ruby kui ka Java.

Alustamiseks on siin konfiguratsioonifaili näidis s3_website.yml mida ma kasutan S3 ämber + Cloudfront'i tarnitud staatilise saidi jaoks, mida serveeritakse HTTPS-i kaudu, kui HTTP / 2 on lubatud:

# 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 
  • Kahjuks ei tööta s3_website AWS GovCloudiga. Seda proovisin kõigepealt.
  • Ahh, sellest on kahju. Peaksite sellele küsimusele lisama, kuna seal on palju GovCloudi kasutajaid. Ja võib-olla saab paranduse rakendada, kui esitate veaaruande s3_website GitHubis? (see eeldab, et see on viga ja AWS pole seda tahtlikult blokeerinud, mis võib juhtuda)

none: Charles Robertson | none