Pekan lalu, terjemahan dari artikel yang berusia dua tahun diterbitkan. Analisis Kinerja Server WSGI: Bagian Dua , di mana uWSGI kehilangan ketenaran dengan tidak patut.

Sangat mendesak untuk memeriksa kembali tes!

Tujuan

Saya telah menggunakan uWSGI sejak lama, dan saya ingin menunjukkan bahwa itu tidak seburuk yang dijelaskan dalam tes 2016.
Awalnya, saya hanya ingin mereproduksi tes, dan mencari tahu apa yang salah dengan uWSGI.
Tidak ada versi paket dan modul yang digunakan dalam kode .

Karenanya, untuk menjalankan tes dan mendapatkan hasil yang serupa - itu tidak berhasil.
Berikutnya adalah pencarian saya untuk menjalankan tes dan membandingkan hasilnya pada grafik.
Atas permintaan pembaca, Unit NginX telah ditambahkan.

Langkah-langkah

wrk 4.1.0

Temukan spesifikasi , tempel , kumpulkan
Informasi ditambahkan ke readme.rd.

statistik buruh pelabuhan

Selama 2 tahun, output statistik telah berubah.

Kolom NAME kedua ditambahkan, dan ini memecah parser statistik.

Agar tidak mengalami masalah serupa dalam dua tahun, kami akan menggunakan output yang diformat:

 - docker stats > "$BASE/$1.$2.stats" & + docker stats --format "{{.CPUPerc}} {{.MemUsage}}" > "$BASE/$1.$2.stats" & 

Dan karenanya, kita akan menyederhanakan sedikit kode parser.

debian

Sekarang gambar debian terbaru adalah versi 9.5 , tampilkan ini di Dokerfile:

 - FROM debian + FROM debian:9.5 

Pada April 2016, versi terbaru adalah 8.4

Namun demikian, Apache tetap hampir sama: sekarang versi Apache adalah 2.4.25, dan pada 2016 itu adalah Apache 2.4.10.

tornado ceri uwsgi gunicorn bjoern meinheld mod_wsgi

Tidak masuk akal untuk mengatakan bahwa modul telah berubah.
Tentukan versi saat ini:

 - RUN pip install cherrypy tornado uwsgi gunicorn bjoern meinheld mod_wsgi + RUN pip install cherrypy==17.4.0 \ + uwsgi==2.0.17.1 \ + gunicorn==19.9.0 \ + bjoern=2.2.3 \ + meinheld==0.6.1 \ + mod_wsgi==4.6.5 

Apa yang dilakukan tornado di sana, di mana peluncuran file wsgi untuk meluncurkan tornado? Hapus artefak.
Tidaklah buruk untuk menempatkan ini di requirement.txt terpisah, tetapi untuk sekarang mari kita biarkan seperti itu.

cherrypy -> cheroot.wsgi

Seperti yang ditunjukkan di atas, versi saat ini adalah 17.4.0.
Pada April 2016, versi v5.1.0 mungkin digunakan.
Dan pada 2017, perubahan terjadi pada versi 9.0 , yang memengaruhi impor server:

 - from cherrypy import wsgiserver - server = wsgiserver.CherryPyWSGIServer( + from cheroot.wsgi import Server as WSGIServer + server = WSGIServer( 

Kesalahan soket: baca 100500

Setelah perubahan yang dijelaskan di atas, uji penuh pertama diluncurkan.
Hasilnya bagus: uwsgi tidak menghasilkan 3 ... 200, tetapi 7500 ... 5000 permintaan per detik.
Tetapi setelah pemeriksaan rinci dari grafik yang diperoleh, ternyata wrk mendeteksi semua jawaban sebagai kesalahan pembacaan.

Setelah memeriksa selusin kunci startup uwsgi, ternyata tidak ada kesalahan ketika menyalakan http1.1: --http-keepalive dan --http11-socket .
Selain itu, yang pertama memberikan 7.500 ... 5.000 permintaan per detik, dan yang stabil 29 ribu!

apa yang telah berubah di uWSGI saat ini

Kemungkinan besar pada Agustus 2016 versi uWSGI 2.0.12 (20151230) digunakan.
Setelah, pada bulan Mei, uWSGI 2.0.13 dirilis .

Ini adalah acara yang sangat penting, tetapi tidak menyelesaikan masalah kinerja menurut versi wrk hingga 2018, dengan rilis uWSGI 2.0.16 :

Dukungan HTTP / 1.1 porting belakang (--http11-socket) dari 2.1

Inilah mengapa uWSGI direkomendasikan untuk digunakan dengan NginX,
Dan mengapa ini penting dalam rangka artikel bisa dipahami dari tiket ini pada 2012.

Lalu mengapa hasilnya seperti itu

Saya mencoba versi berikut:

• 2.0.12 untuk debian 8.4, pada sembilan tidak akan karena openssl baru.
• 2.0.13 ... 2.0.17 untuk debian 8.4 dan 9.5

Tapi saya tidak bisa mendapatkan hasil yang buruk seperti 3 ... 200 kueri per detik.
Perhatian tertuju pada jalur peluncuran aplikasi:

uwsgi --http: 9808 --plugin python2 --wsgi-file app.py --proses ...

Menentukan plug-in menunjukkan instalasi uwsgi dari repositori, bukan pip.
Ini mungkin menunjukkan bahwa penulis tidak memiliki pengalaman yang diperlukan dengan tumpukan ini.

Karena itu, saya mengakui beberapa kemungkinan:

• pengujian masing-masing server uwsgi dilakukan secara terpisah, pada waktu yang berbeda.
• Ada beberapa konflik antara versi sistem uwsgi dan diinstal melalui pip.
• Versi penulis pada tahun 2016, memiliki beberapa fitur untuk bekerja di http1.0
• uwsgi memulai dengan serangkaian opsi yang berbeda
• artikel khusus, gambar dari langit-langit.

Apa hasilnya sekarang

uWSGI pada grafik adalah beberapa:
Dua uWSGI pertama dan uWSGIbase (v2.0.17.1) dijalankan dalam tes panjang, dengan pesaing mereka, dengan parameter:
--http11 :9808 --processes 5 --threads 2 --enable-threads .
--http11 :9808 --processes 5 .
Seperti yang telah ditunjukkan oleh praktik, tidak ada perbedaan kualitatif untuk tes aplikasi tiruan.

Dan, secara terpisah, versi 2016 uWSGI:
uWSGI-v2.0.12th-old dan uWSGI-v2.0.12nt-old - masing-masing v2.0.12 dengan dan tanpa utas dalam wadah debian 8.4.
--http :9808 --http-keepalive --processes 5 --threads 2 --enable-threads
--http :9808 --http-keepalive --processes 5

uWSGI menempati posisi ke-2, tanpa mengurangi hasil dengan meningkatnya beban.
Di tempat ketiga adalah Unit NginX.

Di segmen rendah, uWSGI-v2.0.12 adalah yang terbaik, bahkan dengan peningkatan beban.

Di sini kita melihat bagaimana Unit tidak menunjukkan sisi terbaiknya.

uWSGI dan CherryPy tidak diragukan lagi adalah pemenang dalam latensi.

Gambar ini mirip dengan 2016.

Di sini kita melihat berapa umur uWSGI memakan memori dengan meningkatnya beban.
Unit juga meningkatkan konsumsi memori secara linear.

Dan uWSGI baru, gunicorn, mod_wsgi - percaya diri "menjaga bar", dan itu mengatakan banyak.

UWSGI lama mulai mendapatkan kesalahan tajam setelah 300 koneksi terbuka.

Unit dan CherryPy - tidak ada kesalahan!
Bjoern mulai menyumbang dengan 1000 senyawa.
Tetapi dengan keanehan uWSGI baru, mulai 200 koneksi, kami mendapatkan 50 kesalahan, dan jumlahnya tidak lagi meningkat. Poin ini membutuhkan pertimbangan terperinci.

Semua data dikumpulkan di sini.
Semua perubahan kode dapat dilihat dalam RP .

Kesimpulan

uWSGI tidak terlalu buruk, atau bahkan sangat bagus!
Jika Anda tidak menyukai hasil tes WRK, coba gunakan alat lain.