Apa yang harus saya lakukan untuk memperkecil situs web dengan lalu lintas tinggi?

Apa praktik terbaik yang harus dilakukan untuk situs web yang perlu "ditingkatkan" untuk menangani kapasitas? Ini sangat relevan sekarang karena orang-orang mempertimbangkan cloud, tetapi mungkin kehilangan fundamentalnya.

Saya tertarik mendengar tentang apa pun yang Anda anggap praktik terbaik dari tugas tingkat pengembangan, infrastruktur, hingga manajemen.

Desain untuk Konkurensi

Yaitu, saat Anda membuat kode, rencanakan untuk menjalankan beberapa utas. Rencanakan status bersama (seringkali hanya db). Rencanakan beberapa proses. Merencanakan distribusi fisik.

Ini memungkinkan Anda untuk mendistribusikan sistem Anda di beberapa mesin, dan di berbagai proses dengan load balancing. Ini memungkinkan Anda untuk menjalankan proses redundan jika terjadi kegagalan, dan jika Anda perlu memodifikasi sistem di tempat, Anda tidak perlu mematikan semua layanan untuk melakukannya.

Beberapa hal yang mungkin Anda pertimbangkan:

• Memisahkan sisi baca dan tulis dari penyimpanan data Anda.
  
  • Sumber CQRS / Acara
  • CQS
  • Penerusan pesan / Aktor
• Menghindari proses berbagi dan status utas
  • Oleh karena itu menghindari penguncian
  • Anda dapat menghindari ini melalui sistem tipe dengan membuat kelas, struct, dan tipe data lainnya agar tidak berubah, yaitu tidak berubah setelah konstruksi. Khusus untuk tipe data abstrak yang kompleks, ia bekerja sangat baik (misalnya implementasi jQuery)
• Tidak memblokir utas server web di IO. Jika Anda menggunakan ASP.Net, gunakan halaman / tindakan asinkron dengan pola APM / task-parallel library (TPL)
• Tidak menyimpan banyak status dalam kamus sesi pengguna
  • Ini harus dipindahkan melintasi utas saat migrasi utas terjadi di IIS.
  • Memiliki perutean yang cerdas, sehingga sumber daya yang tidak diamankan / statis tidak disajikan dengan kerangka kerja aplikasi yang sama (misalnya ASP.Net) yang menambahkan overhead. Lihat memiliki server web yang berbeda, misalnya.
• Menulis kode passing-lanjut dengan pola-alur kerja asinkron (mis. Bind (haskell) /callcc/Tasks.ContinueWith/F#'s async)
• Gunakan teori antrian untuk menghitung di mana kemacetan Anda mungkin terjadi
• Gunakan pembaruan berbasis push dan bukan pull untuk model-baca dan status aplikasi lainnya. Misalnya melalui RabbitMQ / nServiceBus
• Gunakan fitur-fitur yang paling sedikit berlaku 'http handler'
• Untuk file statis, sajikan kebijakan kadaluwarsa e-tag dan cache untuk mengaktifkan infrastruktur web agar berfungsi sebagaimana mestinya (mis. Dengan proxy squid)
• (Pekerjakan saya untuk menyelesaikan masalah penskalaan Anda dan dapatkan tutorial di tempat;))

Bagikan arsitektur apa-apa.

Dengan pemikiran itu, dan bertentangan dengan apa yang mungkin Anda pikirkan, jangan langsung menuju solusi skala-out. Over-sistem overhead vs panggilan dalam-sistem tidak boleh di bawah-ditimbang. Misalnya, dibutuhkan BANYAK lebih lama untuk membuat koneksi DB di semua antarmuka jaringan daripada untuk membuat panggilan lokal. Anggaran berapa banyak waktu dalam manajemen, daya, dan upaya penyempurnaan diperlukan dalam skala-out vs $ ekstra untuk sistem besar yang sebenarnya.

Apapun, saya masih ada nilai besar dalam arsitektur "tidak berbagi apa-apa" dan Anda dapat lapisan dan skala-sistem Anda ketika saatnya tiba.

Paralelkan permintaan dengan beberapa nama host

Bagian dari standar HTTP adalah bagian yang mengatakan klien web akan meminta maksimum 2 sesi per Host DNS. Ini adalah solusi tempat Anda dan alias mengeluarkan www.domain.com dan mendapatkan konkurensi permintaan yang lebih tinggi, membuat laman Anda dimuat lebih cepat:

/programming/3653609/how-do-i-code-my-asp-net-page-to-parallelize-downloads-across-hostnames

Pada dasarnya ini melibatkan pengeditan ASP.NET HTTP Handler Anda untuk mengganti host target yang Anda kirimi klien, di mana setiap host adalah CNAME menjadi "www".

DNS yang Aman, Cepat, andal

Saya menemukan beberapa situs web berkapasitas tinggi menggunakan server DNS registrar, yang tidak memiliki SLA untuk uptime atau kinerja. Selain itu, server mereka berlokasi di India dan latensi saja meningkatkan kemungkinan spoofer DNS dapat meracuni pelanggan Anda, atau cache perantara ISP. Ini akan menyebabkan bahkan lalu lintas yang Anda lindungi SSL untuk dialihkan tanpa ada yang mengetahuinya.

Kecepatan DNS juga memengaruhi waktu muat awal server Anda, sebelum catatan di-cache.

Saya menggunakan DynDNS atau Neustar untuk sebagian besar pelanggan saya karena mereka memiliki infrastruktur DNS yang cukup solid (meskipun mahal dan saya tidak memiliki afiliasi lain dengan perusahaan-perusahaan itu).

Saya pikir kuncinya akan sederhana:

Memiliki kode sederhana. Itu berarti sesuatu yang Anda lihat dan pahami. Ketika Anda memperluas dan mengganti server, Anda perlu tahu apa yang sedang terjadi. Anda juga mungkin perlu menambahkan coders yang perlu dengan cepat mengerti. File kait dan XML yang memanggil kode acak yang tidak jelas sangat buruk.

Kemudian Anda dapat menguji dan menemukan masalahnya.

Lihat di sini: http://blog.servint.net/2013/08/27/going-big-how-to-scale-a-website-part-1-infrastructure-that-scales/

Kami di stellarbuild mencoba memastikan skala situs web kami tanpa down time. Itu berarti Anda harus dapat mengetahui apa kode Anda dan di mana ia melakukannya. Bahkan jika Anda menguji mesin yang berbeda, Anda tidak bisa terlalu lama untuk mengukur. Kebanyakan orang hanya memulai ketika hampir terlambat, dengan sedih. Anda dapat mengoptimalkan hanya sekali Anda melakukannya menurut saya.