Artikel ini, lebih tepatnya, dari serangkaian "catatan nyonya rumah." Nah, sedikit lagi tentang pengalaman pribadi dan mencungkil.
Jika Anda harus berurusan dengan situs WordPress yang memiliki plugin caching WP Super Cache terinstal, maka artikel itu mungkin berguna bagi Anda. Kalau tidak, ini hanya cerita pendek.
Singkatnya, awal cerita adalah ini: ada situs. Berita dan informasi tematik. Dibuat oleh penyihir tidak dikenal di CMS WordPress. Dan dilakukan persis seperti yang diizinkan pada saat itu dengan bantuan pemiliknya. Seiring waktu, situs mendapatkan popularitas, jumlah pengunjung bertambah. Situs itu sendiri "menghasilkan" iklan. Yaitu semakin banyak pengunjung, semakin baik. Di beberapa titik, selama beban puncak, situs mulai berputar: halaman dimuat perlahan dan semua itu. Tapi, tentu saja, sampai ayam itu mematuk, tidak ada yang benar-benar bergerak. Ayam jantan muncul pada saat situs tersebut seharusnya meliput beberapa peristiwa yang menarik perhatian publik. Pengunjung berlari masuk, situs turun, dan semua pendapatan yang diperkirakan mencair di depan mata kami. Karena keadaan, saya harus bertindak sebagai resusitator. Saya menulis
artikel tentang ini. Keputusan saya menyeramkan (jangan ulangi), tetapi tujuan utama tercapai - impian diselamatkan. Kebanyakan.
Tentu saja, tidak ada yang tertarik mengulangi situasi yang sama dan bekerja di situs. Pertama-tama, mereka menemukan alasan jatuh dan beban tinggi di server. Itu adalah hal yang lumrah: kurangnya situs caching seperti itu dan mekanisme yang diimplementasikan dengan buruk untuk merekam dan menampilkan jumlah tampilan artikel. Yang terakhir itu sendiri menciptakan beban yang layak: dengan setiap permintaan untuk halaman artikel, ia mengambil dari database jumlah tampilan artikel ini, menampilkannya, dan kemudian menambahkan satu dan menulisnya kembali ke database. Pada saat yang sama, tabel
wp_postmeta dengan metadata digunakan untuk penyimpanan (seperti yang disebut dalam WP). Di mana massa disimpan sepenuhnya tidak relevan dengan pandangan akuntansi informasi dan yang sangat besar.
Masalah caching diselesaikan dengan sederhana: di lingkungan yang sunyi, plugin WP Super Cache diinstal secara normal. Apa, banyak, jika saya ingat dengan benar, menyarankan saya untuk melakukan alih-alih kruk menakutkan yang saya buat di komentar pada artikel saya itu. Jujur, saya dulu dan sekarang kurang bernavigasi di ekosistem WordPress dan karenanya muncul kruk itu. Plugin caching dipasang dan dikonfigurasikan oleh orang yang sudah tahu, dan langsung keluar dari kotak. Dengan demikian, masalah caching terpecahkan. Mengapa plugin ini dipilih, saya tidak tahu pasti. Sejauh yang saya mengerti, ini adalah salah satu plugin yang paling populer dari jenis ini untuk WP.
Mengingat pandangan, mereka bertindak agak berbeda. Jelas bahwa mekanisme asli harus ditinggalkan. Saya tidak ingin menolak untuk mempertimbangkan pandangan mereka sendiri: setidaknya satu blok yang menunjukkan "artikel paling populer dalam seminggu" terikat dengannya. Semua plugin untuk merekam tampilan, walaupun mereka adalah "teman" dengan plugin caching, ternyata sangat rakus dan, paling sering, menerapkan mekanisme yang sama dengan menulis dan mengekstraksi data dari wp_postmeta. Untuk situs kecil, ini sangat cocok. Untuk situs dengan tingkat kehadiran puncak yang cukup solid - tidak lagi: terlalu rakus untuk fungsi sekecil itu. Kemudian, omong-omong, saya muncul hosting berbayar dan tidak digunakan selama bertahun-tahun yang akan datang. Termudah dan termurah. Tanggung jawab untuk menyimpan, merekam, dan mengembalikan data tentang pandangan ditumpuk padanya. Semuanya asinkron, mis. bahkan jika jatuh, situs utama akan terus menampilkan artikel, iklan, dan segala sesuatu yang harus ditampilkan secara diam-diam. Penyimpanan online untuk melihat data ditugaskan ke Redis, dan penyimpanan jangka panjang ke MySQL. Jadi itu berputar, itu tidak benar-benar bertanya, dan memakan 1-2% dari beban maksimum yang diizinkan di hosting itu.
Maka, waktu yang cukup lama berlalu. Lagi malam dan lagi cerita lama. Lalu lintas yang cukup kuat masuk ke situs dan situs mulai turun. Dan lagi, saya satu-satunya spesialis kondisional yang terjaga di daerah tersebut. Tentu saja, saya terkejut dengan pengulangan acara. Pikiran pertama saya adalah seseorang secara tidak sengaja mematikan caching. Tapi tidak, dalam kode sumber halaman situs yang diberikan server jatuh, saya melihat tanda-tanda plugin caching berfungsi. Semuanya harus baik-baik saja. Tetapi di panel kontrol server, saya melihat bahwa tidak ada RAM yang tersisa, jumlah permintaan basis data luar biasa dan semuanya buruk. Pertama-tama, saya membuka halaman dengan deskripsi plugin, dengan cepat menelusuri matanya, tidak menemukan apa pun dan meninggalkan aktivitas ini. Langkah selanjutnya adalah melihat statistik. Saya melihat bahwa arus lalu lintas utama mengalir ke situs dari Yandex.Zen. Dan permintaan yang mengarahkan pengguna ke situs terlihat seperti ini:
https://example.com ? utm_referrer = https:% 2F% 2Fzen.yandex.com
Yaitu Yandex.Zen menambahkan tag utm ke alamat. Karena server sudah benar-benar berbaring dan memberi saya hanya 500, untuk beberapa alasan saya tidak dapat dengan jelas memverifikasi teori bahwa halaman dengan "pembobotan" tidak di-cache. Oleh karena itu, "penopang" lain lahir (kemudian diganti): pengalihan ditambahkan ke .htaccess, yang mengubah permintaan dengan tag utm menjadi permintaan tanpa mereka sebelum WordPress dan semua plugin yang kuat ikut bermain. Mesin reboot dan, voila, semuanya berfungsi: situs memuat dengan cepat, server diam-diam berdesir pada kecepatan rendah. Karena tidak ada yang terjadi.
Lalu saya santai dan naik dengan tenang menonton pengaturan plugin caching. Pertama-tama, kotak centang "Jangan cache halaman dengan parameter GET", yang ada di sana. Semuanya baik-baik saja, dia tidak layak. Plus, seperti yang diperlihatkan percobaan, plugin mengatasi caching kueri dengan set parameter arbitrer apa pun. Jika ini bukan tag utm (faktanya, saya hanya mengarahkan permintaan dari jenis tertentu dan tidak memotong semua tag utm).
Di sini saya hati-hati (menggunakan CTRL + F) melihat halaman plugin. Dan saya temukan di FAQ, paragraf yang mulia, “Bagaimana saya sebaiknya menggunakan alat pelacak utm_source di Google Analytics dengan plugin ini?”. Jelas bahwa selama pemeriksaan sepintas lalu, saya dengan aman mengabaikannya: sepertinya tidak ada hubungannya dengan masalah tersebut. Pada saat yang sama, omong-omong, ini tidak terlalu informatif dan tidak menawarkan solusi spesifik.
Satu-satunya kesimpulan yang mungkin berguna dalam artikel: jika Anda memiliki situs WP dengan plugin WP Super Cache, maka periksa apa fungsinya (atau tidak), jika Anda mengirim permintaan dengan parameter “? Utm_referrer = https:% 2F% 2Fzen. yandex.com ", dll. Saya tidak yakin ketika menginstal plugin ini, semua orang membaca FAQ-nya dengan sangat hati-hati. Implementasi spesifik, tampaknya, tetap dengan pemilik situs: ketika saya terakhir melihat pembaruan plugin ini, saya tidak melihat perubahan apa pun mengenai reaksi anehnya terhadap tag utm.
Tetapi kisah itu tidak akan lengkap (dan saya tidak akan mengatakannya) jika tidak ada konfirmasi lain dari hukum Murphy. Sementara kami berkorespondensi secara damai dengan pemilik situs dan menyaksikan bagaimana situs tersebut bekerja dengan tenang selama sekitar satu jam ... situs tersebut jatuh. Tanpa diduga dan akhirnya. Tidak ada akses ke panel kontrol server, FTP, SSH dan yang lainnya tidak berfungsi. Tidak ada yang berhasil. Jika sebelum itu tekanan saya hanya sedikit meningkat dengan memecahkan masalah yang dilontarkan J. Zen dan plugin caching (setelah semua, itu adalah kesenangan khusus untuk dengan cepat memahami dan memperbaiki sesuatu dengan mudah), maka seluruh serangan panik mini terjadi pada saya. Dan hanya perasaan samar bahwa beberapa baris dalam .htaccess tidak dapat membunuh segalanya satu jam setelah membuat garis-garis ini tidak membiarkan "mini" berubah menjadi sesuatu yang lebih lengkap. Secara umum, setelah beberapa menit bertukar pesan yang mengejutkan, kami masuk ke akun pribadi penyedia hosting tempat server tinggal. Dan di sana, di tiket, kami menemukan peringatan tentang "pekerjaan teknis dari X ke Y di MSC." Yang paling menarik adalah di kantor pos, tidak peduli bagaimana kami mencari, kami tidak menemukan pesan dari hoster tentang karya-karya ini. Tiket setidaknya sudah satu hari. Sebelum ini, pesan seperti itu datang ke surat, dan tidak ada yang biasanya melihat tiket layanan dukungan (dan kantor hoster itu sendiri) biasanya tanpa kebutuhan khusus. Karena itu, apa yang terjadi adalah kejutan besar. Setelah itu, kami memarahi mata sang hoster, tertawa, menunggu sampai semuanya bekerja dan pergi tidur.
Ini adalah sebuah cerita.