AAR การจัดการส่วนกินระบบ (Performance Hog)

เมื่อวาน ดร.จันทวรรณ และผมนั่งค้นหาสาเหตุที่ KnowledgeVolution ช้าอืดแถมกินกำลังการประมวลผลและหน่วยความจำมาก

KnowledgeVolution เป็น Rails application ซึ่งเป็น framework ที่เลื่องลือกันว่าไม่กินทรัพยากรระบบเท่าไหร่เลย แล้วทำไมระบบเราถึงกินจัง? หรือ Rails ไม่ได้ดีอย่างที่เขาเลื่องลือ เพราะนี่ก็เป็น Rails application ตัวแรกของเรา เราหลงใช้ framework ผิดหรือเปล่านี่?

เมื่อไล่กันไปเป็นส่วนๆ ก็พบสาเหตุต่างๆ แล้วก็ทำการแก้ไขจนในที่สุด KV ทำงานได้อย่างที่เห็นในวันนี้ครับ

เริ่มจากเรื่องการกินหน่วยความจำ เราก็ดูจาก Ruby modules ที่เราใช้พิเศษจาก Rails ปกติได้แก่ RMagick และ Ruby-Tidy ครับ

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

ปรากฎว่าการใช้ Tidy นี่ละตัวร้าย ตัว Tidy ในฐานะ C library เองไม่มีปัญหาหรอก แต่ Ruby-Tidy ซึ่งเป็น Ruby module ที่ติดต่อกับ Tidy นี่สิ เขียนได้ไม่ดีและกินทั้งหน่วยความจำและกำลังการประมวลผล แต่เราก็อยากใช้เลยพยายาม optimize ให้เป็นไปได้ ปรากฎว่าเกินกำลังครับ ท่าน Tidy “กิน” จริงๆ เลยสรุปว่าต้องเลิกใช้ รอให้ Ruby-Tidy ปรับปรุงให้ดีกว่านี้หน่อย พอเลิกใช้ Tidy ระบบจากที่ load อยู่ 80-90% ก็กลับมาวิ่งฉิวเหมือนไม่มี load อะไรเลย

เรื่องต่อมาก็คือการไล่เก็บพวก hotlinks ต่างๆ ที่ใช้ GotoKnow.org เป็นที่เก็บไฟล์ อันนี้ก็ดักเรียบร้อย ไม่มีปัญหา ถ้า hotlink มาหารูปจากที่อื่น เราก็จะคืน 404 File Not Found ไป

จริงๆ แล้ว hotlinks นี่หลายๆ ที่ก็ทำไปด้วยวัตถุประสงค์ที่ดี อย่างเช่นเว็บไซต์ในหน่วยงานต่างๆ ที่จริงแล้วเราก็ไม่อยากตัด hotlinks เท่าไหร่ แต่เพื่อถนอมทรัพยากรระบบก็เลยต้องตัดไปก่อน ต่อไปจะพัฒนาให้สามารถทำ hotlinks มาจากเว็บไซต์ที่อยู่ในหน่วยงานของรัฐและมหาวิทยาลัยครับ

นอกจากสองเรื่องดังกล่าวแล้ว เรายัง optimize โปรแกรมในส่วนต่างๆ อีกหลายจุดด้วยกัน เรียกว่าทำงานกันข้ามคืนทีเดียว แต่หลังจากเรียบร้อยแล้วก็ได้ KnowledgeVolution ที่วิ่งฉิวสมใจ นับว่าคุ้มค่าในการทุ่มเวลา ได้ GotoKnow.org ที่มีความเร็วให้ผู้ใช้สามารถใช้งานได้อย่างเต็มที่ในวันมหามงคลในวันนี้ครับ