Webrick sebagai server produksi vs. Thin atau Unicorn?

117

Sepertinya sudah dianggap biasa bahwa Anda tidak boleh menggunakan Webrick sebagai server produksi, tetapi saya tidak dapat menemukan tempat yang menyebutkan alasannya. Konsensusnya tampaknya: "Webrick baik-baik saja untuk pengembangan, tetapi Thin atau Unicorn adalah pilihan untuk produksi, titik."

Saya memang mencari beranda Thin server dan berbicara tentang permintaan / detik tetapi saya tidak begitu mengerti grafik karena tidak ada anotasi.

Adakah yang bisa memberi tahu saya mengapa saya harus menggunakan Thin atau Unicorn dibandingkan dengan Webrick? Juga apakah ada manfaat menggunakan Webrick untuk pengembangan? Saya telah menggunakan Webrick karena dilengkapi dengan rel, dan saya pikir seharusnya ada alasan mengapa ini default.

Saya menggunakan Heroku.

— Vlad
sumber

Ini lambat jika dibandingkan dengan orang lain seperti Mongrel.

— Uday

38

Ken, saya benar-benar tidak menanyakan pertanyaan ini untuk memperdebatkan apa pun. Saya benar-benar ingin tahu jawabannya karena saya tidak dapat menemukan statistik nyata di mana pun, ketika semua orang menerima begitu saja Webrick lebih rendah. Saya tidak berafiliasi dengan salah satu pihak tersebut dan debat yang Anda sebutkan adalah pertanyaan yang saya ajukan karena rasa ingin tahu yang tulus. Bagaimana saya bisa mengubah pertanyaan agar tidak terlihat seperti itu?

— Vlad

24

Ini pertanyaan yang bagus.

— justingord

29

Pertanyaan seperti ini TIDAK boleh ditutup. Mereka berguna dan bermanfaat. Semua polisi konten yang ditunjuk sendiri harus mundur.

— Ken Smith

22

Saya menemukan ini dengan googling "Mengapa tidak menggunakan WEBrick dalam produksi?" karena itu pertanyaan yang ingin saya jawab. Saya tidak bermaksud menggunakan WEBrick dalam produksi, tetapi saya merasa menjengkelkan bahwa semua orang berkata, "Karena ini jelas bukan Untuk Produksi®." Ini benar-benar tidak terlalu jelas — jika demikian, orang tidak akan meneliti pertanyaan sebelum akhirnya bertanya di StackOverflow, seperti yang diindikasikan oleh @Vlad. Jawaban yang diterima sangat membantu; setidaknya menunjukkan beberapa fitur yang hilang. Pada dasarnya, bersikeras bahwa pertanyaan ditutup karena menurut Anda pertanyaan tersebut diperdebatkan tanpa memberikan jawaban Anda sendiri tidak akan membantu.

— Justin Force

42

Beberapa alasan penting

itu tertulis di Ruby (lihat http://github.com/ruby/ruby/tree/trunk/lib/webrick )
Diedit, ia tidak memiliki banyak fitur yang biasanya dibutuhkan situs web produksi, seperti banyak pekerja (khususnya, pra-percabangan, manajemen siklus hidup, penanganan asinkron, dll), pengalihan, penulisan ulang, dll.

Ketika saya menyebutkan pengalihan / penulisan ulang, saya mengacu pada fakta bahwa menggunakan Webrick, Anda harus menangani penulisan ulang pada lapisan yang berbeda (Rack, Sinatra, Rails, kode Webrick kustom, dll). Ini mengharuskan Anda untuk menjalankan "penangan" ruby ekstra untuk menjalankan kode penulisan ulang Anda. Untuk situs dengan lalu lintas rendah, ini mungkin baik-baik saja karena Anda mungkin memiliki proses pemanasan sebelumnya yang belum melakukan apa pun. Namun, untuk situs dengan lalu lintas yang lebih tinggi, ini adalah beban tambahan pada server untuk sesuatu yang dapat ditangani oleh server ujung depan (Apache, Nginx, dll) tanpa menjalankan Ruby *, dan mungkin lipat lebih cepat.

* misalnya, jika Anda menjalankan di belakang penyeimbang beban, Anda dapat merutekan semua lalu lintas penulisan ulang ke server yang tidak memasang ruby, dan membiarkan server utama Anda hanya mengelola lalu lintas utama. Lalu lintas penulisan ulang ini mungkin disebabkan oleh perubahan situs untuk SEO, atau sesuatu yang serupa. Kasus lain adalah situs yang memiliki banyak komponen, dan mungkin satu bagian adalah Rails, yang lainnya adalah PHP, dan penulisan ulang diperlukan untuk keduanya (yaitu menulis ulang jalur PHP lama ke Rails)

— Jim Deville
sumber

Bukankah mungkin menggunakan delay_job untuk menangani banyak pekerja di Heroku, terlepas dari server mana yang Anda gunakan?

— Vlad

Ya, delay_job tidak terkait dengan Webrick, kecuali pekerjaan Anda menggunakan API Webrick (yang sejujurnya berbau kode karena berpasangan).

— Jim Deville

Saya mengacu pada pengalihan di luar tumpukan Ruby. Seperti pengalihan gaya mod_rewrite. Secara teknis, Anda dapat mengarahkan ulang ke dalam Rack, atau Rails, atau, mungkin bahkan Webrick (saya bisa saja salah), tetapi itu membutuhkan mulai ruby, yang relatif lambat vs Apache atau Nginx

— Jim Deville

1

@JimDeville - Unicorn juga ditulis di Ruby

— Yarin

1

github.com/defunkt/unicorn/tree/master/ext/unicorn_http sebagian besar Unicorn ada di C

— Jim Deville

4

WEBrick juga tidak dapat menangani URI yang lebih lama, jika melebihi 2083 karakter, Anda akan melihat error. Tipis tidak memiliki masalah ini, yang membuatnya lebih unggul - sudah dalam pengembangan.

— Michael Schmitz
sumber

Juga Webrick kehilangan koneksi dan mati otomatis ketika menurut pengalaman saya, saya sedang mengembangkan perangkat lunak dan ketika saya memilih WeBRICK di Heroku PaaS, mati otomatis dikompensasi oleh kecepatan tinggi auto-turn (diaktifkan melalui arsitektur Heroku secara otomatis )

— Daniel Antonio Nuñez Carhuayo

3

Saya tidak terlalu suka memperumit hal-hal sederhana dan pengoptimalan yang prematur. WEBrick dapat digunakan dalam produksi dengan syarat situs web dengan lalu lintas rendah. Sebagian besar aplikasinya adalah.

Jika situs Anda melakukan sesuatu yang membutuhkan waktu, misalnya mengirim email atau menghasilkan file PDF, Anda harus membuat WEBrick multi-threaded . Anda ingin menangani banyak permintaan sekaligus.

— Nowaker
sumber

1

Ini memiliki beberapa masalah keamanan di masa lalu, tetapi tampaknya alasan utamanya adalah sangat lambat dibandingkan dengan server yang dimaksudkan untuk produksi.

— Brett Henning
sumber

4

Pernahkah Anda melihat perbandingan stat? Saya juga mendengar orang-orang mengatakan itu (dan mungkin benar) tetapi tidak dapat benar-benar menemukan perbandingan statistik nyata di mana pun di web ...

— Vlad

3

Saya tidak berpikir ada orang yang benar-benar membandingkan Webrick karena tidak dimaksudkan sebagai server produksi. Unicorn, Tipis atau Penumpang didukung dengan baik dan pilihan yang jauh lebih baik

— Jim Deville

0

Kelemahan terbesar webrick saat berjalan dalam mode produksi adalah server web proses tunggal berulir tunggal, yang berarti bahwa ia hanya mampu melayani satu permintaan http tunggal pada satu waktu.

— Artur Beljajev
sumber

Ini bukan single threaded. Atau dengan cara yang sama seperti bahasa skrip modern diterapkan (dengan GIL). Tetapi akses database dan IO di webrick sepenuhnya multithread.

— Lothar