คำว่า "การปรับใช้" สามารถมีความหมายสองประการขึ้นอยู่กับบริบท คุณยังสับสนบทบาทของ Apache / Nginx กับบทบาทของส่วนประกอบอื่น ๆ
บันทึกประวัติศาสตร์: บทความนี้เขียนขึ้นครั้งแรกเมื่อวันที่ 6 พฤศจิกายน 2010 เมื่อระบบนิเวศเซิร์ฟเวอร์แอพ Ruby ถูก จำกัด ฉันได้อัปเดตบทความนี้เมื่อวันที่ 15 มีนาคม 2013 ด้วยการอัปเดตล่าสุดทั้งหมดในระบบนิเวศ
ข้อจำกัดความรับผิดชอบ : ฉันเป็นหนึ่งในผู้สร้าง Phusion Passenger ซึ่งเป็นหนึ่งในเซิร์ฟเวอร์แอป
Apache vs Nginx
พวกเขาทั้งเว็บเซิร์ฟเวอร์ พวกเขาสามารถให้บริการไฟล์คงที่ แต่ - ด้วยโมดูลที่เหมาะสม - ยังสามารถให้บริการแอปเว็บแบบไดนามิกเช่นที่เขียนใน PHP Apache เป็นที่นิยมมากขึ้นและมีคุณสมบัติมากขึ้น Nginx นั้นเล็กกว่าและเร็วกว่าและมีคุณสมบัติน้อยกว่า
ทั้ง Apache และ Nginx ไม่สามารถให้บริการเว็บแอพ Ruby out-of-the-box เพื่อที่คุณจะต้องใช้ Apache / Nginx ร่วมกับ Add-on บางชนิดตามที่อธิบายไว้ในภายหลัง
Apache และ Nginx สามารถทำหน้าที่เป็น reverse proxies ซึ่งหมายความว่าพวกเขาสามารถรับคำร้องขอ HTTP ขาเข้าและส่งต่อไปยังเซิร์ฟเวอร์อื่นซึ่งพูด HTTP เมื่อเซิร์ฟเวอร์นั้นตอบสนองด้วยการตอบสนอง HTTP Apache / Nginx จะส่งต่อการตอบกลับกลับไปยังลูกค้า คุณจะได้เรียนรู้ในภายหลังว่าทำไมสิ่งนี้จึงมีความเกี่ยวข้อง
Mongrel และเซิร์ฟเวอร์แอปที่ใช้งานจริงอื่น ๆ เทียบกับ WEBrick
Mongrel เป็น Ruby "application server": ในแง่ที่เป็นรูปธรรมนี่หมายความว่า Mongrel เป็นแอปพลิเคชั่นที่:
- โหลดแอป Ruby ของคุณภายในพื้นที่กระบวนการของตัวเอง
- ตั้งค่าซ็อกเก็ต TCP ช่วยให้สามารถสื่อสารกับโลกภายนอก (เช่นอินเทอร์เน็ต) Mongrel รับฟังคำร้องขอ HTTP บนซ็อกเก็ตนี้และส่งผ่านข้อมูลคำขอไปยัง Ruby web app
- จากนั้นเว็บแอป Ruby จะส่งคืนออบเจกต์ซึ่งอธิบายว่าการตอบสนองของ HTTP ควรเป็นอย่างไรและ Mongrel ดูแลการแปลงให้เป็นการตอบสนอง HTTP จริง (ไบต์จริง) และส่งกลับไปยังซ็อกเก็ต
อย่างไรก็ตาม Mongrel ค่อนข้างล้าสมัยทุกวันนี้จะไม่ได้รับการดูแล แอ็พพลิเคชันเซิร์ฟเวอร์ทางเลือกที่ใหม่กว่าคือ:
- ผู้โดยสาร Phusion
- ตัวยูนิคอน
- ผอม
- เสือพูมา
- ตรินิแดด (JRuby เท่านั้น)
- TorqueBox (JRuby เท่านั้น)
ฉันจะครอบคลุมพวกเขาในภายหลังและอธิบายว่าพวกเขาแตกต่างกันและจาก Mongrel อย่างไร
WEBrick ทำสิ่งเดียวกับ Mongrel แต่ความแตกต่างคือ:
- WEBrick ไม่เหมาะสำหรับการผลิตซึ่งแตกต่างจากทุกอย่างที่ฉันพูดถึงก่อนหน้านี้ WEBrick เขียนทั้งหมดใน Ruby Mongrel (และเซิร์ฟเวอร์แอปทับทิมอื่น ๆ ส่วนใหญ่) เป็นส่วนหนึ่งของ Ruby และส่วน C (ส่วนใหญ่เป็น Ruby) แต่ตัวแยกวิเคราะห์ HTTP ของมันจะถูกเขียนใน C เพื่อประสิทธิภาพ
- WEBrick ช้าลงและมีประสิทธิภาพน้อยลง มีการรั่วไหลของหน่วยความจำที่รู้จักและปัญหาการแยกวิเคราะห์ HTTP ที่รู้จัก
- WEBrick มักใช้เป็นเซิร์ฟเวอร์เริ่มต้นในระหว่างการพัฒนาเท่านั้นเนื่องจาก WEBrick รวมอยู่ใน Ruby โดยค่าเริ่มต้น ต้องติดตั้ง Mongrel และเซิร์ฟเวอร์แอปอื่นแยกต่างหาก ไม่แนะนำให้ใช้ WEBrick ในสภาพแวดล้อมการผลิต แต่ด้วยเหตุผลบางอย่าง Heroku เลือก WEBrick เป็นเซิร์ฟเวอร์เริ่มต้น พวกเขาใช้ Thin มาก่อนดังนั้นฉันจึงไม่รู้เลยว่าทำไมพวกเขาถึงเปลี่ยนเป็น WEBrick
แอพเซิร์ฟเวอร์และโลก
เซิร์ฟเวอร์แอปทับทิมปัจจุบันทั้งหมดพูด HTTP อย่างไรก็ตามเซิร์ฟเวอร์แอปบางตัวอาจสัมผัสโดยตรงกับอินเทอร์เน็ตที่พอร์ต 80 ในขณะที่เซิร์ฟเวอร์อื่นอาจไม่เปิดเผย
- แอพเซิร์ฟเวอร์ที่สามารถสัมผัสโดยตรงกับอินเทอร์เน็ต: Phusion Passenger, Rainbows
- แอพเซิร์ฟเวอร์ที่อาจไม่สามารถสัมผัสโดยตรงกับอินเทอร์เน็ต: Mongrel, Unicorn, Thin, Puma เซิร์ฟเวอร์แอปเหล่านี้ต้องอยู่ด้านหลังเว็บพร็อกซีเซิร์ฟเวอร์ย้อนกลับเช่น Apache และ Nginx
- ฉันไม่รู้เกี่ยวกับ Trinidad และ TorqueBox มากพอดังนั้นฉันจึงข้ามไป
ทำไมเซิร์ฟเวอร์แอปบางตัวต้องวางอยู่ด้านหลังพร็อกซีย้อนกลับ
- เซิร์ฟเวอร์แอปบางตัวสามารถจัดการ 1 คำขอได้พร้อมกันต่อกระบวนการเท่านั้น หากคุณต้องการจัดการคำขอ 2 รายการในเวลาเดียวกันคุณจำเป็นต้องเรียกใช้อินสแตนซ์เซิร์ฟเวอร์หลายแอปโดยแต่ละแอปจะให้บริการแอพ Ruby เดียวกัน กระบวนการเซิร์ฟเวอร์แอปชุดนี้เรียกว่าคลัสเตอร์เซิร์ฟเวอร์แอป (ดังนั้นชื่อ Mongrel Cluster, Thin Cluster ฯลฯ ) จากนั้นคุณต้องตั้งค่า Apache หรือ Nginx เพื่อย้อนกลับ proxy ไปยังคลัสเตอร์นี้ Apache / Nginx จะดูแลการกระจายคำร้องขอระหว่างอินสแตนซ์ในคลัสเตอร์ (เพิ่มเติมเกี่ยวกับเรื่องนี้ในหัวข้อ "I / O concurrency models")
- เว็บเซิร์ฟเวอร์สามารถบัฟเฟอร์การร้องขอและการตอบสนองปกป้องแอปเซิร์ฟเวอร์จาก "ไคลเอนต์ที่ช้า" - ไคลเอนต์ HTTP ที่ไม่ส่งหรือรับข้อมูลอย่างรวดเร็ว คุณไม่ต้องการให้เซิร์ฟเวอร์แอปของคุณไม่ทำอะไรเลยในขณะที่รอให้ลูกค้าส่งคำขอเต็มรูปแบบหรือรับการตอบกลับอย่างเต็มที่เพราะในช่วงเวลานั้นเซิร์ฟเวอร์แอปอาจไม่สามารถทำสิ่งอื่นได้ Apache และ Nginx ทำได้ดีมากในการทำสิ่งต่าง ๆ ในเวลาเดียวกันเพราะพวกเขามีหลายเธรดหรือเหตุการณ์
- เซิร์ฟเวอร์แอปส่วนใหญ่สามารถให้บริการไฟล์สแตติกได้ แต่ก็ไม่ค่อยดีเท่าไหร่ Apache และ Nginx สามารถทำได้เร็วขึ้น
- โดยทั่วไปผู้คนตั้งค่า Apache / Nginx เพื่อให้บริการไฟล์คงที่โดยตรง แต่การร้องขอไปข้างหน้าที่ไม่สอดคล้องกับไฟล์คงที่ไปยังเซิร์ฟเวอร์แอปมันเป็นแนวทางปฏิบัติด้านความปลอดภัยที่ดี Apache และ Nginx มีอายุมากและสามารถป้องกันแอปเซิร์ฟเวอร์จากคำขอที่เสียหาย (อาจเป็นอันตราย)
ทำไมเซิร์ฟเวอร์แอพบางตัวจึงสัมผัสกับอินเทอร์เน็ตโดยตรง
- Phusion Passenger นั้นเป็นสัตว์ร้ายที่แตกต่างจากเซิร์ฟเวอร์แอพอื่น ๆ ทั้งหมด หนึ่งในคุณสมบัติพิเศษของมันคือมันรวมเข้ากับเว็บเซิร์ฟเวอร์
- ผู้เขียน Rainbows เปิดเผยต่อสาธารณะว่าปลอดภัยที่จะเปิดเผยโดยตรงกับอินเทอร์เน็ต ผู้เขียนค่อนข้างมั่นใจว่าไม่มีช่องโหว่ในตัวแยกวิเคราะห์ HTTP (และที่คล้ายกัน) ถึงกระนั้นผู้เขียนก็ไม่รับประกันและบอกว่าการใช้งานนั้นเป็นความเสี่ยงเอง
แอปพลิเคชันเซิร์ฟเวอร์เปรียบเทียบ
ในส่วนนี้ฉันจะเปรียบเทียบเซิร์ฟเวอร์แอปพลิเคชันส่วนใหญ่ที่ฉันพูดถึง แต่ไม่ใช่ Phusion Passenger Phusion Passenger นั้นเป็นสัตว์ร้ายที่แตกต่างจากที่อื่น ๆ ฉันได้ละทิ้งตรินิแดดและ TorqueBox เพราะฉันไม่รู้จักพวกเขาดีพอ แต่พวกเขาก็มีความเกี่ยวข้องเฉพาะในกรณีที่คุณใช้ JRuby
- Mongrelเป็นกระดูกเปลือยสวย ดังกล่าวก่อนหน้า Mongrel เป็นกระบวนการหลายเธรดเดียวซึ่งมีประโยชน์ในคลัสเตอร์เท่านั้น ไม่มีการตรวจสอบกระบวนการ: หากกระบวนการในคลัสเตอร์ล้มเหลว (เช่นเนื่องจากข้อบกพร่องในแอป) ดังนั้นจึงต้องเริ่มต้นใหม่ด้วยตนเอง ผู้คนมักใช้เครื่องมือตรวจสอบกระบวนการภายนอกเช่น Monit และ God
- ยูนิคอร์นเป็นกิ่งก้านของ Mongrel สนับสนุนการตรวจสอบกระบวนการที่ จำกัด : หากกระบวนการขัดข้องกระบวนการนั้นจะเริ่มต้นใหม่โดยอัตโนมัติโดยกระบวนการหลัก มันสามารถทำให้กระบวนการทั้งหมดฟังบนซ็อกเก็ตที่ใช้ร่วมกันเดียวแทนซ็อกเก็ตที่แยกต่างหากสำหรับแต่ละกระบวนการ ทำให้การกำหนดค่าพร็อกซีย้อนกลับง่ายขึ้น เช่นเดียวกับ Mongrel เป็นกระบวนการหลายเธรดเดียว
- Thinใช้โมเดล I / O ที่มีเหตุการณ์โดยใช้ไลบรารี EventMachine นอกเหนือจากการใช้ตัวแยกวิเคราะห์ Mongrel HTTP มันไม่ได้อิงจาก Mongrel แต่อย่างใด โหมดคลัสเตอร์ไม่มีการตรวจสอบกระบวนการดังนั้นคุณต้องตรวจสอบข้อขัดข้อง ฯลฯ ไม่มีซ็อกเก็ตที่ใช้ร่วมกันแบบยูนิคอร์นดังนั้นแต่ละกระบวนการจะฟังบนซ็อกเก็ตของตัวเอง ในทางทฤษฎีแล้วโมเดล I / O ของ Thin ช่วยให้เกิดการทำงานพร้อมกันสูง แต่ในสถานการณ์ที่ใช้งานได้จริงที่สุดสำหรับ Thin นั้นหนึ่ง Thin จะสามารถจัดการกับ 1 คำร้องขอพร้อมกันได้เท่านั้นดังนั้นคุณยังต้องการคลัสเตอร์ เพิ่มเติมเกี่ยวกับคุณสมบัติพิเศษนี้ในส่วน "โมเดล I / O การทำงานพร้อมกัน"
- Pumaถูกแยกจาก Mongrel เช่นกัน แต่ต่างจากยูนิคอร์น Puma ถูกออกแบบมาให้มีหลายเธรดอย่างหมดจด ดังนั้นในปัจจุบันจึงไม่มีการสนับสนุนคลัสเตอร์ในตัว คุณต้องใช้ความระมัดระวังเป็นพิเศษเพื่อให้แน่ใจว่าคุณสามารถใช้ประโยชน์จากหลายคอร์ (เพิ่มเติมเกี่ยวกับเรื่องนี้ในส่วน "I / O โมเดลการทำงานพร้อมกัน")
- Rainbowsรองรับหลายรุ่นพร้อมกันผ่านการใช้ไลบรารี่ที่แตกต่างกัน
ผู้โดยสาร Phusion
Phusion Passenger นั้นแตกต่างจากของอื่นอย่างสิ้นเชิง Phusion Passenger รวมเข้ากับ Apache หรือ Nginx โดยตรงและสามารถเปรียบเทียบกับ mod_php สำหรับ Apache ได้ เช่นเดียวกับ mod_php อนุญาตให้ Apache ให้บริการแอป PHP, เกือบจะอย่างน่าอัศจรรย์, Phusion Passenger อนุญาตให้ Apache (และ Nginx!) ให้บริการแอพ Ruby, เกือบอย่างน่าอัศจรรย์. เป้าหมายของ Phusion Passenger คือการทำให้ทุกอย่างเพียงแค่ Work (tm) มีความยุ่งยากน้อยที่สุดเท่าที่จะทำได้
แทนที่จะเริ่มต้นกระบวนการหรือคลัสเตอร์สำหรับแอปของคุณและกำหนดค่า Apache / Nginx เพื่อให้บริการไฟล์สแตติกและ / หรือย้อนกลับคำขอพร็อกซี่ไปยังกระบวนการ / คลัสเตอร์ด้วย Phusion Passenger คุณจะต้อง:
- คุณแก้ไขไฟล์กำหนดค่าเว็บเซิร์ฟเวอร์และระบุตำแหน่งของไดเรกทอรี 'สาธารณะ' ของแอป Ruby ของคุณ
- ไม่มีขั้นตอนที่ 2
การกำหนดค่าทั้งหมดเสร็จสิ้นภายในไฟล์กำหนดค่าเว็บเซิร์ฟเวอร์ Phusion Passenger ทำให้ทุกอย่างเป็นไปโดยอัตโนมัติ ไม่จำเป็นต้องเริ่มคลัสเตอร์และจัดการกระบวนการ เริ่มต้น / หยุดกระบวนการเริ่มต้นใหม่เมื่อเกิดความผิดพลาด ฯลฯ - ทั้งหมดอัตโนมัติ เปรียบเทียบกับเซิร์ฟเวอร์แอปอื่น ๆ Phusion Passenger มีชิ้นส่วนที่เคลื่อนไหวน้อยกว่ามาก ความง่ายในการใช้งานนี้เป็นหนึ่งในเหตุผลหลักว่าทำไมคนถึงใช้ Phusion Passenger
ซึ่งแตกต่างจากเซิร์ฟเวอร์แอปอื่น ๆ Phusion Passenger นั้นเขียนด้วยภาษา C ++ เป็นหลักทำให้รวดเร็วมาก
นอกจากนี้ยังมีรุ่น Enterprise Phusion Passenger ซึ่งมีคุณสมบัติเพิ่มเติมมากมายเช่นการรีสตาร์ทแบบอัตโนมัติ, การสนับสนุนมัลติเธรด, การต่อต้านข้อผิดพลาดในการปรับใช้เป็นต้น
ด้วยเหตุผลข้างต้น Phusion Passenger ปัจจุบันเป็นแอพเซิร์ฟเวอร์ทับทิมที่ได้รับความนิยมสูงสุดมีกำลังมากกว่า 150,000 เว็บไซต์รวมถึงเว็บไซต์ขนาดใหญ่เช่น New York Times, Pixar, Airbnb และอื่น ๆ
Phusion Passenger เทียบกับเซิร์ฟเวอร์แอปอื่น
Phusion Passenger มีคุณสมบัติมากมายและให้ประโยชน์มากมายกับแอพเซิร์ฟเวอร์อื่น ๆ เช่น:
- ปรับจำนวนกระบวนการแบบไดนามิกตามปริมาณการใช้งาน เราใช้งานแอพ Rails จำนวนมากบนเซิร์ฟเวอร์ที่ จำกัด ทรัพยากรซึ่งไม่ได้เปิดเผยต่อสาธารณะและผู้คนในองค์กรของเราใช้เพียงไม่กี่ครั้งต่อวัน สิ่งต่าง ๆ เช่น Gitlab, Redmine เป็นต้น Phusion Passenger สามารถลดขั้นตอนเหล่านั้นลงเมื่อไม่ใช้งานและหมุนมันเมื่อใช้ กับเซิร์ฟเวอร์แอปอื่น ๆ กระบวนการทั้งหมดของคุณจะเปิดอยู่ตลอดเวลา
- เซิร์ฟเวอร์แอปบางตัวไม่สามารถทำงานได้ตามปริมาณงานที่กำหนด ตัวอย่างเช่น Unicorn ถูกออกแบบมาสำหรับการร้องขอที่ทำงานอย่างรวดเร็วเท่านั้น: ดูในส่วนของเว็บไซต์ Unicorn "เพียงแย่ลงในบางกรณี"
ปริมาณงานที่ยูนิคอร์นไม่ดีคือ:
- สตรีมเวิร์กโหลด (เช่นสตรีมมิ่ง Rails 4 live หรือสตรีมมิ่ง Rails 4 เทมเพลต)
- ปริมาณงานที่แอปทำการเรียก HTTP API
รุ่นไฮบริดของ I / O ในPhusion Passenger Enterprise 4หรือใหม่กว่าทำให้เป็นตัวเลือกที่ยอดเยี่ยมสำหรับปริมาณงานประเภทนี้
- เซิร์ฟเวอร์แอปอื่นต้องการให้ผู้ใช้เรียกใช้อย่างน้อยหนึ่งอินสแตนซ์ต่อแอปพลิเคชัน ในทางตรงกันข้าม Phusion Passenger รองรับแอพพลิเคชั่นหลายตัวในอินสแตนซ์เดียว สิ่งนี้จะลดค่าใช้จ่ายในการบริหารลงอย่างมาก
- การสลับผู้ใช้อัตโนมัติซึ่งเป็นคุณสมบัติความปลอดภัยที่สะดวกสบาย
- Phusion Passenger รองรับ MRI Ruby, JRuby และ Rubinius จำนวนมาก Mongrel, Unicorn และ Thin รองรับ MRI เท่านั้น Puma รองรับได้ทั้ง 3 คน
- Phusion Passenger รองรับมากกว่า Ruby จริงๆ! นอกจากนี้ยังรองรับ Python WSGI ดังนั้นจึงสามารถเรียกใช้แอพ Django และ Flask ได้เช่นกัน ในความเป็นจริง Phusion Passenger กำลังเคลื่อนไปสู่ทิศทางของการเป็นเซิร์ฟเวอร์โพลีล็อต Node.js รองรับรายการสิ่งที่ต้องทำ
- การรวบรวมขยะนอกวง Phusion Passenger สามารถเรียกใช้ตัวรวบรวมขยะ Ruby ภายนอกวงจรการร้องขอ / ตอบสนองปกติซึ่งอาจลดเวลาการร้องขอได้หลายร้อยมิลลิวินาที ยูนิคอร์นยังมีคุณสมบัติที่คล้ายกัน แต่เวอร์ชันของ Phusion Passenger นั้นมีความยืดหยุ่นมากกว่าเพราะ 1) มันไม่ได้ จำกัด อยู่แค่ GC และสามารถใช้งานได้ตามอำเภอใจ 2) เวอร์ชันของ Phusion Passenger ทำงานได้ดีกับแอพแบบมัลติเธรดในขณะที่ยูนิคอร์นไม่ทำงาน
- รีสตาร์ทอัตโนมัติกลิ้ง การเริ่มระบบใหม่บนยูนิคอร์นและเซิร์ฟเวอร์อื่น ๆ จำเป็นต้องใช้สคริปต์บางงาน Phusion Passenger Enterprise ทำสิ่งนี้ให้คุณโดยอัตโนมัติ
มีคุณสมบัติและข้อดีเพิ่มเติมมากมาย แต่รายการมีความยาวมาก คุณควรอ้างอิงคู่มือ Phusion Passenger ที่ครอบคลุม ( เวอร์ชั่น Apache , Nginx รุ่น ) หรือเว็บไซต์ Phusion Passengerสำหรับข้อมูล
โมเดลการทำงานพร้อมกันของ I / O
- กระบวนการหลายเธรดเดียว นี่เป็นแบบจำลอง I / O ที่นิยมมากที่สุดสำหรับเซิร์ฟเวอร์แอป Ruby บางส่วนเนื่องจากการสนับสนุนมัลติเธรดในระบบนิเวศทับทิมนั้นแย่มาก แต่ละกระบวนการสามารถจัดการคำขอ 1 ครั้ง โหลดเว็บเซิร์ฟเวอร์ยอดคงเหลือระหว่างกระบวนการ รุ่นนี้แข็งแกร่งมากและมีโอกาสน้อยที่โปรแกรมเมอร์จะแนะนำบั๊กที่เกิดขึ้นพร้อมกัน อย่างไรก็ตามการทำงานพร้อมกันของ I / O นั้น จำกัด มาก (ถูก จำกัด โดยจำนวนกระบวนการ) รุ่นนี้เหมาะอย่างยิ่งสำหรับปริมาณงานที่รวดเร็วและสั้น มันไม่เหมาะสมอย่างยิ่งสำหรับเวิร์กโหลด I / O บล็อกที่ช้าและใช้เวลานานเช่นเวิร์กโหลดที่เกี่ยวข้องกับการเรียก HTTP API
- แบบมัลติเธรดล้วนๆ ทุกวันนี้ระบบนิเวศของทับทิมมีการสนับสนุนมัลติเธรดที่ยอดเยี่ยมดังนั้นโมเดล I / O นี้จึงมีศักยภาพมาก มัลติเธรดช่วยให้สามารถใช้งาน I / O ได้พร้อมกันสูงเหมาะสำหรับทั้งเวิร์กโหลด I / O บล็อกระยะสั้นและระยะยาว โปรแกรมเมอร์มีแนวโน้มที่จะแนะนำบั๊กที่เกิดขึ้นพร้อมกัน แต่โชคดีที่เฟรมเวิร์กเว็บส่วนใหญ่ได้รับการออกแบบในลักษณะที่ยังไม่น่าเป็นไปได้ สิ่งหนึ่งที่ควรทราบก็คือล่าม MRI Ruby ไม่สามารถใช้ประโยชน์จากคอร์ CPU หลายแกนได้แม้ว่าจะมีหลายเธรดเนื่องจากการใช้ Global Interpreter Lock (GIL) คุณสามารถหลีกเลี่ยงปัญหานี้ได้โดยใช้กระบวนการแบบมัลติเธรดหลายกระบวนการเนื่องจากแต่ละกระบวนการสามารถใช้ประโยชน์จากซีพียูหลัก JRuby และ Rubinius ไม่มี GIL ดังนั้นพวกเขาสามารถใช้ประโยชน์จากหลายคอร์ได้อย่างเต็มที่ในขั้นตอนเดียว
- ไฮบริดแบบมัลติเธรดหลายกระบวนการ เริ่มดำเนินการโดย Phusion Passenger Enterprise 4 และใหม่กว่า คุณสามารถสลับระหว่างกระบวนการแบบมัลติเธรดแบบหลายเธรดแบบมัลติเธรดล้วนๆหรือแม้กระทั่งกระบวนการหลาย ๆ กระบวนการด้วยหลายเธรดได้อย่างง่ายดาย รุ่นนี้ให้สิ่งที่ดีที่สุดของทั้งสองโลก
- Evented รุ่นนี้แตกต่างจากรุ่นที่กล่าวถึงก่อนหน้าอย่างสิ้นเชิง ช่วยให้มีการทำงานพร้อมกันของ I / O ที่สูงมากและยอดเยี่ยมสำหรับการบล็อกปริมาณงานของ I / O ที่ทำงานเป็นเวลานาน ในการใช้งานจำเป็นต้องได้รับการสนับสนุนอย่างชัดเจนจากแอปพลิเคชันและกรอบงาน อย่างไรก็ตามเฟรมเวิร์กหลักทั้งหมดเช่น Rails และ Sinatra ไม่สนับสนุนโค้ดที่มีเหตุการณ์ นี่คือเหตุผลที่ในทางปฏิบัติกระบวนการ Thin ยังคงไม่สามารถจัดการมากกว่า 1 คำขอในเวลาทำให้มันทำงานได้อย่างมีประสิทธิภาพเช่นเดียวกับแบบจำลองกระบวนการหลายเธรดเดียว มีเฟรมเวิร์กเฉพาะที่สามารถใช้ประโยชน์จาก I / O ที่มีเหตุการณ์เช่น Cramp
บทความถูกโพสต์เมื่อเร็ว ๆ นี้ในบล็อก Phusion เกี่ยวกับการปรับจำนวนกระบวนการและเธรดให้เหมาะสมกับปริมาณงานของคุณ ดูการตั้งค่าการทำงานพร้อมกันผู้โดยสารปรับแต่ง Phusion ของ
Capistrano
Capistrano เป็นสิ่งที่แตกต่างอย่างสิ้นเชิง ในส่วนก่อนหน้าทั้งหมด "การปรับใช้" หมายถึงการเริ่มต้นแอพ Ruby ของคุณในแอปพลิเคชันเซิร์ฟเวอร์เพื่อให้ผู้เยี่ยมชมเข้าถึงได้ แต่ก่อนหน้านั้นอาจเกิดขึ้นได้โดยทั่วไปต้องมีการเตรียมการบางอย่างเช่น:
- การอัพโหลดรหัสและไฟล์ของแอพ Ruby ไปยังเครื่องเซิร์ฟเวอร์
- การติดตั้งไลบรารีที่แอพของคุณขึ้นอยู่กับ
- การตั้งค่าหรือย้ายฐานข้อมูล
- การเริ่มและหยุดดีมอนใด ๆ ที่แอปของคุณอาจใช้เช่นพนักงาน Sidekiq / Resque หรืออะไรก็ตาม
- สิ่งอื่น ๆ ที่ต้องทำเมื่อคุณตั้งค่าแอปพลิเคชันของคุณ
ในบริบทของ Capistrano "การปรับใช้" หมายถึงการดำเนินการเตรียมการทั้งหมดนี้ Capistrano ไม่ใช่แอปพลิเคชันเซิร์ฟเวอร์ แต่เป็นเครื่องมือสำหรับการเตรียมการทั้งหมดอัตโนมัติ คุณบอก Capistrano ว่าเซิร์ฟเวอร์ของคุณอยู่ที่ไหนและต้องใช้คำสั่งใดทุกครั้งที่คุณปรับใช้แอพเวอร์ชันใหม่และ Capistrano จะดูแลการอัปโหลดแอพ Rails ไปยังเซิร์ฟเวอร์ให้คุณและเรียกใช้คำสั่งที่คุณระบุ
Capistrano มักใช้ร่วมกับแอพพลิเคชันเซิร์ฟเวอร์ มันไม่ได้แทนที่แอปพลิเคชันเซิร์ฟเวอร์ ในทางกลับกันแอปพลิเคชันเซิร์ฟเวอร์ไม่ได้แทนที่ Capistrano พวกเขาสามารถใช้ร่วมกับ Capistrano
แน่นอนว่าคุณไม่จำเป็นต้องใช้ Capistrano หากคุณต้องการอัปโหลดแอพ Ruby ของคุณด้วย FTP และรันคำสั่งขั้นตอนเดียวกันทุกครั้งด้วยตนเองคุณก็สามารถทำได้ คนอื่นเบื่อมันดังนั้นพวกเขาจึงทำขั้นตอนเหล่านั้นใน Capistrano โดยอัตโนมัติ