Bagaimana ATS melaksanakan strategi caching untuk meningkatkan daya pemprosesan perkhidmatan dinamik

Mula-mula lihat graf trafik sejurus selepas pelarasan dasar:

Untuk meningkatkan pengalaman pengguna, tingkatkan nisbah penguatan cache, dan pada masa yang sama Untuk mengelakkan pelanggan daripada melaporkan masalah, kami bersusah payah apabila mencipta cache Kami mengasingkan fail besar dan fail kecil, dan memisahkan kandungan dinamik dan kandungan statik pada asasnya boleh disimpan telah disimpan, tetapi hanya kandungan dinamik yang sentiasa disimpan. Menurut strategi sebelumnya, kandungan dinamik diproksikan secara langsung, dengan kemasukan dan keluar 1:1 dan berkeras untuk mencapai nisbah penguatan tertentu Jika tiada diskaun, mari gunakan pisau dalam kandungan dinamik.

Sebelum pergi ke bawah pisau, saya melakukan analisis terlebih dahulu dan melakukan banyak ujian pada kandungan dinamik yang boleh disimpan dan strategi caching ATS, dan saya mendapat banyak manfaat. Strategi caching semasa ATS mematuhi sepenuhnya protokol HTTP dan menggunakan kaedah caching yang paling konservatif, iaitu, hanya maklumat dengan pengepala cache kitaran hayat yang jelas disimpan konfigurasi yang sepadan dalam ats Parameter tidak akan ditulis. Untuk memastikan kualiti, kami terus melangkau kandungan dinamik dengan kuki dan keizinan Sebabnya ialah risikonya terlalu besar. Kategori yang selebihnya boleh dicuba:

1 dan kandungan lain; (kami menganggap bahawa maklumat pengepala tapak web adalah boleh dipercayai)

2. gambar dan maklumat lain.

Untuk kategori pertama, mudah dikendalikan ats mempunyai parameter yang sepadan, cuma bukanya:

proxy.config.http.cache.cache_urls_that_look_dynamic INT 1

Untuk. kategori pertama Kategori 2 adalah perkara teknikal yang perlu ditangani Pertama sekali, syarat yang diperlukan untuk maklumat pengepala dalam talian ialah:

proxy.config.http.cache.required_headersINT 2 Kategori 2 boleh disertakan hanya oleh sekatan, jadi menetapkannya kepada 0 adalah keperluan pertama Selepas menetapkannya, bagaimana untuk memastikan perkhidmatan biasa Sebagai contoh, kod pengesahan tidak mempunyai maklumat pengepala Ia adalah konservatif , tetapi jika kita biarkan, ia pasti akan menimbulkan masalah. Selepas analisis, ats menggunakan masa cache maksimum dan minimum untuk memastikan masa cache kandungan tanpa maklumat pengepala Dua parameter masa adalah seperti berikut:

proxy.config.http.cache.heuristic_min_lifetime INT 3600

proxy.config.http.cache.heuristic_max_lifetime INT 864000

Untuk maklumat pengepala yang terakhir diubah suai, ia dikira oleh faktor penuaan parameter faktor penuaan adalah seperti berikut:

proxy.config. http.cache.heuristic_lm_factor-v 0.1

Jadi saya mendapat idea untuk menyimpan kandungan selepas ia datang, tetapi sebelum setiap spit, biarkan ATS menghantar maklumat pengepala IMS ke tapak asal untuk tanya jika terdapat sebarang perubahan, kerana maklumat pengepala ini hanya Tanya, berapa banyak trafik yang tidak akan diduduki jika tiada perubahan, TCP_REFRESH_HIT akan diludahkan kepada pengguna Walaupun sumbernya dikembalikan, kandungannya masih diludahkan daripada cache. Jika terdapat perubahan, TCP_REFRESH_MISS akan diludahkan kepada pengguna.

Tetapi bagaimana untuk menetapkan parameter? Tiba-tiba saya terfikir bahawa saya boleh menetapkan semua parameter di atas kepada 0, yang secara teorinya mencapai matlamat saya Selepas menyimpannya buat kali pertama, saya mula meminta pengepala IMS kembali ke sumber dari kali kedua, dan segera menemui ujian. persekitaran untuk ujian. Begitu juga, apabila saya teruja, saya segera mengemas kini strategi dalam talian dan memantaunya selama sejam melalui alat graf lalu lintas dikurangkan, tetapi sesuatu yang aneh juga berlaku tsar untuk melihat bahawa kembali ke asal pada saat-saat tertentu masih sama Ia hampir seperti muntah, dan selepas menganalisisnya dengan traffic_logstats -s, saya mendapati bahawa terdapat banyak ERR_CLIENT_ABORT, yang sangat mengerikan pelanggan secara aktif memutuskan sambungan sebelum ia selesai menerima data selepas menyambung. Jika ia kurang, ia adalah perkara biasa, jika lebih, ia akan menjadi masalah ia mula-mula, kemudian melengkungkan sambungan dan memutuskannya dengan serta-merta, mencipta log ralat ini. Kali kedua saya melawat, ternyata TCP_HIT saya memuat turun imej tempatan dan membukanya secara normal, ternyata ATS akan diteruskan untuk memuat turun ke cache apabila menangani masalah ini kerana kualiti nama domain ini adalah buruk, kadangkala saya terus mencari maklumat di Google dan mendapati artikel ini proxy.config.http.background_fill_completed_thresholdFLOAT 0.5

Lalai ditetapkan kepada 0. Parameter ini bermakna pelanggan tiba-tiba memutuskan sambungan dan muat turun akan diteruskan apabila muat turun mencapai peratusan tertentu , jika tidak, ia akan terputus sambungan terlalu banyak berfikir, saya menetapkannya kepada 0.5, melakukan ujian, dan kemudian mengemas kininya dengan serta-merta Trafik menjadi stabil dan daya pengeluaran juga meningkat.

Akhirnya, ia adalah satu kejayaan kecil. Bukannya parameter dalam talian begitu stabil Anda masih perlu menyesuaikan ujian mengikut situasi perniagaan pada masa hadapan, tetapi ini juga merupakan sebahagian daripada keseronokan.

Semua pelarasan adalah baki Pelarasan semasa: 1. Peningkatan IO baca dan tulis cakera 2. Peningkatan beban CPU.

Atas ialah kandungan terperinci Bagaimana ATS melaksanakan strategi caching untuk meningkatkan daya pemprosesan perkhidmatan dinamik. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!