Multitasking Optimization: หัวไวทำแต่น้อย หัวช้าทำให้มาก
อืมม.. ที่จริงที่ผ่านมาผมก็ค้นพบโน่นพบนี่มาตลอดเพื่อทำให้ GotoKnow.org ทำงานให้เร็วที่สุดเท่าที่เร็วได้นั่นละครับ แต่ไม่ได้มีโอกาสเขียนบันทึก เพราะระบบมันช้า การที่ผมไม่มาเขียนก็เป็นการลด load ระบบไปอีกหนึ่งคน (ฮา.. เป็นเหตุผล)
เครื่องก่อนหน้านี้เป็นเครื่องช้า ผมเลยเรียก FastCGI instance ของ KnowledgeVolution ทำงานพร้อมๆ กัน 10 ตัว ก็รองรับผู้ใช้ได้ เรียกว่ามีมือสิบมือมาสลับสับเปลี่ยนกันรองรับผู้ใช้พร้อมๆ กัน แต่เป็นมือสิบที่ทำงานช้า แต่อย่างน้อยผู้ใช้เมื่อเรียกใช้ ก็จะมีมือ "ว่าง" ต้อนรับการเรียกใช้นั้น
ที่จริงแล้วผมทดสอบมาจาก 4 ตัวก่อนและผมทดลองเพิ่มเรื่อยๆ ทีละสองตัว พบว่ายิ่งเพิ่ม "ความรู้สึก" ว่าระบบตอบสนองได้เร็วก็จะเพิ่มขึ้น แต่พอเพิ่มไปถึง 10 ตัวก็เห็นท่าว่าหน่วยความจำไม่พอ ถ้ามากกว่านี้ระบบจะใช้ swap memory ซึ่งจะทำให้ระบบช้าไปใหญ่
พอมาเป็นเครื่องเร็ว ผมก็เรียกให้ทำงาน 10 ตัวเหมือนเดิม ความเร็วก็ใช้ได้ แต่ปรากฎว่าเมื่อลองให้ทำงานเพียง 4 ตัวกลับทำงานได้เร็วกว่า สาเหตุก็คือมือทั้งสี่มือนี้ทำงานเสร็จเร็ว การที่มีน้อยการใช้ทรัพยากรระบบก็จะยิ่งมีประสิทธิภาพมากขึ้นก็จะยิ่งทำให้มือทั้งสี่นี้ทำงานได้เร็วขึ้นและเปิดโอกาสให้ระบบว่างมากขึ้นด้วย เพราะเป็นการลดงานให้แก่ระบบปฎิบัติการในการต้องคอยสลับงาน
สรุปว่า ถ้าหัวไวให้ทำงานแต่น้อย เพราะทำงานเสร็จเร็ว แต่ถ้าหัวช้าให้ทำงานพร้อมๆ กันเยอะๆ เพราะทำงานเสร็จช้าแต่งานก็จะเสร็จไปได้เรื่อยๆ
วิธีการนี้ใช้กับการพัฒนาระบบคอมพิวเตอร์ได้ แต่ผมสงสัยจริงว่าจะใช้กับการบริหารงานของบุคคลได้หรือเปล่านะ?
ความเห็น (6)
- หัวไว ก็ทำงานได้เสร็จเร็วอย่างนี้ใช้คนน้อยได้งานเยอะ...ประหยัดทรัพยากรหลายอย่าง
- หัวช้า ก็ทำงานเสร็จช้า อย่างนี้ต้องใช้คนเยอะเพื่อให้ได้งานเยอะ....ต้องใช้ทรัพยากรอื่นๆเพิ่มขึ้นไปด้วย
- ปัญหาอยู่ตรงที่ว่า ถ้าบุคลากรหลายๆคน..หัวไวบ้าง ช้าบ้าง...มาช่วยกันทำงานแบบเดียวกัน....ทำไงให้ได้งานเยอะที่สุดดีคะเนี่ย....
- ชอบเหตุผลของอาจารย์ครับ
- เพราะระบบมันช้า การที่ผมไม่มาเขียนก็เป็นการลด load ระบบไปอีกหนึ่งคน (ฮา.. เป็นเหตุผล)
- ชอบทำงานหลายคน สนุกดีครับ
ขออนุญาตสนทนาธรรมกับสังฆราชนะครับ
ผมคิดว่าไม่ว่าจะหัวไวหรือหัวช้าก็ทำงานเท่ากัน แต่เสร็จไม่พร้อมกัน (เอิ๊ก) เข้าใจว่าแต่ละ instant ของ FastCGI เป็นตัวที่ compose หน้า HTML ที่ผู้ใช้เห็น
ไม่ว่าจะใช้ HTTP 1.1 keep alive หรือไม่ เวลาเฉลี่ยที่ FastCGI จะถูกใช้งาน ขึ้นกับว่าสามารถจะ render page เสร็จได้เร็วแค่ไหน ส่วนการพยายามป้องกันไม่ให้ swap เป็นแนวที่ถูกต้องรวดเร็วแน่นอน
เมื่อ render เสร็จแล้ว (หรือค่อยๆทำไปใน pipeline) FastCGI ก็จะส่ง HTML ออกไปผ่าน network แล้วจะ free up ตัวเองสำหรับ request อื่น
แต่ขนาดของ HTML นั้นใหญ่กว่า default TXBUF ซึ่งค่าปริยาย จะทำให้ FastCGI ต้องหยุดรอ จน TXBUF ว่าง เนื่องจากผู้รับปลายทางจะรับ HTML ด้วยความเร็วที่ต่ำกว่าเครื่อง g2k สามารถจะส่งได้เสมอ นี่ยังไม่นับความคับคั่งในวงจรต่างๆอีกนะครับ
ดังนั้นหาก bump ค่า TXBUF แล้ว gen kernel ใหม่ หรือจะระบุ mss ในส่วนของ routing เพื่อเพิ่มขนาด TXBUF ก็อาจจะช่วยให้งานของ FastCGI เสร็จสิ้นเร็วขึ้นอีกเพราะคราวนี้ ส่งไปได้เรื่อยๆไม่ต้องหยุดรอ TXBUF
พูดถึงเรื่องนี้ ยังไม่มีความจำเป็นเนื่องจากยังมี idle capacity อีกมหาศาล แต่ผมคิดว่ามีคอขวดอีกจุดหนึ่งในส่วนของระบบซึ่งอาจปรับปรุงได้หากจำเป็นครับ
สาธุ
เป็นคำแนะนำที่ดีมากเลยครับ เป็นจุดที่ optimize แล้วจะได้ความเร็วเพิ่มขึ้นมากจริงๆ แต่ตอนนี้พอลดเหลือ 4 instances แล้วเครื่องยิ่งว่างครับ
เดี๋ยวผมไปเขียนโปรแกรมส่วนเพิ่มงานที่ load เครื่องหน่อยดีกว่า (อาทิเช่น การ plot social networks ของผู้ใช้แต่ละคน) แล้วหลังจากนั้นค่อย optimize ต่อครับ
อ่านเรื่องที่อ.ธวัชชัยเขียนแล้วรู้สึกสนุกไปด้วย ทั้งๆที่ไม่ค่อยเข้าใจรายละเอียดสักเท่าไหร่ ยิ่งความเห็นของคุณConductor ด้วยยิ่งมึนตึ้บไปเลย
นึกเห็นภาพใน lab ของเราเลยค่ะ เรามีคนทั้ง 2 แบบแล้วคนที่หัวไวทำงานเร็วก็จะเป็นกลไกที่หมุนให้ คนหัวช้าทำงานน้อยทำได้เร็วขึ้นกว่าเวลาทำคนเดียว เพราะฉะนั้นการจัดวางตำแหน่งงานก็เป็นสิ่งสำคัญต่อความก้าวหน้าของงาน
คนละบริบทแต่หลักการเดียวกันเลย ใช่ไหมคะ