make sure no overlogging

ในระหว่างการพัฒนาระบบงาน สิ่งหนึ่งที่เราได้เรียนรู้มาจากการทำงานในองค์กรขนาดใหญ่ คือการพัฒนาระบบให้มี traceability หรือสามารถติดตามสถานะของงานแต่ละชิ้นได้ เทคนิคอย่างหนึ่งคือการทำ logging หรือบันทึกผลของการทำงานแต่ละขั้นตอนไว้

ประโยชน์ของการทำ system log มีหลายอย่าง อาทิเช่น

  • ช่วยให้สามารถทราบผลของงานแต่ละขั้นตอนได้ โปรแกรมหนึ่งอาจจะมีขั้นตอนในการทำงาน ตั้งแต่ไม่กี่ขั้นตอน ไปจนถึงเป็นร้อย เป็นพันขั้นตอน การบันทึก log เอาไว้ ทำให้ operator สามารถกลับมาตรวจสอบในภายหลังได้ว่า ขั้นตอนที่โปรแกรมได้ทำไปแล้วนั้น เสร็จสมบูรณ์หรือไม่ หรือเกิดข้อผิดพลาดอย่างไร
  • ช่วยในการพัฒนาปรับปรุงประสิทธิภาพการทำงานโดยรวม การบันทึก log ยังช่วยให้สามารถดูได้ว่า ประสิทธิภาพการทำงานของระบบเป็นอย่างไร มีขั้นตอนไหนที่ใช้เวลามากเกินไปหรือเปล่า สามารถแสดงให้เห็นจุดที่ควรปรับปรุงแก้ไขได้
  • ช่วย recovery หรือ re-process ในกรณีที่โปรแกรมทำงานไม่เสร็จเรียบร้อย อาจจะหยุดที่ขั้นตอนใดขั้นตอนหนึ่ง การตรวจดู log สามารถช่วยให้ operator สามารถ resume ขั้นตอนต่อไปได้ โดยไม่จำเป็นต้องเริ่มต้นขั้นตอนใหม่ทั้งหมด

ดังนั้นแล้ว เวลาพัฒนาโปรแกรม เรามักจะให้มีการเขียน  log ในลักษณะอย่างใดอย่างหนึ่งเสมอ เพื่อประโยชน์ต่างๆ ข้างต้น

อย่างไรก็ดี ถ้ามีการทำ logging มากเกินไป  แน่นอนว่าจะส่งผลเสียต่อระบบได้

  • performance แน่นอนว่า ถ้าระบบถูกพัฒนามาให้บันทึก log ทุกขั้นตอนการทำงาน แบบละเอียดยิบ สิ่งที่เกิดขึ้นก็คือ มันก็จะทำให้ประสิทธิภาพโดยรวมลดลง แทนที่จะใช้เวลาประมวลผลเสีย 95-99 เปอร์เซ็นต์ แล้วบันทึก log ซัก 1-4 เปอร์เซ็นต์ กลายเป็นว่า เวลากว่าครึ่งของการทำงาน หมดไปกับการเขียนบันทึก ว่ากำลังทำอะไรบ้าง
  • storage หรือการบันทึกข้อมูล ก็จะต้องกันพื้นที่ส่วนหนึ่ง ไม่ว่าจะเป็นพื้นที่ในฐานข้อมูลหรือพื้นที่ดิสก์สำหรับเก็บ log files ส่วนนี้อาจจะเป็นปัญหาได้ หากไม่ได้มีการเขียนโปรแกรมเพื่อทำการ clean-up ข้อมูลบันทึกเหล่านั้น
  • clean-up process หรือกระบวนการในการ “ลบ” ข้อมูล log ที่บันทึกเอาไว้ เมื่อระบบทำงานนานๆ ไป สิ่งหนึ่งที่มักจะลืมกันก็คือ กระบวนการในการ clean-up log เพื่อลดพื้นที่เก็บข้อมูลที่ไม่จำเป็น เคยมีมากกว่าหนึ่งระบบที่ พอดิสก์เต็ม พยายามจะ archive ข้อมูล พอเข้าไปดูเข้าจริงๆ ข้อมูลกว่าครึ่ง เป็นข้อมูล log ซึ่งบางทีก็เก่านานหลายปีแล้ว แสดงว่าไม่เคยได้มีการ clean-up เลย

นอกจากนั้นแล้ว ขั้นตอนการทำงานบางอย่าง มันไม่ต้อง logging ละเอียดนักก็ได้ อย่างเมื่อไม่นานนี้ เราสั่งให้มีการวิเคราะห์ module หนึ่งที่มีชื่อว่า Instant XP ซึ่งมีหน้าที่หลักคือเก็บ mapping table หลังจากที่พบว่า เวลาโหลดข้อมูล mapping ใหม่ๆ เข้าไป มันใช้เวลานานมาก ทั้งๆ ที่ฝั่งฮาร์ดแวร์ก็ไม่ได้มีปัญหาอะไร

ผลการวิเคราะห์ออกมาถึงได้พบว่า คนออกแบบเจ้าโมดูลนี้ สั่งให้มีการเขียน log ทุกรายการที่มีการเปลี่ยนแปลงข้อมูลในตาราง เรียกว่าบันทึกไว้ละเอียดยิบเลยทีเดียว ผลเลยปรากฎว่า ตาราง log ใหญ่โตมโหฬาร ใหญ่กว่าตัวตาราง mapping เองนับเป็นร้อยเท่า เวลาที่ใช้ส่วนใหญ่ในการทำงาน ก็หมดไปกับการ insert ข้อมูล log เข้าไปในตาราง log พอ disable ส่วนนี้ออกไป ระบบทำงานเร็วขึ้นกว่าเดิมเยอะ จากที่เคยใช้เวลาสองสามชั่วโมง กลายเป็นเหลือแค่ “นาทีเดียว”

อะไรที่มันมากเกินไป ก็ไม่ดีทั้งนั้นแหละ เดินสายกลางดีที่สุด

Advertisements

ใส่ความเห็น

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s