Webrick เป็นเซิร์ฟเวอร์การผลิตเทียบกับ Thin หรือ Unicorn?

117

ดูเหมือนว่าคุณจะต้องไม่ใช้ Webrick เป็นเซิร์ฟเวอร์ที่ใช้งานจริง แต่ฉันไม่พบที่ใดที่กล่าวถึงสาเหตุ ฉันทามติน่าจะเป็น: "Webrick สามารถพัฒนาได้ แต่ Thin หรือ Unicorn เป็นตัวเลือกสำหรับการผลิตช่วงเวลา"

ฉันค้นหาหน้าแรกของเซิร์ฟเวอร์ Thin และมันพูดถึงคำขอ / วินาที แต่ฉันไม่เข้าใจกราฟจริงๆเนื่องจากไม่มีคำอธิบายประกอบ

ใครช่วยบอกฉันหน่อยได้ไหมว่าทำไมฉันจึงควรใช้ Thin หรือ Unicorn เทียบกับ Webrick? การใช้ Webrick ในการพัฒนายังมีประโยชน์อีกหรือไม่? ฉันใช้ Webrick มาพร้อมกับรางและฉันคิดว่าควรมีเหตุผลว่าทำไมถึงเป็นค่าเริ่มต้น

ฉันกำลังใช้ Heroku อยู่ข้างทาง

— Vlad
แหล่งที่มา

ช้าเมื่อเทียบกับคนอื่นเช่น Mongrel

— uday

38

เคนฉันไม่ได้ถามคำถามนี้เพื่อถกเถียงอะไรเลย ฉันต้องการทราบคำตอบอย่างแท้จริงเพราะฉันไม่พบสถิติที่แท้จริงจากที่ใดเมื่อทุกคนยอมรับว่า Webrick นั้นด้อยกว่า ฉันไม่ได้มีส่วนเกี่ยวข้องกับบุคคลเหล่านั้นและการอภิปรายที่คุณกล่าวถึงเป็นคำถามที่ฉันถามด้วยความอยากรู้อยากเห็นอย่างแท้จริง ฉันจะเรียบเรียงคำถามใหม่ให้ดูไม่เป็นอย่างนั้นได้อย่างไร

— Vlad

24

นี่เป็นคำถามที่ดี

— justingordon

29

คำถามเช่นนี้ไม่ควรปิด มีประโยชน์และเป็นประโยชน์ ตำรวจเนื้อหาที่ได้รับการแต่งตั้งเองทั้งหมดควรถอยออกไป

— Ken Smith

22

ฉันพบสิ่งนี้โดย googling "ทำไมไม่ใช้ WEBrick ในการผลิต" เพราะเป็นคำถามที่ฉันต้องการคำตอบ ฉันไม่ได้ตั้งใจจะใช้ WEBrick ในการผลิต แต่ฉันคิดว่ามันน่ารำคาญที่ทุกคนพูดว่า "เพราะมันไม่ใช่สำหรับProduction®ชัด ๆ " มันไม่ค่อยชัดเจนเท่าไหร่ - ถ้าเป็นเช่นนั้นผู้คนจะไม่ค้นคว้าคำถามก่อนที่จะถามใน StackOverflow ในที่สุดเนื่องจาก @Vlad ระบุว่าเขาทำ คำตอบที่ยอมรับมีประโยชน์ อย่างน้อยก็ชี้ให้เห็นคุณสมบัติบางอย่างที่ขาดหายไป โดยทั่วไปแล้วการยืนยันว่าคำถามถูกปิดเพราะคุณคิดว่ามันเป็นเรื่องที่สงสัยโดยไม่ได้ให้คำตอบของคุณเองนั้นไม่เป็นประโยชน์

— Justin Force

42

เหตุผลสำคัญสองประการ

มันเขียนด้วย Ruby (ดูhttp://github.com/ruby/ruby/tree/trunk/lib/webrick )
แก้ไขแล้วไม่มีคุณสมบัติมากมายที่เว็บไซต์การผลิตมักต้องการเช่นพนักงานหลายคน (โดยเฉพาะอย่างยิ่งการตีขึ้นล่วงหน้าการจัดการวงจรชีวิตการจัดการแบบอะซิงโครนัส ฯลฯ ) การเปลี่ยนเส้นทางการเขียนใหม่ ฯลฯ

เมื่อฉันพูดถึงการเปลี่ยนเส้นทาง / เขียนใหม่ฉันหมายถึงข้อเท็จจริงที่ว่าการใช้ Webrick คุณต้องจัดการการเขียนซ้ำในเลเยอร์อื่น (Rack, Sinatra, Rails, โค้ด Webrick ที่กำหนดเอง ฯลฯ ) สิ่งนี้ทำให้คุณต้องหมุน "ตัวจัดการ" ทับทิมพิเศษเพื่อดำเนินการเขียนโค้ดใหม่ของคุณ สำหรับไซต์ที่มีการเข้าชมต่ำอาจเป็นเรื่องปกติเนื่องจากคุณอาจมีกระบวนการอุ่นเครื่องไว้ล่วงหน้าซึ่งไม่ได้ทำอะไรเลย อย่างไรก็ตามสำหรับไซต์การรับส่งข้อมูลที่สูงขึ้นนี่เป็นภาระเพิ่มเติมบนเซิร์ฟเวอร์สำหรับบางสิ่งที่เซิร์ฟเวอร์ส่วนหน้า (Apache, Nginx ฯลฯ ) สามารถจัดการได้โดยไม่ต้องหมุน Ruby * และอาจเป็นคำสั่งขนาดที่เร็วกว่า

* ตัวอย่างเช่นหากคุณกำลังทำงานอยู่หลังตัวโหลดบาลานเซอร์คุณสามารถกำหนดเส้นทางการรับส่งข้อมูลที่เขียนซ้ำทั้งหมดไปยังเซิร์ฟเวอร์ที่ไม่ได้ติดตั้งทับทิมและปล่อยให้เซิร์ฟเวอร์หลักของคุณจัดการเฉพาะการรับส่งข้อมูลหลักเท่านั้น การเข้าชมที่เขียนซ้ำนี้อาจเกิดจากการเปลี่ยนแปลงไซต์สำหรับ SEO หรือสิ่งที่คล้ายกัน อีกกรณีหนึ่งจะเป็นไซต์ที่มีหลายองค์ประกอบและอาจเป็นส่วนหนึ่งคือ Rails อีกส่วนหนึ่งคือ PHP และจำเป็นต้องเขียนซ้ำสำหรับทั้งสองอย่าง (เช่นเขียนเส้นทาง PHP เก่าไปยัง Rails)

— จิมเดอวิลล์
แหล่งที่มา

เป็นไปไม่ได้ที่จะใช้ delay_job เพื่อจัดการคนงานหลายคนบน Heroku ไม่ว่าคุณจะใช้เซิร์ฟเวอร์ใด?

— Vlad

ใช่ delay_job ไม่เกี่ยวข้องกับ Webrick เว้นแต่งานของคุณจะใช้ Webrick APIs (ซึ่งเป็นรหัสที่มีกลิ่นเหมือนคู่กัน)

— Jim Deville

ฉันหมายถึงการเปลี่ยนเส้นทางภายนอกสแต็ก Ruby เช่นเดียวกับการเปลี่ยนเส้นทางสไตล์ mod_rewrite ในทางเทคนิคคุณสามารถเปลี่ยนเส้นทางภายใน Rack หรือ Rails หรือบางทีแม้แต่ Webrick (ฉันอาจจะผิด) แต่ต้องใช้ทับทิมเริ่มต้นซึ่งค่อนข้างช้าเมื่อเทียบกับ Apache หรือ Nginx

— Jim Deville

1

@JimDeville - Unicorn เขียนด้วย Ruby

— Yarin

1

github.com/defunkt/unicorn/tree/master/ext/unicorn_httpยูนิคอร์นส่วนใหญ่อยู่ใน C

— Jim Deville

4

นอกจากนี้ WEBrick ยังไม่สามารถจัดการ URI ที่ยาวกว่านี้ได้หากเกิน 2083 ตัวอักษรคุณจะพบข้อผิดพลาด Thin ไม่มีปัญหาเหล่านี้ซึ่งทำให้เหนือกว่า - อยู่ระหว่างการพัฒนาแล้ว

— Michael Schmitz
แหล่งที่มา

นอกจากนี้ Webrick ยังขาดการเชื่อมต่อและปิดอัตโนมัติเมื่อด้วยประสบการณ์ของฉันฉันกำลังพัฒนาซอฟต์แวร์และเมื่อฉันเลือก WeBRICK ใน Heroku PaaS การปิดอัตโนมัติจะได้รับการชดเชยด้วยการเปิดอัตโนมัติความเร็วสูง (ยิงผ่านสถาปัตยกรรมอัตโนมัติของ Heroku )

— Daniel Antonio Nuñez Carhuayo

3

ฉันไม่ชอบการซับซ้อนและการเพิ่มประสิทธิภาพก่อนเวลาอันควร สามารถใช้ WEBrick ในการผลิตได้หากเป็นเว็บไซต์ที่มีการเข้าชมต่ำ ส่วนใหญ่เป็นแอพพลิเคชั่น

หากเว็บไซต์ของคุณทำอะไรบางอย่างที่ต้องใช้เวลาเช่นส่งอีเมลหรือสร้างไฟล์ PDF, คุณควรจะทำ WEBrick แบบมัลติเธรด คุณต้องการจัดการคำขอหลายรายการพร้อมกัน

— Nowaker
แหล่งที่มา

1

ในอดีตมีปัญหาด้านความปลอดภัย แต่ดูเหมือนว่าสาเหตุใหญ่คือมันช้ามากเมื่อเทียบกับเซิร์ฟเวอร์ที่มีไว้สำหรับการผลิต

— Brett Henning
แหล่งที่มา

4

คุณเคยเห็นการเปรียบเทียบสถิติหรือไม่? ฉันยังได้ยินคนพูดแบบนั้น (และอาจเป็นเรื่องจริง) แต่ไม่สามารถหาการเปรียบเทียบสถิติที่แท้จริงได้จากเว็บ ...

— Vlad

3

ฉันไม่คิดว่าจะมีใครเปรียบเทียบ Webrick จริง ๆ เพราะมันไม่ได้ตั้งใจจะเป็นเซิร์ฟเวอร์การผลิต Unicorn, Thin หรือ Passenger ได้รับการสนับสนุนอย่างดีและตัวเลือกที่ดีกว่ามาก

— Jim Deville

0

จุดอ่อนที่ยิ่งใหญ่ที่สุดของ webrick เมื่อทำงานในโหมดการใช้งานจริงคือเว็บเซิร์ฟเวอร์แบบ single threaded แบบ single process ซึ่งหมายความว่าสามารถตอบสนองคำขอ http ครั้งละหนึ่งรายการเท่านั้น

— Artur Beljajev
แหล่งที่มา

มันไม่ได้เป็นเธรดเดียว หรือเป็นไปในลักษณะเดียวกับที่ใช้ภาษาสคริปต์สมัยใหม่ (ด้วย GIL) แต่การเข้าถึงฐานข้อมูลและ IO ใน webrick เป็นแบบมัลติเธรดอย่างสมบูรณ์

— Lothar