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: Meningkatkan dan mengoptimalkan kemampuan server.
  4. Pantau: Gunakan alat otomatis untuk membantu mencegah masalah di masa mendatang.

Nilai

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 secara konsisten lebih dari 80% harus diselidiki dan diperbaiki. Performa server sering kali menurun setelah penggunaan CPU mencapai ~80-90%, dan menjadi lebih jelas saat penggunaan mendekati 100%. Penggunaan CPU untuk menayangkan satu permintaan dapat diabaikan, tetapi melakukannya pada skala yang terjadi selama lonjakan traffic terkadang dapat membebani server. Mentransfer penayangan ke infrastruktur lain, mengurangi operasi yang mahal, dan membatasi jumlah permintaan akan mengurangi penggunaan 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 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 di-offload ke disk untuk disimpan. Disk jauh lebih lambat untuk diakses daripada memori, dan hal ini dapat memperlambat seluruh aplikasi. Jika memori benar-benar habis, error Kehabisan Memori (OOM) dapat terjadi. 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 adalah bottleneck, meningkatkan jumlah data yang di-cache dalam memori dapat mengurangi masalah ini (dengan mengorbankan peningkatan penggunaan memori). Jika tidak berhasil, Anda mungkin perlu mengupgrade disk.

Teknik dalam panduan ini berfokus pada mengatasi 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 tempat yang baik untuk memulai penyelidikan bottleneck. Jika tersedia, lengkapi dengan data historis dari penyedia hosting atau alat pemantauan Anda.

Stabilkan

Server yang kelebihan beban dapat dengan cepat menyebabkan kegagalan beruntun di tempat lain dalam sistem. Oleh karena itu, penting untuk menstabilkan server sebelum mencoba membuat perubahan yang lebih signifikan.

Pembatasan Kapasitas

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

Perbaiki

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

Petunjuk:

Bacaan lebih lanjut:

Penyimpanan Cache HTTP

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

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

Meskipun pekerja layanan juga dapat digunakan untuk menyimpan cache, pekerja layanan menggunakan cache terpisah dan merupakan pelengkap, bukan pengganti, untuk penyimpanan cache HTTP yang tepat. Oleh karena itu, saat menangani server yang kelebihan beban, upaya harus difokuskan pada pengoptimalan penyimpanan dalam cache HTTP.

Diagnosis

Jalankan Lighthouse dan lihat audit Menayangkan 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 lama (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 Anggun

Degradasi halus adalah strategi untuk mengurangi fungsi sementara waktu guna mengurangi beban berlebih dari sistem. Konsep ini dapat diterapkan dengan berbagai cara: misalnya, menayangkan 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 minimal.

Tingkatkan kualitas

Menggunakan jaringan penayangan konten (CDN)

Penayangan aset statis dapat di-offload dari server Anda ke jaringan penayangan konten (CDN), sehingga mengurangi beban.

Fungsi utama CDN adalah mengirimkan konten kepada pengguna dengan cepat dengan menyediakan jaringan server besar yang terletak dekat dengan pengguna. Namun, sebagian besar CDN juga menawarkan fitur terkait performa tambahan 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 agar mengarah ke CDN.

Mengoptimalkan Penggunaan CDN

Diagnosis

Identifikasi resource yang tidak ditayangkan dari CDN (tetapi seharusnya ditayangkan) dengan menjalankan WebPageTest. Di halaman hasil, klik kotak di atas 'Penggunaan CDN yang efektif' untuk melihat daftar resource yang harus ditayangkan 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 hati-hati. Meskipun sering kali perlu menskalakan resource komputasi, melakukannya secara prematur dapat menimbulkan kompleksitas arsitektur dan biaya keuangan 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 Mengurangi 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 distribusi traffic di 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 akan otomatis menskalakan resource komputasi naik dan turun sesuai permintaan pada waktu tertentu. Meskipun demikian, penskalaan otomatis bukanlah hal yang ajaib. Perlu waktu agar instance baru dapat beroperasi dan memerlukan konfigurasi yang signifikan. Karena kompleksitas tambahan yang diperlukan 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 sebesar ~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 sebagian besar ukuran file di sebagian besar situs; mengoptimalkan gambar dapat mengurangi ukuran situs dengan cepat dan signifikan.

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 besar dan sering dimuat serta mengoptimalkannya secara manual dengan alat seperti Squoosh. Gambar utama sering kali merupakan 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 berdampak 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 lebih banyak waktu…

Sebaiknya siapkan CDN gambar jika gambar merupakan bagian yang cukup besar dari situs Anda. CDN Gambar dirancang untuk menayangkan dan mengoptimalkan gambar serta akan mengurangi beban penayangan gambar dari server asal. Menyiapkan CDN gambar cukup mudah, tetapi Anda harus memperbarui URL gambar yang ada agar mengarah ke CDN gambar.

Bacaan lebih lanjut:

Melakukan minifikasi JS dan CSS

Pengompresian menghapus karakter yang tidak diperlukan dari JavaScript dan CSS.

Diagnosis

Gunakan audit Lighthouse Minifikasi CSS dan Minifikasi JavaScript untuk mengidentifikasi resource yang memerlukan minifikasi.

Perbaiki

Jika Anda memiliki waktu terbatas, fokuslah untuk 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 memitigasi masalah performa server di masa mendatang.

Penyiapan pemantauan harus dibuat sesederhana mungkin. Pengumpulan dan pemberitahuan data yang berlebihan memiliki biayanya sendiri: 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 mendeteksi masalah secara konsisten dan akurat. 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 suplemen yang berguna, tetapi akan mendeteksi subset masalah yang lebih kecil. 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 open source dan gratis yang sangat baik. Apa pun alat yang Anda pilih, Anda harus menginstal agen pemantauan alat di setiap server yang ingin dipantau. Setelah selesai, pastikan untuk menyiapkan pemberitahuan.

Petunjuk: