Saya bermaksud menggunakan VPS tunggal untuk menggunakan beberapa aplikasi CherryPy lalu lintas rendah sebagai subdirektori; misalnya: example.com/app1, example.com/app2, dll

Setelah meneliti tentang penyebaran WSGI, sepertinya metode yang disukai untuk menyebarkan aplikasi adalah dengan menggunakan server WSGI (Gunicorn, uWSGI, dll) dan NGinx dalam pengaturan reverse-proxy. Sepertinya terlalu banyak menggunakan dua server web secara bersamaan - terutama karena aplikasi CherryPy saya sendiri adalah server web - tetapi saya tidak ingin mengabaikan gagasan seperti yang muncul di mana-mana . Saya tentu bukan ahli jadi saya ingin membahasnya.

Saya melihat tiga opsi:

• Sebarkan CherryPy dengan sendirinya.
• Menyebarkan di bawah Gunicorn atau server WSGI lainnya.
• Menyebarkan di bawah server WSGI dan membalikkan proxy ke NGinx, yang tampaknya menjadi solusi semua orang.

Pertanyaan saya:

• Apa alasan utama saya melihat pola ini di mana-mana? Hanya nginx yang baik?
• Untuk aplikasi dengan lalu lintas rendah, apakah server asli CherryPy cukup baik, atau haruskah saya tidak mencobanya?

Setiap dan semua saran sangat dihargai, terima kasih.

Alasan setiap orang menempatkan nginx (atau server lain seperti Apache) di depan server aplikasi mereka adalah bahwa setiap orang memiliki konten statis seperti gambar, CSS dan JavaScript, dan persyaratan aneh yang unik untuk aplikasi mereka.

Server aplikasi Anda (CherryPy, gunicorn, apa pun) dioptimalkan untuk menjalankan aplikasi Anda dan melayani hasilnya. Meskipun server aplikasi juga dapat menyajikan konten statis, mereka hampir tidak pernah dioptimalkan dengan baik untuk tugas ini, karena ini sekunder untuk tujuan utama server aplikasi. (Beberapa server aplikasi juga akan membantu dengan memperkecil dan mengompresi CSS dan JS Anda, sehingga server web di depan dapat menyajikan sumber daya ini dengan lebih cepat.)

Selain itu, server web yang sebenarnya dapat melakukan lebih dari sekadar penyajian konten berkinerja tinggi. Hal-hal seperti caching, manipulasi header, penulisan ulang URL, geolokasi, dan banyak fitur lain yang hanya akan membengkak server aplikasi tanpa tujuan yang baik.

Biasanya Anda hanya akan menjalankan server aplikasi saat mengembangkan aplikasi, ketika Anda adalah satu-satunya pengguna, dan kinerja tidak menjadi masalah. Bahkan jika situs Anda memiliki traffic rendah, Anda ingin lebih cepat, bukan? Situs dengan lalu lintas rendah yang lambat biasanya tidak tumbuh menjadi situs dengan lalu lintas tinggi ...

Mengapa orang menempatkan Nginx di depan?

1. Nginx adalah server web yang tidak sinkron. Ini berarti tidak mendedikasikan utas atau proses per koneksi. Sebaliknya ia menggunakan perpustakaan polling socket yang disukai OS dan dengan demikian mampu menangani ratusan ribu koneksi. Mengapa Anda, sebagai pengembang aplikasi, peduli? Karena Nginx mendukung koneksi dan hanya meneruskan permintaan ke instance hulu CherryPy Anda ketika permintaan sepenuhnya dibaca. Sama untuk tanggapan. Dengan cara ini aplikasi CherryPy Anda, yang merupakan server berulir, di belakang Nginx dalam banyak hal, menjadi asinkron. Secara khusus, Anda melambaikan tangan ke masalah klien yang lambat dan memperlambat serangan loris DOS.
2. Nginx memiliki tingkat koneksi yang terbatas. Katakan, saya tidak ingin lebih dari 8 koneksi simultan dari IP yang sama.
3. CherryPy memiliki masalah SSL . Nginx tidak.
4. Python dapat mengirim bolak-balik hampir sama baiknya dengan C. Python zlibhanyalah pembungkus di sekitar C library. Tetapi karena Nginx menangani koneksi secara efektif, ide yang bagus untuk meringankan utas pekerja CherryPy Anda dari menyajikan konten statis dalam produksi dan hanya mendedikasikan pada konten dinamis.
5. Multiplexing beberapa instance CherryPy pada port, domain, path, dll. Umumnya tambahan fleksibilitas tingkat konfigurasi lain.

Apakah aman menggunakan CherryPy sendiri?

Menurut salah satu penulis asli, ya . Sebagian besar hal yang relevan dengan web dapat Anda lakukan dengan CherryPy sendiri.

CherryPy memiliki gagasan tentang suatu aplikasi dan Anda dapat melayani beberapa aplikasi dengan satu instance CherryPy. CherryPy juga dapat melayani aplikasi WSGI lainnya .

Menyebarkan CherryPy

Dalam penyebaran gaya * nix tradisional Anda menulis skrip init, daemonise proses Anda, lepaskan hak istimewanya, tulis PID-nya, dll. Ini bukan masalah besar ketika Anda memiliki beberapa instance CherryPy. Ketika Anda memiliki lusinan, menjadi membosankan dan masuk akal untuk menyerahkan manajemen proses ke Gunicorn atau uWGSI dan mengalihkan instance CherryPy Anda dari HTTP ke WSGI.

Saya menulis kerangka tutorial / proyek, cherrypy-webapp-skeleton , yang tujuannya adalah untuk mengisi kekosongan penerapan (tradisional) aplikasi CherryPy dunia nyata di Debian untuk pengembang web.

Bungkus

1. Lalu lintas rendah, tidak ada persyaratan khusus → CherryPy * 1 ⇐ HTTP ⇒ Client.
2. Lalu lintas tinggi, persyaratan khusus → CherryPy * n ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Client.
3. Lusinan instance CherryPy yang terpisah di server yang sama, sangat membutuhkan solusi berlebihan dari semua orang → CherryPy * n ⇐ WSGI ⇒ Gunicorn ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Client.