Gunicorn: Beberapa cara untuk melayani banyak aplikasi WSGI melalui instance gunicorn yang sama.

Dibuat pada 29 Mar 2010 · 7Komentar · Sumber: benoitc/gunicorn

Menurut Anda apakah ide yang baik jika kita memiliki beberapa cara untuk menjalankan banyak aplikasi melalui instance gunicorn yang sama, sehingga mereka menggunakan interpreter python yang sama.
Setidaknya bagi saya, ini akan sangat berguna, karena akan menghemat banyak RAM, karena saya memiliki banyak aplikasi kecil (dengan beban sangat rendah) yang berjalan di mesin yang sama.

Add Example

Sumber

loxs

Komentar yang paling membantu

Saya harus setuju dengan jbergstroem bahwa ini bukan milik inti. Tapi saya melanjutkan dan menambahkan contoh yang menguraikan bagaimana Anda dapat melakukannya dengan Routes:

http://github.com/benoitc/gunicorn/blob/master/examples/multiapp.py

davisp pada 10 Apr 2010

👍3

Semua 7 komentar

Saya pikir perilaku semacam ini paling baik diselesaikan oleh pengguna akhir. Ada perbedaan nyata dalam cara gunicorn bekerja dengan "beberapa situs" dibandingkan dengan server web konvensional.
Saya akan menyarankan menggunakan beberapa pustaka python sederhana seperti werkzeug dan membuat dua aplikasi Anda merespons pada rute yang berbeda.

jbergstroem pada 29 Mar 2010

Saya harus setuju dengan jbergstroem bahwa ini bukan milik inti. Tapi saya melanjutkan dan menambahkan contoh yang menguraikan bagaimana Anda dapat melakukannya dengan Routes:

http://github.com/benoitc/gunicorn/blob/master/examples/multiapp.py

davisp pada 10 Apr 2010

👍3

alih-alih memiliki titik pemasangan tertentu per aplikasi, apakah mungkin untuk memiliki contoh dengan Host virtual berdasarkan nama?

sebest pada 19 Jun 2010

Ya, itu sangat mungkin. Anda dapat menulis pemetaan environ['HTTP_HOST'] sepele ke aplikasi.

temoto pada 24 Jun 2010

Saya pikir ini bisa dibangun di gunicorn, bagaimana menurut Anda?

sebest pada 24 Jun 2010

Ini bisa menjadi bagian opsional dari gunicorn, seperti hal-hal kontribusi, ya.

Saya pikir akan lebih baik sebagai aplikasi multiplexor mandiri dengan konfigurasi terpisah. Spesialisasi Django/Paste juga harus ada di sana. Seperti ini:

$ gunicorn wsgi_multi django:project1 myblog.wsgi:wsgi_app anotherapp.foo

Di sini, gunicorn hanya menjalankan satu aplikasi wsgi_multi, argumen lain diteruskan ke sana melalui beberapa API khusus. Atau melalui config atau entah bagaimana.

temoto pada 24 Jun 2010

Saya menghabiskan banyak waktu mencoba menulis sesuatu seperti yang disarankan dalam tiket ini. Pertama saya mencoba memiliki kode yang mengaktifkan virtualenv berdasarkan HTTP_HOST. Ternyata Anda benar-benar tidak dapat menonaktifkan virtualenvs dengan python murni, jadi itu mencuci.

Kemudian saya berpikir: mungkin kita hanya dapat memiliki persyaratan bahwa itu adalah satu virtualenv tunggal, jadi saya menulis kode untuk beralih ke aplikasi WSGI yang berbeda berdasarkan HTTP_HOST hanya untuk mengetahui bahwa Anda tidak dapat menjalankan dua aplikasi Django secara berdampingan karena Django menyimpan benar-benar menakjubkan jumlah variabel global di mana-mana.

Jadi pada dasarnya, apa yang saya katakan adalah tidak semua semudah atau bahkan layak seperti yang disarankan di atas.

Mungkin lebih layak untuk melakukan semacam penyeimbangan beban di mana pekerja berjalan di lingkungan virtual yang berbeda tergantung pada aplikasi dan master gunicorn pusat memastikan bahwa aplikasi yang membutuhkan lebih banyak pekerja mendapatkannya? Mungkin tidak mudah atau menyenangkan untuk menulis :(

Saya benar-benar ingin Django dibersihkan untuk memungkinkan hal semacam ini...