Memperbaiki server yang kelebihan beban

Cara menentukan bottleneck server, memperbaiki bottleneck dengan cepat, meningkatkan performa server, dan mencegah regresi.

Katie Hempenius
Katie Hempenius
X

Ringkasan

Panduan ini menunjukkan cara memperbaiki server yang kelebihan beban dalam 4 langkah:

  1. Menilai: Menentukan bottleneck server.
  2. Stabilkan: Terapkan perbaikan cepat untuk mengurangi dampak.
  3. Meningkatkan: Menambah dan mengoptimalkan kemampuan server.
  4. Pantau: Gunakan alat otomatis untuk membantu mencegah masalah pada masa mendatang.

Menilai

Saat traffic membebani server, satu atau beberapa hal berikut dapat menjadi bottleneck: CPU, jaringan, memori, atau I/O disk. Dengan mengidentifikasi bottleneck, Anda dapat memfokuskan upaya pada mitigasi yang paling berdampak.

  • CPU: Penggunaan CPU yang terus-menerus di atas 80% harus diselidiki dan diperbaiki. Performa server sering kali menurun setelah penggunaan CPU mencapai ~80-90%, dan menjadi lebih terlihat saat penggunaan mendekati 100%. Penggunaan CPU untuk melayani satu permintaan dapat diabaikan, tetapi melakukan hal ini pada skala yang dihadapi selama lonjakan traffic terkadang dapat membebani server. Memindahkan penyaluran ke infrastruktur lain, mengurangi operasi yang mahal, dan membatasi jumlah permintaan akan mengurangi pemakaian CPU.
  • Jaringan: Selama periode traffic tinggi, throughput jaringan yang diperlukan untuk memenuhi permintaan pengguna dapat melebihi kapasitas. Beberapa situs, bergantung pada penyedia hosting, mungkin juga mencapai batas terkait transfer data kumulatif. Mengurangi ukuran dan jumlah data yang ditransfer ke dan dari server akan menghilangkan bottleneck ini.
  • Memori: Jika sistem tidak memiliki cukup memori, data harus dipindahkan ke disk untuk disimpan. Disk jauh lebih lambat untuk diakses daripada memori, dan hal ini dapat memperlambat seluruh aplikasi. Jika memori benar-benar habis, hal ini dapat menyebabkan error Kehabisan Memori (OOM). Menyesuaikan alokasi memori, memperbaiki kebocoran memori, dan mengupgrade memori dapat menghilangkan bottleneck ini.
  • I/O Disk: Kecepatan data dapat dibaca atau ditulis dari disk dibatasi oleh disk itu sendiri. Jika I/O disk menjadi bottleneck, meningkatkan jumlah data yang di-cache dalam memori dapat mengurangi masalah ini (dengan konsekuensi peningkatan penggunaan memori). Jika cara ini tidak berhasil, Anda mungkin perlu mengupgrade disk.

Teknik dalam panduan ini berfokus pada penanganan bottleneck CPU dan jaringan. Untuk sebagian besar situs, CPU dan jaringan akan menjadi bottleneck yang paling relevan selama lonjakan traffic.

Menjalankan top di server yang terpengaruh adalah titik awal yang baik untuk menyelidiki bottleneck. Jika tersedia, lengkapi data ini dengan data historis dari penyedia hosting atau alat pemantauan Anda.

Stabilkan

Server yang kelebihan beban dapat dengan cepat menyebabkan kegagalan beruntun di bagian lain sistem. Oleh karena itu, Anda harus menstabilkan server sebelum mencoba melakukan perubahan yang lebih signifikan.

Pembatasan kapasitas

Pembatasan kapasitas melindungi infrastruktur dengan membatasi jumlah permintaan yang masuk. Hal ini menjadi semakin penting seiring menurunnya performa server: saat waktu respons meningkat, pengguna cenderung memuat ulang halaman secara agresif, sehingga semakin meningkatkan beban server.

Perbaiki

Meskipun menolak permintaan relatif murah, cara terbaik untuk melindungi server Anda adalah dengan menangani pembatasan kapasitas di suatu tempat di upstream-nya, misalnya, melalui load balancer, reverse proxy, atau CDN.

Petunjuk:

Bacaan lebih lanjut:

Penyimpanan cache HTTP

Cari cara untuk meng-cache konten secara lebih agresif. Jika resource dapat ditayangkan dari cache HTTP (baik cache browser maupun CDN), resource tersebut tidak perlu diminta dari server asal, sehingga mengurangi beban server.

Header HTTP seperti Cache-Control, Expires, dan ETag menunjukkan cara resource harus di-cache oleh cache HTTP. Mengaudit dan memperbaiki header ini akan meningkatkan kualitas penyimpanan ke cache.

Meskipun service worker juga dapat digunakan untuk caching, service worker menggunakan cache terpisah dan merupakan pelengkap, bukan pengganti, untuk caching HTTP yang tepat. Oleh karena itu, saat menangani server yang kelebihan beban, upaya harus difokuskan pada pengoptimalan caching HTTP.

Diagnosis

Jalankan Lighthouse dan lihat audit Sajikan aset statis dengan kebijakan cache yang efisien untuk melihat daftar resource dengan time to live (TTL) singkat hingga sedang. Untuk setiap resource yang tercantum, pertimbangkan apakah TTL harus ditingkatkan. Sebagai panduan kasar:

  • Resource statis harus di-cache dengan TTL yang panjang (1 tahun).
  • Resource dinamis harus di-cache dengan TTL singkat (3 jam).

Perbaiki

Tetapkan perintah max-age header Cache-Control ke jumlah detik yang sesuai.

Petunjuk:

Degradasi halus

Degradasi halus adalah strategi untuk mengurangi fungsionalitas sementara guna mengurangi beban berlebih dari sistem. Konsep ini dapat diterapkan dalam berbagai cara: misalnya, menyajikan halaman teks statis, bukan aplikasi berfitur lengkap, menonaktifkan penelusuran atau menampilkan lebih sedikit hasil penelusuran, atau menonaktifkan fitur tertentu yang mahal atau tidak penting. Penekanan harus diberikan pada penghapusan fungsi yang dapat dihapus dengan aman dan mudah dengan dampak bisnis yang minimal.

Tingkatkan kualitas

Menggunakan jaringan penayangan konten (CDN)

Penyajian aset statis dapat dialihkan dari server Anda ke jaringan penayangan konten (CDN), sehingga mengurangi beban.

Fungsi utama CDN adalah mengirimkan konten kepada pengguna dengan cepat melalui jaringan server yang besar dan terletak dekat dengan pengguna. Namun, sebagian besar CDN juga menawarkan fitur tambahan terkait performa seperti kompresi, load balancing, dan pengoptimalan media.

Menyiapkan CDN

CDN mendapatkan manfaat dari skala, sehingga mengoperasikan CDN Anda sendiri jarang masuk akal. Konfigurasi CDN dasar cukup cepat disiapkan (~30 menit) dan terdiri dari memperbarui data DNS untuk mengarah ke CDN.

Mengoptimalkan penggunaan CDN

Diagnosis

Identifikasi resource yang tidak disajikan dari CDN (tetapi seharusnya disajikan) dengan menjalankan WebPageTest. Di halaman hasil, klik kotak di atas 'Effective use of CDN' untuk melihat daftar resource yang harus disajikan dari CDN.

Panah yang mengarah ke tombol 'Penggunaan CDN yang efektif'
Hasil WebPageTest

Perbaiki

Jika resource tidak di-cache oleh CDN, pastikan kondisi berikut terpenuhi:

Menskalakan resource komputasi

Keputusan untuk menskalakan resource komputasi harus dibuat dengan cermat. Meskipun sering kali diperlukan untuk menskalakan resource komputasi, melakukannya sebelum waktunya dapat menimbulkan kompleksitas arsitektur dan biaya finansial yang tidak perlu.

Diagnosis

Time To First Byte (TTFB) yang tinggi dapat menjadi tanda bahwa server hampir mencapai kapasitasnya. Anda dapat menemukan informasi ini di audit Kurangi waktu respons server (TTFB) Lighthouse.

Untuk menyelidiki lebih lanjut, gunakan alat pemantauan untuk menilai penggunaan CPU. Jika penggunaan CPU saat ini atau yang diperkirakan melebihi 80%, Anda harus mempertimbangkan untuk meningkatkan server.

Perbaiki

Menambahkan load balancer memungkinkan pendistribusian traffic ke beberapa server. Load balancer berada di depan kumpulan server dan merutekan traffic ke server yang sesuai. Penyedia cloud menawarkan load balancer mereka sendiri (GCP, AWS, Azure) atau Anda dapat menyiapkan load balancer Anda sendiri menggunakan HAProxy atau NGINX. Setelah load balancer diterapkan, server tambahan dapat ditambahkan.

Selain load balancing, sebagian besar penyedia cloud menawarkan penskalaan otomatis (GCP, AWS, Azure). Penskalaan otomatis berfungsi bersama dengan load balancing - penskalaan otomatis secara otomatis meningkatkan dan menurunkan skala resource komputasi sesuai permintaan pada waktu tertentu. Meskipun demikian, penskalaan otomatis bukanlah hal yang ajaib - perlu waktu bagi instance baru untuk online dan memerlukan konfigurasi yang signifikan. Karena kompleksitas tambahan yang ditimbulkan oleh penskalaan otomatis, penyiapan berbasis load balancer yang lebih sederhana harus dipertimbangkan terlebih dahulu.

Aktifkan pemampatan

Resource berbasis teks harus dikompresi menggunakan gzip atau brotli. Gzip dapat mengurangi ukuran transfer resource ini sekitar 70%.

Diagnosis

Gunakan audit Aktifkan kompresi teks Lighthouse untuk mengidentifikasi resource yang harus dikompresi.

Perbaiki

Aktifkan kompresi dengan memperbarui konfigurasi server Anda. Petunjuk:

Mengoptimalkan gambar dan media

Gambar merupakan bagian terbesar dari ukuran file sebagian besar situs; mengoptimalkan gambar dapat dengan cepat dan signifikan mengurangi ukuran situs.

Diagnosis

Lighthouse memiliki berbagai audit yang menandai potensi pengoptimalan gambar. Atau, strategi lainnya adalah menggunakan DevTools untuk mengidentifikasi file gambar terbesar - gambar ini kemungkinan akan menjadi kandidat yang baik untuk pengoptimalan.

Audit Lighthouse yang relevan:

Alur kerja Chrome DevTools:

Perbaiki

Jika Anda memiliki waktu terbatas…

Fokuskan waktu Anda untuk Mengidentifikasi gambar berukuran besar dan sering dimuat, lalu mengoptimalkannya secara manual dengan alat seperti Squoosh. Banner besar sering kali menjadi kandidat yang baik untuk pengoptimalan.

Hal yang perlu diingat:

  • Ukuran: Gambar tidak boleh lebih besar dari yang diperlukan.
  • Kompresi: Secara umum, tingkat kualitas 80-85 akan memiliki efek minimal pada kualitas gambar sekaligus menghasilkan pengurangan ukuran file sebesar 30-40%.
  • Format: Gunakan JPEG untuk foto, bukan PNG; gunakan MP4 untuk konten animasi, bukan GIF.

Jika Anda memiliki waktu luang…

Sebaiknya siapkan CDN gambar jika gambar merupakan bagian penting dari situs Anda. CDN gambar dirancang untuk menayangkan dan mengoptimalkan gambar, serta akan mengurangi beban penayangan gambar dari server asal. Menyiapkan CDN gambar sangatlah mudah, tetapi memerlukan pembaruan URL gambar yang ada agar mengarah ke CDN gambar.

Bacaan lebih lanjut:

Minifikasi JS dan CSS

Minifikasi menghapus karakter yang tidak diperlukan dari JavaScript dan CSS.

Diagnosis

Gunakan audit Lighthouse Minifikasi CSS dan Minifikasi JavaScript untuk mengidentifikasi resource yang perlu diminifikasi.

Perbaiki

Jika Anda memiliki waktu terbatas, fokuslah pada meminifikasi JavaScript. Sebagian besar situs memiliki lebih banyak JavaScript daripada CSS, sehingga hal ini akan lebih berdampak.

Memantau

Alat pemantauan server menyediakan pengumpulan data, dasbor, dan pemberitahuan terkait performa server. Penggunaannya dapat membantu mencegah dan mengurangi masalah performa server di masa mendatang.

Penyiapan pemantauan harus dibuat sesederhana mungkin. Pengumpulan data dan pemberitahuan yang berlebihan memiliki biaya: semakin besar cakupan atau frekuensi pengumpulan data, semakin mahal biaya pengumpulan dan penyimpanannya; pemberitahuan yang berlebihan pasti akan menyebabkan halaman diabaikan.

Pemberitahuan harus menggunakan metrik yang secara konsisten dan akurat mendeteksi masalah. Waktu respons server (latensi) adalah metrik yang sangat cocok untuk hal ini: metrik ini menangkap berbagai masalah dan berkorelasi langsung dengan pengalaman pengguna. Pemberitahuan berdasarkan metrik tingkat rendah seperti penggunaan CPU dapat menjadi pelengkap yang berguna, tetapi hanya akan menangkap sebagian kecil masalah. Selain itu, pemberitahuan harus didasarkan pada performa yang diamati di bagian akhir (dengan kata lain persentil ke-95 atau ke-99), bukan rata-rata. Jika tidak, rata-rata dapat dengan mudah mengaburkan masalah yang tidak memengaruhi semua pengguna.

Perbaiki

Semua penyedia cloud utama menawarkan alat pemantauan mereka sendiri (GCP, AWS, Azure). Selain itu, Netdata adalah alternatif gratis dan open source yang sangat baik. Apa pun alat yang Anda pilih, Anda harus menginstal agen pemantauan alat tersebut di setiap server yang ingin Anda pantau. Setelah selesai, pastikan untuk menyiapkan pemberitahuan.

Petunjuk: