Haruskah AWS CloudFront * meningkatkan * memuat waktu untuk file yang jarang diakses?


9

Saya baru mengenal CDN dan bereksperimen dengan CloudFront. Saya telah mengatur semuanya dan semua tampak berfungsi dengan baik. Saya dapat membuat gambar statis pada halaman dan mengaksesnya melalui distribusi CloudFront saya. Saya menggunakan asal kustom (yaitu bukan ember s3).

Saya khawatir bahwa saya mungkin akan lebih buruk dari sudut pandang kinerja. Saya memiliki halaman pengujian yang memuat 20 gambar yang sama dengan dan tanpa CDN. Melihat panel net di Firebug, pertama kali saya memuat halaman ini gambar yang dimuat langsung dari server asal datang jauh lebih cepat. Pada halaman berikutnya memuat manfaat CDN menjadi jelas - setelah 3-5 menyegarkan CDN melakukan lebih baik daripada server asal.

Jadi saya bisa melihat bahwa pada halaman populer di situs kami yang sedang dipukul setiap saat, ini akan bermanfaat. Dan saya harus mengharapkan manfaat karena saya di Seattle (sekitar sudut dari Amazon) dan server saya di CA.

Masalahnya adalah bahwa jika saya meninggalkan halaman selama beberapa menit dan kemudian memuat kembali, semuanya kembali ke titik awal, dengan CloudFront lebih buruk daripada server asal. Apakah ini yang diharapkan? Apakah hal-hal keluar dari "cache" CDN begitu cepat?

Mungkinkah ada sesuatu dalam pengaturan saya yang mengganggu kinerja? Atau kenyataan bahwa CDN hanya akan menjadi positif bersih untuk konten yang saat ini diakses setiap beberapa detik?

(cross diposting dari forum AWS karena saya telah dimanjakan selamanya oleh waktu perputaran SO)

MEMPERBARUI:

Ada dua jawaban bagus di bawah ini yang pantas untuk dilihat jika Anda memiliki pertanyaan tentang kinerja CloudFront. Baru-baru ini saya menemukan satu penjelasan untuk masalah spesifik saya yang tidak disebutkan. Saya telah meninggalkan TTL pada 5 menit sebagai pengawasan. Karena saya juga menggunakan asal kustom ada tambahan perjalanan bolak-balik ke server nama otoritatif untuk menyelesaikannya ke domain Amazon CloudFront yang sebenarnya. Sekarang setelah pengaturan TTL kembali ke 12 jam, tampaknya beban panjang jarang terjadi.


Ya, mungkin saja CloudFront lebih lambat daripada hanya langsung menuju ke server yang cepat, karena CloudFront adalah salah satu CDN paling lambat di luar sana, karena cara Amazon menerapkannya dengan beberapa lapis resolusi DNS, dll. Jalankan beberapa tolok ukur dari differnet lokasi di seluruh dunia, dan putuskan apakah itu cocok untuk Anda atau tidak - gunakan webpagetest.org untuk pengujian.
Jesper M

Jawaban:


5

Cloudfront menetapkan header di balasan seperti "X-Cache: Hit from cloudfront" di balasan. Agaknya, ia akan mengatakan "Nona" jika file Anda tidak ada dalam cache node yang Anda tuju.

Mungkin saja file Anda tidak cukup populer, sehingga mereka dikeluarkan dari cache CloudFront oleh konten yang lebih populer walaupun 24 jam belum berlalu. Mungkin juga bahwa kelebihan beban IO atau keadaan lain di dalam simpul CloudFront tertentu membuat akses menjadi lambat. Cloudfront sangat murah dibandingkan dengan Akamai atau LimeLight. Performa terburuk dan tingkat layanan terjamin adalah dua alasan untuk menggunakan pemain yang lebih mahal.

Saya akan melakukan tes, menempatkan hanya satu file populer ke cloudfront dalam produksi, dan kemudian menggunakan tes berkala untuk melihat apakah CloudFront menunjukkan klik (juga mencatat total waktu transaksi).


Saya telah memperbarui pertanyaan dengan penjelasan potensial lain untuk masalah perf yang saya lihat, yaitu bahwa saya telah meninggalkan pengaturan TTL pada pengaturan rendah 5 menit, tetapi ketika beralih kembali ke 12 jam saya tidak berpikir saya melihat ini masalah perf sesekali seperti sering.
Greg

7

Itu mungkin. Namun, salah satu tujuan CDN adalah skalabilitas. Anda dapat mengharapkan CDN melakukan hal yang sama jika Anda melempar 100 kunjungan sekaligus atau 1 juta kunjungan sekaligus.

Sejauh pengaturan Anda berjalan, tidak ada yang bisa saya ketahui dengan informasi yang Anda berikan, tapi saya pikir poin di atas adalah apa yang membuat CDN sangat berharga. Jika Anda membuat situs yang tidak mendapatkan banyak lalu lintas, Anda mungkin lebih baik tanpa CDN. Namun, CDN akan memberikan beban yang lebih ringan di server web Anda jika Anda mendapatkan banyak lalu lintas karena Anda menyerahkan penyajian media Anda ke server lain. Satu poin terakhir, CDN yang bagus (dan Amazon) akan menggunakan jaringan mereka yang luas untuk menyajikan konten Anda dari lokasi terdekat dengan pemohon. Dalam banyak kasus, mereka dapat menyajikan konten dari ISP pemohon, yang berarti waktu pemuatan SANGAT cepat.

Semoga itu bisa membantu.


Terima kasih Jesse - sangat membantu. Poin tentang penskalaan diambil dengan baik. Dan kami memiliki lalu lintas yang cukup untuk membuat perbedaan besar. Saya masih ingin tahu kebijakan caching. Saya telah menemukan sejumlah besar info tentang BAGAIMANA mengatur CDN dan sangat sedikit tentang karakteristiknya. Saya bertanya-tanya, misalnya, apakah saya harus mengecualikan (dari CDN) konten lama yang jarang diakses.
Greg

Greg - Saya tidak melihat argumen untuk mengecualikan konten, selain mungkin karena alasan keuangan. Namun, Anda dapat mengontrol header cache objek Anda di Amazon. Anda dapat mencoba melihat ini: stackoverflow.com/questions/269840/…
Jesse Bunch

Itu akan memungkinkan Anda menentukan tajuk kedaluwarsa yang jauh di masa mendatang seperti halnya dengan media situs web normal mana pun.
Jesse Bunch

Terima kasih lagi. Tautan kontrol-cache itu tidak relevan dengan situasi saya karena saya menggunakan server asal kustom, bukan s3. Tetapi prinsipal berlaku dan saya memiliki masa depan yang jauh header ditetapkan. BTW, dokumen Amazon mengatakan bahwa konten hidup dalam cache selama 24 jam, tetapi percobaan saya menunjukkan sesuatu yang berbeda.
Greg

1

Apakah saya salah paham? Tidakkah kontrol-cache mengatur berapa lama barang hidup di lokasi tepi sebelum lokasi tepi memuatnya dari S3? Jadi pasti mereka relevan dengan situasi Anda apakah Anda menggunakan S3 atau asal Anda sendiri? Tidak?

The Amazon FAQ mengatakan:? "Q. Berapa lama Amazon CloudFront akan menyimpan file-file saya di lokasi tepi Secara default, jika ada header cache control diatur, setiap tepi cek lokasi untuk versi terbaru dari file Anda setiap kali menerima permintaan lebih dari 24 jam setelah waktu sebelumnya memeriksa asal untuk perubahan ke file itu. Ini disebut "periode kedaluwarsa." Anda dapat mengatur periode kedaluwarsa ini sesingkat 1 jam, atau selama yang Anda inginkan, dengan mengatur header kontrol cache pada file Anda di negara asal Anda. Amazon CloudFront menggunakan header kontrol cache ini untuk menentukan seberapa sering perlu untuk memeriksa asal untuk versi terbaru dari file itu. Jika file Anda tidak terlalu sering berubah, itu adalah praktik terbaik untuk mengatur periode kedaluwarsa yang panjang dan menerapkan sistem versi untuk mengelola pembaruan pada file Anda. "

[Saya menganggap kalimat terakhir berarti "keberuntungan jika Anda mengaturnya menjadi 50 tahun dan kemudian ingin mengubah file".]

Bukankah poin utama menggunakan CDN yang menampung konten statis? Jika demikian, apakah akan membantu menggunakan TTL yang jauh lebih lama dari satu hari? Untuk hampir semua (semua gambar dan CSS), saya menggunakan Cache-Control = "max-age = 604800, publik, harus divalidasi ulang" (yaitu 1 minggu). Dalam pengalaman saya, file pasti perlu waktu hingga seminggu untuk berubah jika saya mengunggah versi baru ke S3.

Semoga ini membantu. [BTW: Pada poin Anda yang lebih umum, saya juga bertanya-tanya apakah CDN membantu kinerja sebanyak yang Anda pikir akan terjadi. Saya akan memindahkan seluruh situs saya (termasuk CDN) ke server khusus yang sangat cepat dan melakukan beberapa tes untuk mengetahuinya.]


Anda benar bahwa kontrol cache memengaruhi berapa lama konten disimpan di tepi. TTL adalah masalah yang terpisah. TTL mengontrol caching dari alamat IP yang ditetapkan untuk nama domain. Jadi terlepas dari apakah file statis di-cache di tepi atau tidak, pertama kali server melihat URL file itu harus menemukan alamat IP dari domain ini. Dengan TTL 1 hari, kemungkinan server terdekat memiliki info ini dalam cache DNS-nya. Dengan TTL 5 menit ini jauh lebih kecil kemungkinannya dan diperlukan perjalanan bolak-balik ke server asal saya (bukan untuk file, tetapi untuk menyelesaikan URL) ..
Greg

Ah oke terima kasih. Saya bingung DNS TTL dan kontrol cache :)
Chris W

1

Alasan menggunakan CDN adalah jika Anda mengharapkan

  • Konten statis - pembaruan yang jarang atau terkontrol
  • Dilihat di seluruh dunia
  • Sering diakses

Situs web kami jarang diakses sebagai kasus Anda, tetapi kami memiliki pengaturan layanan pemantauan yang meminta situs web kami di seluruh dunia. Jadi itu membuat cache CDN tetap hangat. Saya juga ingin membagikan kasus kami yang sederhana dan menunjukkan kemampuan CDN.

Lebih jauh lagi kami mengharapkan biaya bulanan $ 2.2 dibandingkan dengan $ 7 untuk server godaddy (yang tidak bisa menangani lonjakan)

Waktu Muat Halaman Rata-Rata

Distribusi Waktu Muat Halaman Rata

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.