Menghindari Bencana CMS: Cara Mencegah Downtime Situs Web

Apa sebenarnya artinya sebuah situs dianggap down ?

Seringkali itu tergantung pada siapa Anda bertanya.

Untuk situs web yang dianggap down, itu mungkin berarti beberapa hal yang berbeda:

• Situs web sama sekali tidak tersedia.
• Situs web online tetapi sangat lambat.
• Situs web memberikan pesan kesalahan untuk pengguna atau lokasi tertentu.
• Situs web berfungsi untuk sebagian besar pengunjung, tetapi beberapa tidak dapat masuk ke CMS mereka, misalnya, untuk membuat, mengedit, atau memublikasikan konten.

Apa pun penyebab atau tingkatnya, dampak waktu henti situs web bisa serius, mulai dari kehilangan pesanan e-niaga dan pengguna yang frustrasi hingga kepercayaan pelanggan yang melemah.

Dalam seri Menghindari Bencana CMS ketiga kami, kami mengeksplorasi akar penyebab klasik downtime situs web dan peran pemantauan terus menerus dan faktor-faktor lain dalam menghindarinya.

Pertama, peran yang dimainkan pemantauan terus menerus

Kami memantau berbagai aspek situs web, sehingga kami dapat mengetahui ketika ada sesuatu yang tidak berfungsi dengan benar di salah satu lapisan berbeda yang membentuk platform VIP WordPress kami yang terkelola sepenuhnya. Lapisan-lapisan itu antara lain:

• Konektifitas jaringan
• Penyeimbang Beban
• Server web
• Caching objek (Memcached)
• Database
• pencarian elastis
• Layanan File (CDN)

Kami mencoba menemukan masalah lebih awal sehingga kami dapat mengantisipasi masalah di masa mendatang yang mungkin memengaruhi stabilitas situs web. Log referensi silang dari komponen sistem yang berbeda memungkinkan kami untuk meninjau periode ketika situs web dilaporkan tidak stabil. Karena kombinasi faktor daripada satu masalah mungkin bertanggung jawab atas waktu henti, kami menggunakan sejumlah alat untuk membandingkan data di seluruh sistem dan aplikasi.

Dalam kebanyakan kasus, ketidakstabilan situs web adalah akibat dari kode aplikasi, yaitu, tema dan kode plugin WordPress kustom atau pihak ketiga. Berikut adalah beberapa hal yang kami cari saat menyelidiki situs yang tidak stabil, dan cara menguranginya.

Caching tidak cukup

Hal terpenting yang dapat Anda lakukan untuk memastikan situs berkinerja baik dan stabil adalah memastikan semua halaman penuh yang dapat di-cache, di-cache. Halaman yang tidak di-cache perlu dibangun di server setiap kali diminta, yang merupakan proses yang lebih lambat dan lebih rentan terhadap kesalahan.

Jawaban VIP WordPress:

Platform VIP WordPress menyediakan caching halaman yang kuat melalui jaringan global server edge cache, masing-masing digunakan untuk menyimpan dan menyajikan konten yang paling dekat dengan pengguna akhir. Waktu respons dari server cache tepi hampir selalu lebih cepat daripada apa pun yang melewati caching halaman dan mengenai server asal.

Tantangan cache

Karena mereka menuntut pengalaman yang dipersonalisasi dan sepenuhnya interaktif, beberapa situs, terutama situs e-niaga, tidak dapat di-cache di tingkat cache halaman.

Seringkali kompromi dapat ditemukan dimana halaman statis dilayani oleh cache tepi, dengan fitur dinamis (misalnya, status login, keranjang belanja) ditambahkan melalui JavaScript. Permintaan asinkron dari JavaScript kemudian dapat digunakan untuk berkomunikasi dengan titik akhir API REST WordPress yang dirancang dengan overhead yang jauh lebih rendah daripada pemuatan halaman penuh.

Atau, di sinilah caching objek berperan. Halaman dapat tetap dinamis tetapi bagian halaman dan data apa pun yang digunakan di dalamnya dapat disimpan dan diambil dalam cache objek untuk menghindari perlunya melakukan kueri ke database.

Jawaban VIP WordPress:

Setiap lingkungan aplikasi VIP WordPress memiliki cluster Memcached tersendiri, yang menyimpan data cache objek dalam memori untuk pengambilan yang cepat dan efisien.

Penerapan kode yang belum teruji

Ini adalah penyebab umum lain dari downtime situs web dan cukup mudah didiagnosis, berdasarkan sebab dan akibat murni.

Jika situs web Anda baru saja menerapkan kode yang belum diuji, yang menyebabkan masalah situs langsung, ada kemungkinan penyebabnya. Jika Anda bisa, kembalikan kode tersangka ke versi sebelumnya secepatnya.

Hal terbaik yang harus dilakukan untuk menghindari situasi ini? Uji secara menyeluruh setiap bagian kode pada lingkungan pengembangan atau pementasan terpisah sebelum dirilis ke produksi.

Jawaban VIP WordPress:

Karena semua penerapan situs kami melalui GitHub, pelanggan VIP WordPress dapat dengan mudah mengembalikan kode sendiri, tanpa kehilangan perubahan kode baru, yang tetap tersimpan dengan aman di riwayat revisi GitHub. Secara opsional, dalam situasi darurat, kami dapat mengembalikan situs web pelanggan ke penerapan sebelumnya atas nama mereka, secara terpisah dari GitHub.

Mengenai lingkungan, semua aplikasi yang dihosting di layanan kami yang terkelola sepenuhnya dapat memiliki lingkungan pengembangan atau staging yang terpisah. Menyinkronkan data di sana dari produksi itu mudah, memungkinkan Anda menguji kode terhadap jumlah dan jenis data yang sama seperti di situs web produksi Anda.

kesalahan PHP

WordPress menggunakan kode PHP di server. Kesalahan PHP mungkin "fatal", artinya setelah kesalahan terjadi, halaman web, skrip, atau perintah akan berhenti berjalan. Ini hampir selalu muncul sebagai kesalahan yang terlihat di suatu tempat, dan akan dicatat dalam log PHP.

Catatan: Beberapa peringatan PHP di PHP 7 menjadi kesalahan fatal di PHP 8, jadi penting untuk menganggap kesalahan ini serius.

Jawaban VIP WordPress (ditambah saran bermanfaat):

Platform kami secara otomatis mencatat semua kesalahan PHP, membuatnya tersedia untuk pelanggan VIP WordPress di dasbor mereka dan untuk teknisi kami.

Kiat pro : Atasi dan perbaiki semua kesalahan PHP—meskipun situs tampaknya berfungsi dengan baik. Secara rutin, kami melihat log yang penuh dengan kesalahan PHP, bahkan yang fatal, di situs yang tampak stabil. Namun, itu tidak berarti situs berfungsi dengan benar . Menjaga log PHP tetap jelas dengan mengatasi kesalahan kecil dan peringatan membuatnya lebih mudah untuk menemukan kesalahan yang lebih serius selama debugging.

Kueri database MySQL lambat

Setiap situs WordPress menggunakan database untuk menyimpan konten situs web dan data konfigurasi. Kueri basis data mengambil data konten itu untuk halaman web, tetapi terkadang kueri tersebut ditulis secara tidak efisien. Mereka mungkin berfungsi dengan baik untuk situs dengan hanya beberapa ratus halaman, tetapi macet saat menangani data dalam jumlah besar (beberapa situs web di platform kami memiliki jutaan catatan yang tersimpan).

Kueri yang lambat mengikat sumber daya database, yang berpotensi memengaruhi stabilitas situs—tidak hanya untuk halaman, skrip, atau perintah yang menjalankan SQL, tetapi di seluruh aplikasi. Situs sering mengalami kesulitan karena kueri basis data tunggal atau ganda lambat, misalnya, kueri apa pun yang membutuhkan waktu lebih dari 0,75 detik untuk dieksekusi.

Jawaban VIP WordPress:

WordPress VIP membantu mengurangi kemacetan basis data dengan menyediakan setiap aplikasi dengan kluster basis data khusus yang menampilkan basis data utama, tempat semua kueri penulisan basis data terjadi, dan satu atau lebih basis data replika baca-saja. Ini meningkatkan jumlah kueri database simultan yang dapat dilakukan, menyebarkan beban sumber daya saat situs berada di bawah tekanan. Meskipun demikian, kueri basis data yang lambat tidak selalu dapat diselesaikan hanya dengan menambahkan sumber daya basis data tambahan. Itu sebabnya kami menyarankan pelanggan untuk memantau kueri database yang lambat dengan menggunakan Query Monitor dan New Relic (disediakan oleh platform kami). Ini menyoroti asal kueri dalam database, sehingga tim pengembangan Anda dapat memfaktorkan ulang kueri tersebut untuk mengoptimalkan kinerja.

Terakhir, Dukungan Aplikasi dan Insinyur Utama kami juga dapat membantu tim Anda menemukan dan menganalisis kueri ini, dan menyarankan cara untuk meningkatkannya demi kecepatan dan efisiensi.

Penulisan basis data yang berlebihan

Terkadang sebuah fitur, seperti logging kustom atau kode pelacakan, memperbarui database pada setiap permintaan. Hal ini dapat menyebabkan ketidakstabilan karena dua alasan:

• Replika database sebelumnya : Semua kueri tulis diarahkan ke database utama; kueri database berikutnya untuk tabel yang sama (atau tabel) dalam permintaan halaman yang sama juga akan diarahkan ke sana. Dengan tidak memanfaatkan replika database, ini membatasi skalabilitas situs.
• Melewati cache halaman : Agar penulisan database terjadi pada setiap permintaan halaman, cache halaman harus dilewati. Tetapi melakukan itu berarti garis pertahanan pertama (dan terbaik) telah dikompromikan.

Jawaban VIP WordPress:

Dalam keadaan ini, kami menyarankan untuk memfaktorkan ulang fitur tersebut. Misalnya, analitik konten biasanya paling baik didelegasikan ke layanan eksternal yang menggunakan cuplikan JavaScript di halaman daripada kode sisi server, yang tidak berfungsi dengan baik dengan cache dan dapat mengakibatkan penulisan database yang berlebihan.

Penyebab downtime lainnya yang diketahui dan cara menghindarinya

Plugin

Ada ribuan plugin pihak ketiga yang populer dan bermanfaat di ekosistem WordPress yang menyediakan fitur dan fungsionalitas fantastis. Namun, beberapa memiliki tantangan penskalaan, yang berpotensi menyebabkan masalah waktu henti saat ditambahkan ke situs web dengan banyak konten dan lalu lintas.

Jawaban VIP WordPress:

Sebagai penjaga ekosistem yang baik, kami secara teratur menghubungi vendor dengan saran untuk membuat plugin mereka berkinerja lebih baik di lingkungan dengan lalu lintas tinggi. Kami juga dapat menyarankan plugin alternatif yang telah dicoba dan diuji dalam skala besar di platform kami.

Pencatatan kustom

Logging kustom adalah alat debugging yang kuat, seringkali satu-satunya metode yang layak untuk melacak bug atau masalah yang tampaknya hanya terjadi di situs produksi. Namun, pada banyak kesempatan, kami telah melihat pencatatan kustom yang dibangun di PHP di situs dengan lalu lintas tinggi memperlambat banyak hal atau menempatkan situs dalam bahaya waktu henti karena penulisan basis data yang berlebihan.

Jawaban VIP WordPress:

Untuk pelanggan, kami menyediakan akses ke log PHP standar di panel Kesehatan Dasbor Aplikasi VIP WordPress. Di sana mereka dapat mencatat kesalahan khusus (dan juga ke New Relic), yang tidak akan berdampak negatif pada database.

Panggilan API jarak jauh

Beberapa situs web memanfaatkan panggilan REST API sisi server ke aplikasi atau layanan lain. Ini cukup cepat dalam keadaan normal, tetapi terkadang kode aplikasi yang mendasarinya menyebabkan respons yang lambat, waktu habis, atau kesalahan.

Jawaban VIP WordPress:

Untuk meminimalkan masalah ini, kami menyarankan "pengkodean defensif." Itu tergantung pada tujuan panggilan jarak jauh, tetapi sering kali ketika permintaan jarak jauh gagal, ada kemungkinan untuk kembali pada respons yang di-cache dari permintaan sebelumnya—atau setidaknya "menangani kesalahan dengan baik", sehingga sisa halaman dapat masih memuat. Kami menyediakan sejumlah fungsi pembantu untuk menangani skenario ini. Menjaga batas waktu rendah juga berarti sumber daya PHP dibebaskan lebih cepat jika API jarak jauh tidak merespons.

Baca lebih lanjut di seri Menghindari Bencana CMS kami

Saat bisnis Anda terancam, Anda tidak dapat mengirim bisnis baru ke tempat lain dan menodai merek Anda dengan membuat sistem manajemen konten (CMS) Anda memberikan pengalaman digital yang buruk. Dalam Cara Meningkatkan Kinerja Situs Web , kami mendiagnosis lima penyebab umum pelambatan dan cara meningkatkan daya menggunakan CMS yang gesit.

Hari-hari dengan lalu lintas tinggi seharusnya menjadi alasan untuk perayaan, bukan mimpi buruk bagi para insinyur di kaki belakang kolektif mereka yang mencoba menjaga situs dan aplikasi tetap aktif dan bersenandung untuk menangani beban—dan reputasi Anda tetap utuh. Dalam Menskalakan WordPress untuk Lalu Lintas Tinggi , kami mengeksplorasi empat pendekatan untuk memungkinkan situs web WordPress menangani gelombang pasang lalu lintas tersebut.