เมื่อหน้าจอใช้เวลาโหลด 30 วินาที หรือรายงานไม่ยอมเสร็จสิ้น มักจะมีแรงกดดันให้ต้องทำอะไรสักอย่างทันที เช่น ซื้อเซิร์ฟเวอร์ที่ใหญ่ขึ้น แก้ไขฐานข้อมูลแบบเร็วๆ หรือบันทึกสำเนาผลลัพธ์เพื่อให้โหลดเร็วขึ้น สิ่งเหล่านี้อาจช่วยได้ แต่ถ้าไม่รู้ว่าทำไมมันถึงช้า คุณก็บอกไม่ได้ว่าการแก้ไขนั้นจะยั่งยืนหรือไม่ หรือเป็นเพียงการซ่อนปัญหาไว้จนกว่าจะถึงเดือนหน้า
มักจะเลือกใช้แนวทางที่มั่นคงและเป็นขั้นตอน ซึ่งสุดท้ายแล้วมักจะเร็วกว่า และอธิบายให้ผู้ที่จ่ายเงินเข้าใจได้ง่ายกว่ามาก
ขั้นแรก ระบุให้ชัดเจนว่าส่วนไหนที่ช้า
เริ่มต้นจากการระบุรายละเอียด หน้าจอหรือรายงานไหน? สำหรับลูกค้าคนไหน ช่วงวันที่ใด หรือการค้นหาอะไร? ช้าทุกครั้งหรือเฉพาะเช้าวันจันทร์? ฐานข้อมูลกำลังทำงานหนักจริงๆ หรือความล่าช้าเกิดขึ้นที่ส่วนอื่น?
จากนั้นจึงทำการวัดผล เพื่อให้มีตัวเลข "ก่อนทำ" ไว้เปรียบเทียบหลังการเปลี่ยนแปลงแต่ละครั้ง และต้องระมัดระวังในการทดสอบกับระบบที่ใช้งานจริง สิ่งที่ไม่เป็นอันตรายเมื่อรันครั้งเดียวอาจทำให้ทุกคนช้าลงได้เมื่อรันซ้ำๆ
ดูวิธีการทำงานของฐานข้อมูล
ฐานข้อมูลจะตัดสินใจเองว่าจะค้นหาข้อมูลที่คุณขออย่างไร เหมือนกับคนที่เลือกเส้นทางเดินในคลังสินค้า ฐานข้อมูลส่วนใหญ่สามารถแสดงเส้นทางที่มันเลือกได้ และนั่นมักจะเป็นจุดที่พบคำตอบ
บางครั้งฐานข้อมูลอ่านทุกเรคคอร์ดในตารางขนาดใหญ่เพียงเพื่อหาข้อมูลแค่ไม่กี่ชิ้น บางครั้งมันประเมินปริมาณข้อมูลผิดพลาดอย่างรุนแรงเพราะบันทึกเกี่ยวกับข้อมูลนั้นล้าสมัย หรือบางครั้งวิธีการเขียนคำค้นหาก็ขัดขวางไม่ให้มันใช้ทางลัดที่มีอยู่แล้ว การเห็นเส้นทางจะบอกได้ว่าเวลาเสียไปกับอะไร คุณจึงสามารถแก้ไขที่ต้นเหตุได้แทนที่จะเดาเอาเอง
เพิ่มทางลัดอย่างระมัดระวัง
วิธีแก้ไขฐานข้อมูลที่ช้าที่พบบ่อยที่สุดคือการสร้าง index ซึ่งทำงานเหมือนดัชนีท้ายเล่มหนังสือ ช่วยให้ฐานข้อมูลข้ามไปยังเรคคอร์ดที่ถูกต้องได้ทันทีแทนที่จะต้องอ่านทั้งหมด
อย่างไรก็ตาม index ไม่ได้มาฟรีๆ แต่ละอันต้องใช้พื้นที่เก็บข้อมูลและเพิ่มภาระงานเล็กน้อยทุกครั้งที่มีการบันทึกหรือเปลี่ยนแปลงข้อมูล หากเพิ่มมากเกินไป คุณอาจทำให้รายงานหนึ่งเร็วขึ้นแต่กลับทำให้หน้าจอสั่งซื้อที่พนักงานใช้ทั้งวันช้าลง ดังนั้นจึงต้องดูว่ามีอะไรอยู่แล้วบ้างและระบบทำงานอะไรบ่อยที่สุด และทดสอบการเปลี่ยนแปลงกับการใช้งานปกติในแต่ละวัน ไม่ใช่แค่กับรายงานที่ช้าเพียงอย่างเดียว
หยุดทำงานที่ไม่มีใครต้องการ
ระบบที่ช้าจำนวนมากทำงานเกินความจำเป็น เช่น โหลดข้อมูล 5,000 เรคคอร์ดเพื่อแสดงแค่ 20 เรคคอร์ดแรก ดึงข้อมูลทั้งหมดมาแล้วค่อยมากลั่นกรองทีหลัง ค้นหารายการหมวดหมู่สินค้าเดิมซ้ำแล้วซ้ำเล่า หรือเรียกใช้ฐานข้อมูลแยกกันสำหรับแต่ละรายการในคำสั่งซื้อแทนที่จะดึงมาทั้งหมดในครั้งเดียว
การตัดงานที่สูญเปล่าเหล่านั้นออกไปมักจะสร้างความแตกต่างได้มากที่สุด แต่ต้องทำด้วยความระมัดระวัง เพราะทุกการเปลี่ยนแปลงยังต้องให้ผลลัพธ์ที่ถูกต้องเหมือนเดิมทุกประการ
ตรวจสอบว่าเป็นเพราะฐานข้อมูลจริงหรือไม่
ฐานข้อมูลมักตกเป็นจำเลย แต่ความล่าช้าอาจเกิดขึ้นที่จุดใดก็ได้ระหว่างการคลิกและการแสดงผลบนหน้าจอ แอปพลิเคชันอาจกำลังรอคิวใช้งานฐานข้อมูล ส่งข้อมูลผ่านเครือข่ายมากเกินไป หรือใช้เวลานานในการเตรียมหน้าเว็บ
จึงต้องจับเวลาแต่ละขั้นตอนแยกกัน หลังการแก้ไข จะต้องตรวจสอบว่าระบบยังทำงานได้ดีเมื่อมีคนใช้งานพร้อมกันจำนวนมาก ไม่ใช่แค่ในช่วงบ่ายที่เงียบสงบ และจะบันทึกสิ่งที่เปลี่ยนแปลงและเหตุผลไว้ เพื่อที่ว่าหากระบบช้าลงอีกในอนาคต คนต่อไปจะรู้ว่าควรตรวจสอบที่ไหน
แนวทางในประโยคเดียว
ค้นหา วัดผล เปลี่ยนแปลงหนึ่งอย่าง และวัดผลอีกครั้ง เป้าหมายไม่ใช่การทำให้รายงานหนึ่งดูน่าทึ่ง แต่คือการทำให้ระบบเร็วขึ้นสำหรับทุกคนโดยไม่ทำให้ส่วนอื่นพัง