ฉันกลัวว่าฉัน "ทำสิ่งที่ผิด" ที่นี่ถ้าเป็นเช่นนั้นลบฉันและฉันขอโทษ โดยเฉพาะอย่างยิ่งฉันไม่เห็นว่าฉันจะสร้างคำอธิบายประกอบเล็ก ๆ ที่ประณีตที่บางคนสร้างขึ้นได้อย่างไร อย่างไรก็ตามฉันมีข้อสงสัย / ข้อสังเกตมากมายในหัวข้อนี้
1) องค์ประกอบที่แสดงความคิดเห็นในรหัสหลอกในหนึ่งในคำตอบที่ได้รับความนิยม
result = query( "select smurfs from some_mushroom" );
// twiddle fingers
go_do_something_with_result( result );
เป็นหลักปลอม หากเธรดกำลังประมวลผลแสดงว่ามันไม่ได้เป็นสองนิ้วหัวแม่มือก็จะทำงานที่จำเป็น หากในอีกทางหนึ่งก็แค่รอความสำเร็จของ IO แล้วก็ไม่ได้ใช้เวลา CPU จุดรวมทั้งหมดของโครงสร้างพื้นฐานการควบคุมเธรดในเคอร์เนลคือ CPU จะพบสิ่งที่มีประโยชน์ที่ต้องทำ วิธีเดียวที่จะ "สะบัดนิ้วโป้ง" ตามที่แนะนำในที่นี้คือการสร้างโพลลูปและไม่มีใครทำรหัสเว็บเซิร์ฟเวอร์ตัวจริงที่ไม่มีประสิทธิภาพเพียงพอที่จะทำเช่นนั้น
2) "เธรดนั้นยาก" มีความหมายเฉพาะในบริบทของการแบ่งปันข้อมูล ถ้าคุณมีเธรดที่เป็นอิสระเช่นในกรณีที่จัดการกับคำร้องขอเว็บอิสระการทำเธรดนั้นง่ายนิดเดียวคุณเพียงแค่เขียนโค้ดการไหลเชิงเส้นของวิธีจัดการกับงานหนึ่งและนั่งค่อนข้างรู้ว่ามันจะจัดการกับคำร้องขอหลายรายการและแต่ละอัน จะเป็นอิสระอย่างมีประสิทธิภาพ โดยส่วนตัวแล้วฉันอยากจะเขียนว่าสำหรับโปรแกรมเมอร์ส่วนใหญ่การเรียนรู้กลไกการปิด / โทรกลับนั้นซับซ้อนกว่าการเขียนโค้ดเธรดจากบนลงล่าง (แต่ใช่ถ้าคุณต้องสื่อสารระหว่างเธรดชีวิตจะยากขึ้นอย่างรวดเร็วจริง ๆ แต่จากนั้นฉันก็ไม่มั่นใจว่ากลไกการปิด / โทรกลับนั้นเปลี่ยนไปจริงๆมันแค่ จำกัด ตัวเลือกของคุณเพราะวิธีนี้ยังคงทำได้ด้วยเธรด ยังไงก็ตาม '
3) จนถึงขณะนี้ยังไม่มีใครแสดงหลักฐานที่แท้จริงว่าเหตุใดการสลับบริบทประเภทใดประเภทหนึ่งจึงใช้เวลานานกว่าหรือน้อยกว่าประเภทอื่น ประสบการณ์ของฉันในการสร้างมัลติทาสกิ้ง (ขนาดเล็กสำหรับตัวควบคุมแบบฝังตัวไม่มีอะไรที่น่าประหลาดใจในฐานะระบบปฏิบัติการ "ของจริง") แสดงให้เห็นว่านี่จะไม่เป็นเช่นนั้น
4) ภาพประกอบทั้งหมดที่ฉันได้เห็นถึงวันที่อ้างว่าแสดงให้เห็นว่าโหนดเร็วกว่าเว็บเซิร์ฟเวอร์อื่น ๆ ที่มีข้อบกพร่องอย่างน่ากลัว แต่พวกเขามีข้อบกพร่องในทางที่แสดงให้เห็นถึงข้อได้เปรียบทางอ้อมฉันจะยอมรับอย่างแน่นอน มันไม่ได้หมายความว่าไม่มีนัยสำคัญ) โหนดดูไม่เหมือนว่าต้องการจูน (หรือแม้แต่อนุญาต) จริง ๆ แล้ว หากคุณมีแบบจำลองเธรดคุณต้องสร้างเธรดที่เพียงพอเพื่อจัดการกับโหลดที่คาดไว้ ทำสิ่งนี้ไม่ดีและคุณจะจบลงด้วยประสิทธิภาพที่ไม่ดี หากมีจำนวนเธรดน้อยเกินไปแสดงว่า CPU ไม่ได้ทำงาน แต่ไม่สามารถรับคำขอเพิ่มเติมสร้างเธรดจำนวนมากเกินไปและคุณจะเสียหน่วยความจำเคอร์เนลและในกรณีของสภาพแวดล้อม Java คุณจะต้องสูญเสียหน่วยความจำฮีปหลักด้วย . ตอนนี้สำหรับ Java การสูญเสียฮีพเป็นวิธีแรกที่ดีที่สุดในการเพิ่มประสิทธิภาพของระบบ เนื่องจากการรวบรวมขยะที่มีประสิทธิภาพ (ปัจจุบันอาจมีการเปลี่ยนแปลงด้วย G1 แต่ดูเหมือนว่าคณะลูกขุนยังคงออกมา ณ จุดนั้นตั้งแต่ต้นปี 2013 อย่างน้อย) ขึ้นอยู่กับการมีกองสำรองมากมาย ดังนั้นจึงมีปัญหาปรับแต่งด้วยเธรดที่น้อยเกินไปคุณมีซีพียูที่ไม่ทำงานและปริมาณงานที่ไม่ดีทำการจูนด้วยจำนวนมากเกินไปและมันจะชะงักไปในทางอื่น
5) มีวิธีอื่นที่ฉันยอมรับตรรกะของการอ้างว่าวิธีของโหนด "เร็วกว่าด้วยการออกแบบ" และนั่นก็คือสิ่งนี้ โมเดลเธรดส่วนใหญ่ใช้โมเดลสวิตช์บริบทแบบแบ่งส่วนเวลาซึ่งอยู่ด้านบนของโมเดลที่เหมาะสมกว่า (การแจ้งเตือนการตัดสินใจค่า :) และมีประสิทธิภาพมากขึ้น สิ่งนี้เกิดขึ้นด้วยเหตุผลสองประการประการแรกโปรแกรมเมอร์ส่วนใหญ่ดูเหมือนจะไม่เข้าใจลำดับความสำคัญในการจัดลำดับความสำคัญและข้อที่สองถ้าคุณเรียนรู้การทำเกลียวในสภาพแวดล้อมของ Windows สะดุดตา Java เวอร์ชันแรกใช้ลำดับความสำคัญในการปรับใช้ Solaris และ timeslicing ใน Windows เนื่องจากโปรแกรมเมอร์ส่วนใหญ่ไม่เข้าใจและบ่นว่า "เธรดไม่ทำงานใน Solaris" พวกเขาเปลี่ยนแบบจำลองเป็นไทม์ซทุกที่) อย่างไรก็ตามสิ่งที่สำคัญที่สุดคือเวลาที่สร้างสวิทช์บริบทเพิ่มเติม (และอาจไม่จำเป็น) การสลับบริบททุกครั้งต้องใช้เวลาของ CPU และเวลานั้นจะถูกลบออกจากงานที่สามารถทำได้จริงในมือ อย่างไรก็ตามจำนวนเวลาที่ลงทุนในการสลับบริบทเนื่องจากเวลาที่เกิดขึ้นไม่ควรมากกว่าร้อยละขนาดเล็กมากของเวลาโดยรวมเว้นแต่จะมีบางสิ่งที่แปลก ๆ เกิดขึ้นและไม่มีเหตุผลที่ฉันสามารถคาดหวังได้ว่าจะเป็นเช่นนั้นใน เว็บเซิร์ฟเวอร์ที่เรียบง่าย) ดังนั้นใช่บริบทส่วนเกินที่เกี่ยวข้องกับการจับเวลาจะไม่มีประสิทธิภาพ (และสิ่งเหล่านี้จะไม่เกิดขึ้น และเวลานั้นจะถูกลบออกจากงานที่สามารถทำได้จริงในมือ อย่างไรก็ตามระยะเวลาที่ลงทุนในการสลับบริบทเนื่องจากเวลาที่เกิดขึ้นไม่ควรมากกว่าร้อยละขนาดเล็กมากของเวลาโดยรวมเว้นแต่จะมีบางสิ่งที่เกิดขึ้นนอกประเทศเกิดขึ้นและไม่มีเหตุผลที่ฉันจะเห็นว่าเป็นเช่นนั้น เว็บเซิร์ฟเวอร์ที่เรียบง่าย) ดังนั้นใช่บริบทส่วนเกินที่เกี่ยวข้องกับการจับเวลาจะไม่มีประสิทธิภาพ (และสิ่งเหล่านี้จะไม่เกิดขึ้น และเวลานั้นจะถูกลบออกจากงานที่สามารถทำได้จริงในมือ อย่างไรก็ตามระยะเวลาที่ลงทุนในการสลับบริบทเนื่องจากเวลาที่เกิดขึ้นไม่ควรมากกว่าร้อยละขนาดเล็กมากของเวลาโดยรวมเว้นแต่จะมีบางสิ่งที่เกิดขึ้นนอกประเทศเกิดขึ้นและไม่มีเหตุผลที่ฉันจะเห็นว่าเป็นเช่นนั้น เว็บเซิร์ฟเวอร์ที่เรียบง่าย) ดังนั้นใช่บริบทส่วนเกินที่เกี่ยวข้องกับการจับเวลาจะไม่มีประสิทธิภาพ (และสิ่งเหล่านี้จะไม่เกิดขึ้นเคอร์เนลเธรดตามกฎ, btw) แต่ความแตกต่างจะเป็นเปอร์เซ็นต์ของปริมาณงานไม่กี่ชนิดของปัจจัยตัวเลขทั้งหมดที่มีนัยในการอ้างประสิทธิภาพที่มักจะบอกเป็นนัยสำหรับโหนด
ยังไงก็ตามขอโทษสำหรับสิ่งที่อยู่มานานและยุ่งเหยิง แต่ฉันรู้สึกว่าจนถึงตอนนี้การอภิปรายไม่ได้พิสูจน์อะไรเลยและฉันยินดีที่จะได้ยินจากใครบางคนในสถานการณ์เหล่านี้:
a) คำอธิบายที่แท้จริงว่าทำไมโหนดควรดีกว่า (นอกเหนือจากสองสถานการณ์ที่ฉันได้อธิบายไว้ข้างต้นสิ่งแรกที่ฉันเชื่อว่าเป็นคำอธิบายที่แท้จริงสำหรับการทดสอบทั้งหมดที่ฉันได้เห็นมา ] ยิ่งฉันคิดถึงมันมากเท่าไหร่ฉันก็ยิ่งสงสัยว่าหน่วยความจำที่ใช้โดยสแต็คจำนวนมากอาจมีความสำคัญที่นี่ขนาดสแต็คเริ่มต้นสำหรับเธรดสมัยใหม่นั้นค่อนข้างใหญ่ แต่หน่วยความจำที่จัดสรรโดย ระบบเหตุการณ์ปิดจะเป็นสิ่งที่จำเป็นเท่านั้น)
b) เกณฑ์มาตรฐานที่แท้จริงซึ่งให้โอกาสที่ยุติธรรมแก่เซิร์ฟเวอร์เธรดที่เลือก อย่างน้อยฉันก็ต้องหยุดเชื่อว่าคำกล่าวอ้างนั้นเป็นเท็จจริง ๆ > ([แก้ไข] ที่อาจค่อนข้างแข็งแกร่งกว่าที่ฉันตั้งใจ แต่ฉันรู้สึกว่าคำอธิบายที่ให้ไว้เพื่อประโยชน์ด้านการแสดงนั้นไม่สมบูรณ์ที่สุดและ มาตรฐานที่แสดงนั้นไม่สมเหตุสมผล)
ไชโยโทบี้
select()เร็วกว่าการสลับบริบทของเธรด