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


23

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.

Jawaban:


22

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.


Faktor penting lainnya untuk sejumlah proses / utas adalah berapa lama permintaan individu dapat ditangani dan keseluruhannya tersebar di semua jangka waktu yang mungkin diambil. Dengan kata lain, berapa banyak permintaan pada satu waktu perlu ditangani yang membutuhkan waktu respons lebih besar dari rata-rata. Jadi, itu tidak sesederhana hanya permintaan teoritis / detik karena dampak dari permintaan yang berjalan lebih lama itu bisa signifikan dan terlalu menentukan parameter konfigurasi keseluruhan. FWIW mod_wsgi 3.0 akan menyertakan beberapa pengumpulan statistik bawaan untuk mencoba dan mengambil data tentang ini untuk membantu konfigurasi.
Graham Dumpleton

@ Graham: Bacalah kembali jawaban saya, saya membahasnya secara mendetail. Permintaan / detik hanyalah kebalikan dari waktu respons, dan lebih mudah untuk dibagi dengan bilangan bulat req / detik daripada mengalikan dengan desimal.
womble

Anda tidak bisa fokus hanya pada respon kasus terburuk, atau hanya rata-rata dalam hal ini. Perlu ditimbang dengan cara berdasarkan persentase permintaan yang termasuk dalam periode waktu, yaitu, penyebaran di semua waktu yang mungkin diambil. Jika Anda benar-benar mengambil waktu respons kasus terburuk Anda, maka Anda akan datang dengan persyaratan yang tidak realistis. Masalahnya sangat sulit untuk mengetahui formula apa yang digunakan. Inilah sebabnya mengapa di mod_wsgi 3.0 akan ada pengumpulan statistik inbuilt yang melihat pemanfaatan utas dan untuk berapa persentase berdasarkan jumlah dan waktu yang digunakan sejumlah utas dalam satu waktu.
Graham Dumpleton

3
Masalahnya mungkin bahwa Anda hanya melihat proses di mana saya khawatir tentang bagaimana masing-masing thread menggunakan faktor untuk itu dan itu tidak sesederhana itu. Dengan kata lain, arahan WSGIDaemonProcess menunjukkan 5 proses di mana setiap proses secara default menggunakan 15 utas. Seperti yang saya baca dalam deskripsi Anda, ia mengasumsikan proses berulir tunggal. Jika tidak, tunjukkan kepada saya bagaimana model Anda melayani utas plus masalah pertikaian / penskalaan di sekitar GIL. Jadi, pastikan bahwa deskripsi Anda hanya valid untuk proses berulir tunggal dan saya tidak akan berdebat.
Graham Dumpleton

2
Bukankah "multithreaded-Apache + multiprocess-wsgi" mendekati taruhan terbaik sampai Anda 99% yakin bahwa kode Python Anda dan semua dependensinya aman untuk digunakan?
Tomasz Zieliński

9

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 .)


Pos yang bagus, tetapi mengapa Anda tidak menetapkan jumlah utas? Karena Python GIL meniadakan banyak keuntungan dari utas, saya menganggap Anda ingin memiliki lebih banyak proses daripada utas, tetapi apakah ada keuntungan untuk menentukan jumlah utas?
Cerin

Jumlah standar threadsadalah 15 sesuai dengan dokumentasi . Saya tidak berpikir ada keuntungan untuk menentukan secara eksplisit. Bahkan, saya ingat telah meninggalkannya karena suatu alasan: Ada beberapa posting di SO atau bagian dari beberapa dokumentasi yang merekomendasikan untuk menghilangkan nilai untuk menghindari efek samping (Saya tahu, itu terdengar aneh). Sayangnya, saya tidak menemukan sumber itu sekarang. Untuk sisa pertanyaan Anda (GIL), Anda mungkin lebih ahli daripada saya, maaf.
Peterino 3-15

Terima kasih atas konfigurasi empiris ini. Namun, ingatlah bahwa menurut pos ini You should never use maximum-requests in a production system unless you understand the implications and have a specific temporary need.
raratiru
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.