Tingkatkan rasio cache hit CDN - CDN - Alibaba Cloud - CDN

Rasio hit cache yang rendah meningkatkan beban server origin, menaikkan biaya bandwidth, dan memperlambat pengiriman konten. Dalam tutorial ini, Anda akan mempelajari cara mendiagnosis penyebab rasio hit cache yang rendah serta menerapkan strategi optimalisasi yang sesuai melalui Konsol Alibaba Cloud CDN. Di akhir tutorial, Anda akan memiliki pendekatan sistematis untuk memaksimalkan kinerja cache pada nama domain yang dipercepat Anda.

Prasyarat

Sebelum memulai, pastikan Anda telah:

Menambahkan dan mengaktifkan setidaknya satu nama domain yang dipercepat di Konsol CDN.
Memiliki izin untuk mengelola konfigurasi domain CDN, seperti kebijakan AliyunCDNFullAccess.
Memiliki akses ke konfigurasi server origin jika perlu memodifikasi header respons.

Informasi latar belakang

Alibaba Cloud CDN menyimpan cache konten pada node edge yang disebut points of presence (POPs). Saat klien meminta resource yang telah di-cache, POP langsung melayani permintaan tersebut tanpa menghubungi server origin. Hal ini mengurangi waktu respons dan beban origin. Rasio hit cache yang rendah berarti lebih banyak permintaan mencapai origin, sehingga meningkatkan latensi dan biaya.

CDN menyediakan dua metrik rasio hit cache:

Rasio hit byte mengukur proporsi data yang dilayani dari cache. Rasio hit byte yang lebih tinggi berarti lebih banyak data berasal dari POP daripada dari origin.
Rasio hit byte = (Traffic yang dilayani oleh POP L1 – Back-to-origin traffic) / Traffic yang dilayani oleh POP L1
Catatan
Rasio hit byte yang lebih rendah berarti lebih banyak back-to-origin traffic, yang meningkatkan biaya bandwidth dan beban origin. Oleh karena itu, rasio hit byte merupakan metrik utama yang harus dipantau untuk kinerja cache.
Rasio hit permintaan mengukur proporsi permintaan yang dilayani dari cache, terlepas dari ukuran file.
Rasio hit permintaan = Permintaan dengan cache hit / Total permintaan ke CDN
Catatan
Dalam sebagian besar skenario—terutama ketika range-based origin fetch diaktifkan untuk file besar—gunakan rasio hit byte sebagai metrik utama. Rasio hit permintaan berguna untuk memahami berapa banyak permintaan yang dilayani dari cache tanpa mempertimbangkan ukuran file.

Lihat rasio hit cache

Metode 1: Gunakan Konsol (disarankan)

Gunakan Konsol untuk pemeriksaan cepat dan sekali jalan terhadap rasio hit cache Anda. Konsol CDN menampilkan rasio hit byte melalui dua fitur pemantauan:

Pemantauan Resource — Lihat tren rasio hit cache dalam periode yang lebih panjang, seperti 30 hari. Data tersedia dengan granularitas 5 menit dan mengalami penundaan sekitar 15 menit. Untuk informasi selengkapnya, lihat Pemantauan Resource.
Pemantauan Real-time — Lihat rasio hit cache secara real-time dalam periode yang lebih singkat, seperti 1 jam. Data tersedia dengan granularitas 1 menit dan mengalami penundaan sekitar 3 menit. Untuk informasi selengkapnya, lihat Pemantauan Real-time.

Metode 2: Panggil operasi API

Gunakan operasi API jika Anda perlu mengintegrasikan pemantauan hit cache ke dalam dasbor, skrip, atau sistem peringatan otomatis.

Operasi API	Deskripsi
DescribeDomainHitRateData	Mengambil data rasio hit byte untuk domain yang dipercepat. Granularitas standar (5 menit atau per jam). Kueri data dari 90 hari terakhir.
DescribeDomainReqHitRateData	Mengambil data rasio hit permintaan untuk domain yang dipercepat. Granularitas standar (5 menit atau per jam). Kueri data dari 90 hari terakhir.
DescribeDomainRealTimeByteHitRateData	Mengambil data rasio hit byte real-time dengan granularitas 1 menit untuk domain yang dipercepat. Kueri data dari 7 hari terakhir.
DescribeDomainRealTimeReqHitRateData	Mengambil data rasio hit permintaan real-time dengan granularitas 1 menit untuk domain yang dipercepat. Kueri data dari 7 hari terakhir.
DescribeCdnDomainLogs	Mengambil URL unduhan log untuk domain yang dipercepat. Kueri log dari 90 hari terakhir.

Tingkatkan rasio hit cache

Mulailah dengan memeriksa log CDN Anda untuk mengidentifikasi penyebab paling umum cache miss pada domain Anda. Kemudian terapkan strategi yang sesuai dari tabel berikut.

Strategi	Faktor dan Skenario	Metode Konfigurasi
Pra-ambil resource populer	Faktor: Sebelum acara berskala besar atau rilis versi baru, resource yang belum di-cache pada POP memicu pengambilan asal, sehingga menurunkan rasio hit cache. Skenario: Untuk acara promosi, panaskan terlebih dahulu resource statis halaman acara ke POP sebelum acara dimulai. Untuk rilis aplikasi, panaskan paket instalasi sebelum peluncuran agar permintaan unduhan dilayani dari POP.	Gunakan fitur prefetch untuk memanaskan resource ke POP. Untuk informasi selengkapnya, lihat Quick start.
Konfigurasikan periode kedaluwarsa cache yang sesuai	Faktor: Tidak ada kebijakan cache yang dikonfigurasi pada CDN, atau TTL yang dikonfigurasi terlalu singkat. Semua permintaan pengguna mencapai origin, atau resource yang di-cache sering kedaluwarsa. Skenario: Anda menerbitkan konten statis pada origin, tetapi POP tidak menyimpannya dalam cache, atau konten yang di-cache cepat kedaluwarsa. Panduan: Untuk file statis yang jarang diperbarui (gambar, unduhan aplikasi), atur TTL menjadi satu bulan atau lebih lama. Untuk file statis yang sering diperbarui (JS, CSS), atur TTL berdasarkan kebutuhan bisnis Anda. Untuk file dinamis (PHP, JSP, ASP), atur TTL menjadi 0 detik untuk menonaktifkan caching. Catatan: Mengatur TTL yang panjang dapat menyajikan konten usang. Gunakan pengendalian versi file (seperti menambahkan nomor versi ke nama file) atau purge cache setelah memperbarui konten.	Konfigurasikan kedaluwarsa cache CDN
Abaikan parameter URL dalam kunci cache	Faktor: URL dengan parameter kueri berbeda yang mengarah ke resource yang sama memicu entri cache terpisah dan pengambilan asal. Skenario: Anda ingin URL berbeda dengan parameter berbeda (seperti ID pelacakan atau timestamp) mengakses resource cache yang sama.	Ignore Parameters
Konfigurasikan range-based origin fetch untuk file besar	Faktor: Saat pengguna hanya mengunduh sebagian file besar (seperti installer atau video), POP mengambil seluruh file dari origin tanpa range-based origin fetch. POP mengunduh lebih banyak data dari origin daripada yang dilayani ke pengguna, sehingga menurunkan rasio hit byte. Skenario: Pengguna mengunduh paket instalasi aplikasi atau konten video streaming.	Konfigurasikan range origin fetch
Tangani header no-cache dari origin	Faktor: Server origin mengembalikan header respons no-cache (seperti `Cache-Control: max-age=0`, `Cache-Control: no-cache`, atau `Cache-Control: private`), sehingga mencegah CDN menyimpan resource dalam cache. Semua permintaan diteruskan ke origin. Skenario: Server origin mengirim `Cache-Control: max-age=0` atau `Cache-Control: no-cache` untuk file statis (gambar, JS, CSS), sehingga mencegah POP menyimpan resource tersebut dalam cache.	Metode 1 (disarankan): Modifikasi konfigurasi server origin untuk menghapus header no-cache dari respons resource statis dan atur durasi cache yang wajar (misalnya, `Cache-Control: max-age=2592000`). Pendekatan ini mengatasi akar masalah di tingkat origin, sehingga CDN menerima arahan caching yang benar. Metode 2: Di Konsol CDN, navigasikan ke Domain Names > klik nama domain target > tab Cache > Cache Expiration Period. Tambahkan aturan cache dan aktifkan Ignore Origin No-Cache Header. Jika diaktifkan, CDN mengabaikan header no-cache dari server origin dan menyimpan resource dalam cache sesuai aturan kedaluwarsa cache yang dikonfigurasi di Konsol CDN. Gunakan Metode 2 hanya jika Anda tidak dapat memodifikasi konfigurasi server origin. Peringatan: Mengabaikan header no-cache dari origin dapat menyebabkan CDN menyimpan dalam cache konten yang sengaja ditandai oleh server origin sebagai non-cacheable, sehingga berpotensi menyajikan file usang. Aktifkan fitur ini hanya jika Anda yakin header no-cache dari server origin salah konfigurasi.
Strategi optimalisasi lainnya	Selain strategi di atas, Alibaba Cloud CDN menyediakan fitur optimalisasi tambahan untuk skenario tertentu: Central 302 redirection: Menjadwalkan permintaan pengguna ke node origin optimal melalui pengalihan 302 dari server dispatch pusat. Edge 302 redirection: Menjadwalkan permintaan pengguna ke origin optimal terdekat melalui pengalihan 302 dari POP edge. Shared cache: Memungkinkan beberapa nama domain yang dipercepat dalam satu Akun Alibaba Cloud berbagi resource cache pada POP. Ketika beberapa nama domain (seperti A.example.com dan B.example.com) memerlukan file JS atau CSS yang sama dan konten origin identik, shared cache memungkinkan domain-domain tersebut berbagi salinan cache tunggal, sehingga meningkatkan rasio hit cache. Saat menambahkan website baru, Anda hanya perlu menyelaraskan jalur resourcenya dengan struktur sumber daya domain yang dipercepat yang sudah ada.	Central 302 redirection, edge 302 redirection, dan agregasi pengambilan asal dikonfigurasi oleh insinyur purnajual Alibaba Cloud. Hubungi dukungan untuk mengaktifkan fitur-fitur ini. Shared cache: Di Konsol CDN, navigasikan ke Domain Names > klik nama domain target > Cache > Shared Cache. Klik Modify, pilih nama domain target dari daftar nama domain yang dipercepat yang sedang aktif di akun Anda (pencarian didukung), lalu konfirmasi. Setelah dikonfigurasi, domain saat ini berbagi cache dengan domain yang dipilih dan digabungkan ke dalam jalur pengambilan asalnya. Untuk menghapus konfigurasi, klik Delete Configuration dan konfirmasi. Catatan: Pastikan domain yang berbagi cache menyajikan konten yang identik. Shared cache dapat mengekspos konten satu domain kepada pengguna domain lain jika jalurnya tumpang tindih.

Catatan

Untuk mengembalikan perubahan konfigurasi cache yang dijelaskan dalam tabel di atas, kembali ke halaman pengaturan yang sama di Konsol CDN dan hapus atau nonaktifkan aturan tersebut.

Lihat status hit cache dalam log

Log permintaan CDN mencatat status hit cache untuk setiap permintaan.

Bidang status cache hit dalam log menunjukkan salah satu nilai berikut:

HIT — Permintaan dilayani dari cache POP.
MISS — Permintaan tidak dilayani dari cache POP dan diambil dari origin.

Catatan

Status hit hanya mencerminkan POP L1. Jika permintaan gagal hit pada POP L1 tetapi berhasil hit pada POP L2, log tetap menampilkan MISS.

Contoh entri log:

[26/Jun/2019:10:38:19 +0800] 192.168.53.146 - 1542 "-" "GET http://example.aliyundoc.com/index.html" 200 191 2830 MISS "Mozilla/5.0 (compatible; AhrefsBot/5.0; +http://example.com/robot/)" "text/html"

Pada contoh ini, status MISS menunjukkan bahwa resource tidak di-cache pada POP L1. Jika log Anda menunjukkan proporsi entri MISS yang tinggi, rujuk strategi pada bagian Tingkatkan rasio hit cache untuk mengidentifikasi dan mengatasi penyebabnya.

Anda juga dapat memanggil operasi API DescribeCdnDomainLogs untuk mengambil URL unduhan log untuk domain yang dipercepat.

Verifikasi optimalisasi

Setelah menerapkan strategi optimalisasi, verifikasi apakah rasio hit cache telah meningkat:

Tunggu propagasi cache. Perubahan konfigurasi cache biasanya berlaku dalam waktu 5 menit. Jika Anda memperpanjang TTL cache, Anda mungkin perlu melakukan purge konten cache lama agar perubahan segera berlaku.
Periksa rasio hit cache. Gunakan fitur Real-time monitoring di Konsol CDN atau panggil DescribeDomainRealTimeByteHitRateData untuk memeriksa rasio hit byte saat ini. Bandingkan hasilnya dengan garis dasar Anda sebelum optimalisasi.
Tinjau log. Periksa entri log terbaru untuk proporsi entri status HIT yang meningkat. CDN yang dioptimalkan dengan baik biasanya mencapai rasio hit byte 80% atau lebih tinggi untuk beban kerja yang didominasi konten statis.