Berapa banyak proses yang harus saya tentukan dalam WSGIDaemonProcess saat menjalankan Django melalui mod_wsgi?

Katakanlah saya memiliki 2 situs (Superuser dan Serverfault) yang berjalan dari host virtual Apache mereka sendiri dalam satu kotak. 2 situs ini didukung oleh Django dan berjalan di Apache dengan mod-wsgi. File konfigurasi khas untuk salah satu situs akan terlihat seperti berikut:

WSGIDaemonProcess serverfault.com user=www-data group=www-data processes=5

Tuan rumah adalah mesin linux dengan 4GB RAM yang menjalankan Ubuntu. Adakah yang bisa menyarankan jumlah proses yang harus saya tentukan di atas untuk 2 situs saya? Mari kita asumsikan mereka memiliki lalu lintas yang sama dengan situs Superuser dan Serverfault yang sebenarnya.

Nah, berapa banyak traffic yang dimiliki situs Superuser dan Serverfault yang sebenarnya? Hipotetis tidak banyak digunakan jika mereka tidak memiliki cukup info untuk membuat jawabannya lebih mudah ...

Hitungan proses kasus terburuk Anda harus merupakan jumlah puncak permintaan per detik yang Anda inginkan dapat ditangani oleh situs, dibagi dengan jumlah permintaan per detik yang dapat ditangani oleh satu proses jika semua permintaan tersebut dilakukan untuk tindakan paling lambat Anda (jadi kebalikan dari waktu pemrosesan tindakan itu). Tambahkan faktor fudge apa pun yang Anda anggap tepat, berdasarkan interval kepercayaan req / detik Anda dan pengukuran waktu.

Jumlah kasus rata-rata adalah sama, tetapi Anda membagi req / detik dengan rata-rata tertimbang dari permintaan Anda per angka kedua untuk setiap tindakan (beratnya adalah persentase permintaan yang Anda harapkan untuk mencapai tindakan tertentu). Sekali lagi, faktor fudge berguna.

Batas atas sebenarnya dari berapa banyak proses yang dapat Anda jalankan pada mesin ditentukan oleh jumlah memori yang lebih tinggi dari setiap proses yang dilakukan; gabungkan satu proses, kemudian jalankan berbagai tindakan yang haus memori (yang mengambil dan memproses banyak data, biasanya) melawannya dengan set data realistis (jika Anda hanya menggunakan set data mainan untuk pengujian, katakan 50 atau 100 baris, maka jika salah satu tindakan Anda mengambil dan memanipulasi setiap baris dalam tabel itu tidak akan menjadi ukuran yang baik untuk kapan tabel itu tumbuh menjadi 10.000 baris) untuk melihat bagaimana penggunaan memori habis. Anda dapat secara artifisial membatasi penggunaan memori per-proses Anda dengan skrip yang menuai pekerja yang mencapai ambang penggunaan memori tertentu, dengan risiko menyebabkan masalah buruk jika Anda menetapkan ambang itu terlalu rendah.

Setelah angka penggunaan memori Anda, Anda mengurangi sejumlah memori untuk overhead sistem (saya suka 512MB sendiri), kurangi lebih banyak jika Anda punya proses lain yang berjalan pada mesin yang sama (seperti database), dan kemudian beberapa lagi untuk memastikan Anda tidak kehabisan ruang cache disk (tergantung pada ukuran set kerja disk Anda, tapi sekali lagi saya akan pergi dengan tidak kurang dari 512MB). Itu adalah jumlah memori yang Anda bagi dengan penggunaan memori per-proses untuk mendapatkan plafon.

Jika jumlah proses yang Anda butuhkan untuk melayani beban puncak Anda lebih besar dari jumlah proses yang dapat Anda masukkan pada kotak, Anda membutuhkan lebih banyak mesin (atau untuk memindahkan database ke mesin lain, dalam kasus yang paling sederhana).

Inilah Anda, beberapa tahun pengalaman menskalakan situs web disaring menjadi satu pos SF kecil dan sederhana.

Jawaban womble luar biasa, meskipun agak sulit untuk dipahami dan diterapkan untuk yang belum berpengalaman. Saya ingin memberikan beberapa angka empiris, dan perbandingan aplikasi "konten sederhana" versus "e-commerce".

Tidak ada banyak bahan di sekitar pengaturan kasus penggunaan yang berbeda sehubungan dengan konfigurasi mod_wsgi yang sesuai, jadi saya harap tidak apa-apa untuk menggunakan prosa kecil di sini.

A) Situs CMS & Microsites

Kami menjalankan beberapa situs web pelanggan, kebanyakan dari mereka terutama situs konten atau situs mikro hosting django CMS, beberapa formulir khusus, dan kadang-kadang Seledri untuk tugas-tugas latar belakang yang dijadwalkan. Situs-situs ini tidak haus sumber daya, beberapa dari mereka berjalan dengan gembira secara paralel pada 4 Core Intel Xeon dengan RAM 32 GB. Berikut konfigurasi yang kami gunakan untuk masing-masing situs semacam ini:

WSGIDaemonProcess example.com user=www-data processes=2 maximum-requests=100

Saya berbicara tentang sekitar 40 situs di satu server, kebanyakan dari mereka dengan situs Pementasan mereka berjalan dalam keadaan siaga. Dengan 2 proses (masing-masing memiliki 15 utas, secara default) situs-situs tersebut kaya, meskipun terbatas dalam kemampuan mereka mengalokasikan sumber daya server. Mengapa pengaturan ini cukup dapat dibenarkan dengan sifat sederhana dari aplikasi (CMS): Tidak ada permintaan yang diharapkan akan membutuhkan lebih dari beberapa milidetik untuk diselesaikan. Apache akan selalu tetap santai, dan demikian juga dengan beban CPU.

B) Situs E-Commerce

Situs yang lebih kompleks yang kami lakukan ditandai dengan operasi lokal yang masih murah secara komputasi tetapi ketergantungan eksternal (mis. Layanan web yang menyediakan data pemesanan) yang mahal dalam hal waktu transaksi. Operasi dengan permintaan eksternal menempati utas untuk waktu yang lebih lama, sehingga Anda membutuhkan lebih banyak utas untuk memenuhi jumlah pengguna yang sama (dibandingkan dengan situs CMS sederhana dari atas). Lebih buruk lagi, utas terkadang diblokir ketika layanan eksternal tidak dapat langsung menjawab permintaan, kadang-kadang selama beberapa detik. Ini dapat menyebabkan efek samping yang tidak menyenangkan karena utas menempatkan permintaan ke antrian layanan yang sama, sampai semua utas mod_wsgi yang tersedia digunakan dan diblokir menunggu.

Untuk skenario itu, kami telah mencoba menggunakan 6proses tanpa melihat banyak perbedaan, dan kami akhirnya 12melihat peningkatan yang tak tertandingi dalam kinerja dan stabilitas operasional:

WSGIDaemonProcess example.com user=www-data processes=12 maximum-requests=100

Beberapa tes beban sederhana dengan 150, dan 250 pengguna paralel dengan mudah ditangani oleh situs tetap responsif dengan baik (sementara dengan 2proses situs dapat digunakan melayani 50 pengguna secara paralel). 2 CPU 6 Core Intel Xeon dengan 32 GB RAM berjalan jauh di bawah 25% penggunaan CPU di bawah beban itu, penggunaan RAM hampir tetap konstan di kurang dari 25%, juga. Perhatikan bahwa kami menggunakan mesin khusus hanya untuk satu situs di sini, jadi kami tidak akan mencuri sumber daya yang mungkin dibutuhkan situs lain.

Kesimpulan

Menggunakan jumlah proses yang lebih tinggi merupakan pertukaran antara memungkinkan Apache untuk menggunakan sumber daya sistem yang tersedia atau tidak. Jika Anda ingin menjaga sistem server yang stabil (bukan situs web!) Di bawah kondisi "serangan", pertahankan angkanya tetap rendah. Jika Anda ingin Apache membantu Anda menggunakan sumber daya sistem (CPU, RAM) saat diperlukan, pilih angka yang lebih tinggi. Seberapa tinggi Anda dapat menghitung seperti diuraikan dalam jawaban yang diterima di atas, dan pada akhirnya dibatasi oleh daya CPU dan RAM yang tersedia.

(PS: Saya menyimpan bagian ConfigurationDirectives dari wiki proyek modwsgi di bawah bantal saya untuk membaca latar belakang seperti Apache. Juga pastikan untuk memahami dan memantau koneksi terbuka server Apache Anda .)