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. Evaluasi: Tentukan bottleneck server.
  2. Stabilkan: Menerapkan perbaikan cepat untuk mengurangi dampak.
  3. Tingkatkan: Meningkatkan 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. Mengidentifikasi mana yang merupakan bottleneck memungkinkan Anda memfokuskan upaya pada mitigasi yang paling berdampak.

  • CPU: Penggunaan CPU yang secara konsisten di atas 80% harus diselidiki dan diperbaiki. Performa server sering kali menurun begitu penggunaan CPU mencapai ~80-90%, dan menjadi lebih jelas saat penggunaan makin mendekati 100%. Penggunaan CPU dalam melayani satu permintaan dapat diabaikan, tetapi melakukan ini pada skala yang terjadi selama lonjakan traffic terkadang dapat membebani server. Mengurangi beban layanan 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, juga mungkin 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 dialihkan ke disk untuk disimpan. Disk jauh lebih lambat diakses daripada memori, dan ini dapat memperlambat seluruh aplikasi. Jika memori benar-benar habis, hal ini dapat menyebabkan error Out of Memory (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 mengatasi 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 awal yang baik untuk menyelidiki 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 masuk. Hal ini semakin penting karena penurunan performa server: seiring meningkatnya waktu respons, 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 suatu tempat di hulunya - misalnya, melalui load balancer, reverse proxy, atau CDN.

Petunjuk:

Bacaan lebih lanjut:

Caching HTTP

Mencari cara untuk meng-cache konten dengan lebih agresif. Jika resource dapat disalurkan 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 bagaimana resource harus di-cache oleh cache HTTP. Mengaudit dan memperbaiki header ini akan memperbaiki penyimpanan dalam cache.

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

Diagnosis

Jalankan Lighthouse dan lihat audit Tayangkan aset statis dengan kebijakan cache yang efisien untuk melihat daftar resource dengan time to live (TTL) singkat hingga menengah. 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:

{i>Graceful degradation<i}

{i>Graceful degradation <i}adalah strategi pengurangan fungsionalitas sementara untuk menghilangkan beban berlebih dari sistem. Konsep ini dapat diterapkan dengan banyak cara: misalnya, melayani halaman teks statis alih-alih aplikasi berfitur lengkap, menonaktifkan penelusuran atau menampilkan lebih sedikit hasil penelusuran, atau menonaktifkan fitur tertentu yang mahal atau tidak penting. Penekanan harus ditempatkan pada penghapusan fungsi yang dapat dihapus secara aman dan mudah dengan dampak bisnis yang minimal.

Meningkatkan

Menggunakan jaringan penayangan konten (CDN)

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

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

Menyiapkan CDN

CDN mendapat manfaat dari skala, sehingga mengoperasikan CDN sendiri jarang masuk akal. Konfigurasi CDN dasar cukup cepat disiapkan (~30 menit) dan terdiri dari pembaruan catatan DNS agar mengarah ke CDN.

Mengoptimalkan Penggunaan CDN

Diagnosis

Identifikasi resource yang tidak disalurkan dari CDN (tetapi seharusnya) dengan menjalankan WebPageTest. Di halaman hasil, klik kotak di atas 'Penggunaan CDN yang efektif' untuk melihat daftar sumber daya yang harus disalurkan dari CDN.

Panah yang mengarah ke tombol &#39;Penggunaan CDN yang efektif&#39;
Hasil WebPageTest

Perbaiki

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

Menskalakan resource komputasi

Keputusan untuk menskalakan resource komputasi harus dibuat dengan hati-hati. Meskipun skala resource komputasi sering kali diperlukan, 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 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 Anda untuk mendistribusikan traffic di beberapa server. Load balancer terletak di depan kumpulan server dan merutekan traffic ke server yang sesuai. Penyedia cloud menawarkan load balancer mereka sendiri (GCP, AWS, Azure) atau Anda dapat menyiapkannya sendiri menggunakan HAProxy atau NGINX. Setelah load balancer diterapkan, server lain dapat ditambahkan.

Selain load balancing, sebagian besar penyedia cloud menawarkan penskalaan otomatis (GCP, AWS, Azure). Penskalaan otomatis berfungsi bersama dengan load balancing - penskalaan otomatis menskalakan resource komputasi naik dan turun secara otomatis permintaan tertentu pada waktu tertentu. Meskipun demikian, penskalaan otomatis tidak bersifat ajaib - perlu waktu bagi instance baru untuk online dan memerlukan konfigurasi yang signifikan. Karena penskalaan otomatis yang diperlukan oleh penskalaan otomatis, penyiapan berbasis load balancer yang lebih sederhana harus dipertimbangkan terlebih dahulu.

Mengaktifkan kompresi

Resource berbasis teks harus dikompresi menggunakan gzip atau brotli. Gzip dapat mengurangi ukuran transfer resource tersebut hingga ~70%.

Diagnosis

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

Perbaiki

Aktifkan kompresi dengan memperbarui konfigurasi server Anda. Petunjuk:

Optimalkan gambar dan media

Gambar merupakan mayoritas ukuran file di sebagian besar situs; mengoptimalkan gambar dapat memperkecil 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 optimalisasi.

Audit Lighthouse yang relevan:

Alur kerja Chrome DevTools:

Perbaiki

Jika Anda memiliki waktu yang terbatas...

Fokuskan waktu Anda pada Mengidentifikasi gambar yang besar dan sering dimuat lalu optimalkan secara manual dengan alat seperti Squoosh. Banner besar sering kali merupakan kandidat yang tepat 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 punya waktu lebih...

Sebaiknya siapkan CDN gambar jika gambar merupakan bagian besar dari situs Anda. CDN Gambar dirancang untuk menyajikan dan mengoptimalkan gambar, dan CDN akan memindahkan penyajian gambar dari server asal. Menyiapkan CDN gambar sangat mudah, tetapi memerlukan pembaruan URL gambar yang ada agar mengarah ke CDN gambar.

Bacaan lebih lanjut:

Meminifikasi 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 memerlukan minifikasi.

Perbaiki

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

Memantau

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

Pengaturan pemantauan harus dibuat sesederhana mungkin. Pengumpulan dan peringatan data yang berlebihan menimbulkan biaya: semakin besar cakupan atau frekuensi pengumpulan data, semakin mahal pengumpulan dan penyimpanan data; peringatan yang berlebihan pasti akan mengarah ke halaman yang diabaikan.

Pemberitahuan harus menggunakan metrik yang mendeteksi masalah secara konsisten dan akurat. Waktu respons server (latensi) adalah metrik yang berfungsi sangat baik untuk hal ini: metrik ini mendeteksi berbagai masalah dan berkorelasi langsung dengan pengalaman pengguna. Pemberitahuan berdasarkan metrik tingkat rendah seperti penggunaan CPU dapat menjadi pelengkap yang berguna, tetapi akan mencakup 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 besar menawarkan alat pemantauan mereka sendiri (GCP, AWS, Azure). Selain itu, Netdata adalah alternatif open source dan gratis yang sangat bagus. Apa pun alat yang dipilih, Anda harus menginstal agen pemantauan alat tersebut pada setiap server yang ingin dipantau. Setelah selesai, pastikan untuk menyiapkan pemberitahuan.

Petunjuk: