เรื่องของ GotoKnow Monitor (1)


เดิมทีเดียว ไม่คิดว่าจะเขียนบันทึกเกี่ยวกับการใช้งาน GotoKnow Monitor ครับ ตอนนี้ก็ยังไม่คิดครับ แต่อยากจะเขียนเกี่ยวกับแนวคิดการแก้ไขปัญหา การออกแบบมากกว่า เผื่อว่าใครจะนำไปใช้ประโยชน์ได้ แล้วเนื่องจากคิดเรื่องเทคนิค คงหลีกเลี่ยงศัพท์เทคนิคไม่ได้ 

ดังนั้นบันทึกนี้ ถ้าจะมองเป็นเรื่องเทคนิค ก็เป็น ถ้าจะมองว่าไม่ใช่ บางก็อาจไม่ใช่ครับ ผมเขียนเพื่อเล่าเรื่องกระบวนการคิด ไม่มีอะไรมากไปกว่านั้นครับ 

แนวคิด

เครื่องแม่ข่ายของ GotoKnow มีปัญหาหนักหลายอย่าง (บันทึกเก่า: ขอความเห็นสำคัญเรื่องเครื่องแม่ข่าย GotoKnow.org และเว็บไซต์ข้างเคียง) ผู้พัฒนาได้ทำงานอย่างหนักตลอดมา แต่ GotoKnow เอง ก็เหมือนตกเป็นเหยื่อความสำเร็จของตัวเองเช่นกัน ในการแก้ไขปัญหา

ผมไม่คิดว่าผู้มีส่วนได้เสียควรจะผลักภาระให้ผู้รับผิดชอบแต่ฝ่ายเดียว หากแต่เหล่าผู้ที่มีส่วนได้เสียนั้นเอง ควรจะทำเท่าที่ทำได้ เพื่อป้องกัน+แก้ไขให้ปัญหาผ่านพ้นไปได้ด้วยดี

ปัญหา

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

GotoKnow มีผู้ใช้มากขึ้นเรื่อยๆ ถ้าเริ่มแสดงอาการตั้งแต่ตอนนี้ จะรองรับความเติบโตในอนาคตได้อย่างไีร

สาเหตุ 

มีหลายเรื่องครับ

  • อยากได้ Memory อีก ยิ่งมากยิ่งดี แต่ถ้าได้มากกว่านี้ก็จะรองรับการเติบโตได้ดีขึ้น ในครึ่งปีที่ผ่านมา โหลดของ GotoKnow เพิ่มขึ้นเท่าตัว สเป็คเครื่องซึ่งเดิมทีคิดว่าเหลือเฟือ เดี๋ยวเดียวกลายเป็นไม่พอไปแล้ว
  • Ruby ช้า อันนี้ช่วยไม่ได้ (และไม่ได้บ่นครับ) version หน้าคงเร็วขึ้น
  • มีคอขวดหลายที่ แต่ database (MySQL) เป็นคอขวดหลัก

จะแก้ไปถึงไหน แก้ให้เป็นอะไรขึ้นมา

ก็แก้ไปจนใกล้จุด optimum ในทุกส่วนที่เห็นว่าเป็นปัญหาครับ พยายามกำจัดคอขวดออกจากระบบให้มากที่สุด ถ้าทำได้ ก็ไม่อยากให้ระบบหยุดรออะไร-ในที่ใดเลย

การเพิ่มเครื่องแม่ข่าย เป็นวิธีที่ง่าย แต่แก้ไขไม่ตรงจุด ที่จริง ไม่ได้แตะสาเหตุเลย แต่จะแก้ปัญหาเฉพาะหน้าได้เร็ว ซึ่งปัญหาเก่าจะย้อนกลับมาอีกในอนาคต และจะต้องขยายเครื่องไปเรื่อยๆ ซึ่งไม่ดีแน่

แนวทางการแก้ไข

  1. เพิ่ม Memory ที่ database server เพื่อขยายขนาด cache จะเป็นวิธีที่มีประโยชน์ต่อต้นทุนสูงสุด
  2. tune database ขยายขนาด query cache (กำลังปรับแต่งกันอยู่ แต่ต้องรอจังหวะวันธรรมดาที่มีโหลดสูง จึงจะได้สภาพการใช้งานจริง)
  3. ลดภาระ database ให้มากที่สุด การ refresh จอภาพ เป็นการเพิ่มภาระแก่ database โดยตรง จึงต้องหาวิธีมาแก้ไข -- อันนี้เป็นที่มาของ GotoKnow Monitor ครับ กรุณาอ่านตอนสอง
  4. แก้ไขโปรแกรม ให้ cache SQL queries (ซึ่งต้องการ memory เพิ่ม) ในขณะนี้ มีการ cache HTML ผ่าน memcached และมีการขยาย cache ของ MySQL แต่ยังไม่มีการ cache ผลของ queries ที่เรียกจาก MySQL -- การทำอย่างนี้ ดูเหมือนเป็น cache ซ้อน cache แต่ cache ของ MySQL เล็กกว่า cache ชั้นที่สอง (memcached) อย่างน้อยสี่เท่าตัว แม้ว่าจะไปเบียดบัง HTML cache แต่ก็น่าจะให้ cache hit เพิ่มขึ้นได้มาก ทำให้ระบบทำงานน้อยลง และเร็วขึ้น เทียบได้เหมือนการมี cache หลายชั้นของ CPU ครับ
คำสำคัญ (Tags): #gotoknow.org
หมายเลขบันทึก: 122116เขียนเมื่อ 26 สิงหาคม 2007 01:34 น. ()แก้ไขเมื่อ 11 กุมภาพันธ์ 2012 20:03 น. ()สัญญาอนุญาต: จำนวนที่อ่านจำนวนที่อ่าน:


ความเห็น (0)

ไม่มีความเห็น

พบปัญหาการใช้งานกรุณาแจ้ง LINE ID @gotoknow
ClassStart
ระบบจัดการการเรียนการสอนผ่านอินเทอร์เน็ต
ทั้งเว็บทั้งแอปใช้งานฟรี
ClassStart Books
โครงการหนังสือจากคลาสสตาร์ท