เดิมทีเดียว ไม่คิดว่าจะเขียนบันทึกเกี่ยวกับการใช้งาน GotoKnow Monitor ครับ ตอนนี้ก็ยังไม่คิดครับ แต่อยากจะเขียนเกี่ยวกับแนวคิดการแก้ไขปัญหา การออกแบบมากกว่า เผื่อว่าใครจะนำไปใช้ประโยชน์ได้ แล้วเนื่องจากคิดเรื่องเทคนิค คงหลีกเลี่ยงศัพท์เทคนิคไม่ได้
ดังนั้นบันทึกนี้ ถ้าจะมองเป็นเรื่องเทคนิค ก็เป็น ถ้าจะมองว่าไม่ใช่ บางก็อาจไม่ใช่ครับ ผมเขียนเพื่อเล่าเรื่องกระบวนการคิด ไม่มีอะไรมากไปกว่านั้นครับ
แนวคิด
เครื่องแม่ข่ายของ GotoKnow มีปัญหาหนักหลายอย่าง (บันทึกเก่า: ขอความเห็นสำคัญเรื่องเครื่องแม่ข่าย GotoKnow.org และเว็บไซต์ข้างเคียง) ผู้พัฒนาได้ทำงานอย่างหนักตลอดมา แต่ GotoKnow เอง ก็เหมือนตกเป็นเหยื่อความสำเร็จของตัวเองเช่นกัน ในการแก้ไขปัญหา
ผมไม่คิดว่าผู้มีส่วนได้เสียควรจะผลักภาระให้ผู้รับผิดชอบแต่ฝ่ายเดียว หากแต่เหล่าผู้ที่มีส่วนได้เสียนั้นเอง ควรจะทำเท่าที่ทำได้ เพื่อป้องกัน+แก้ไขให้ปัญหาผ่านพ้นไปได้ด้วยดี
ปัญหา
ระบบทำงานช้า ผู้ใช้ที่อยู่ไกล หรือเชื่อมต่อด้วยความเร็วไม่สูง อาจจะรู้สึกหรือไม่รู้สึกก็ได้ แต่เมื่อเฝ้่าดูสุขภาพของเครื่องแม่ข่ายอย่างใกล้ชิด คงต้องสารภาพว่าเกิดความกังวลเป็นอย่างมาก
GotoKnow มีผู้ใช้มากขึ้นเรื่อยๆ ถ้าเริ่มแสดงอาการตั้งแต่ตอนนี้ จะรองรับความเติบโตในอนาคตได้อย่างไีร
สาเหตุ
มีหลายเรื่องครับ
- อยากได้ Memory อีก ยิ่งมากยิ่งดี แต่ถ้าได้มากกว่านี้ก็จะรองรับการเติบโตได้ดีขึ้น ในครึ่งปีที่ผ่านมา โหลดของ GotoKnow เพิ่มขึ้นเท่าตัว สเป็คเครื่องซึ่งเดิมทีคิดว่าเหลือเฟือ เดี๋ยวเดียวกลายเป็นไม่พอไปแล้ว
- Ruby ช้า อันนี้ช่วยไม่ได้ (และไม่ได้บ่นครับ) version หน้าคงเร็วขึ้น
- มีคอขวดหลายที่ แต่ database (MySQL) เป็นคอขวดหลัก
จะแก้ไปถึงไหน แก้ให้เป็นอะไรขึ้นมา
ก็แก้ไปจนใกล้จุด optimum ในทุกส่วนที่เห็นว่าเป็นปัญหาครับ พยายามกำจัดคอขวดออกจากระบบให้มากที่สุด ถ้าทำได้ ก็ไม่อยากให้ระบบหยุดรออะไร-ในที่ใดเลย
การเพิ่มเครื่องแม่ข่าย เป็นวิธีที่ง่าย แต่แก้ไขไม่ตรงจุด ที่จริง ไม่ได้แตะสาเหตุเลย แต่จะแก้ปัญหาเฉพาะหน้าได้เร็ว ซึ่งปัญหาเก่าจะย้อนกลับมาอีกในอนาคต และจะต้องขยายเครื่องไปเรื่อยๆ ซึ่งไม่ดีแน่
แนวทางการแก้ไข
- เพิ่ม Memory ที่ database server เพื่อขยายขนาด cache จะเป็นวิธีที่มีประโยชน์ต่อต้นทุนสูงสุด
- tune database ขยายขนาด query cache (กำลังปรับแต่งกันอยู่ แต่ต้องรอจังหวะวันธรรมดาที่มีโหลดสูง จึงจะได้สภาพการใช้งานจริง)
- ลดภาระ database ให้มากที่สุด การ refresh จอภาพ เป็นการเพิ่มภาระแก่ database โดยตรง จึงต้องหาวิธีมาแก้ไข -- อันนี้เป็นที่มาของ GotoKnow Monitor ครับ กรุณาอ่านตอนสอง
- แก้ไขโปรแกรม ให้ cache SQL queries (ซึ่งต้องการ memory เพิ่ม) ในขณะนี้ มีการ cache HTML ผ่าน memcached และมีการขยาย cache ของ MySQL แต่ยังไม่มีการ cache ผลของ queries ที่เรียกจาก MySQL -- การทำอย่างนี้ ดูเหมือนเป็น cache ซ้อน cache แต่ cache ของ MySQL เล็กกว่า cache ชั้นที่สอง (memcached) อย่างน้อยสี่เท่าตัว แม้ว่าจะไปเบียดบัง HTML cache แต่ก็น่าจะให้ cache hit เพิ่มขึ้นได้มาก ทำให้ระบบทำงานน้อยลง และเร็วขึ้น เทียบได้เหมือนการมี cache หลายชั้นของ CPU ครับ