เจาะลึก N+1 ปัญหาบั๊กเงียบตัวร้ายที่ทำให้เว็บ Laravel อืดเป็นเรือเกลือ
เผยวิธีแก้ปัญหา N+1 Query ใน Eloquent ที่ทำให้หน้าเว็บโหลดนานถึง 8 วินาที ให้กลับมาเร็วปรี๊ดภายในพริบตาเดียวโดยไม่ต้องอัพเกรดเซิร์ฟเวอร์
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- ปัญหา N+1 Query เกิดจากการดึงข้อมูลความสัมพันธ์ในลูป ทำให้เกิดการยิงคำสั่ง SQL ซ้ำซ้อนมหาศาล
- สภาพแวดล้อมในเครื่องนักพัฒนาที่มีข้อมูลน้อยมักไม่แสดงอาการ ทำให้ปัญหาไปโผล่เฉพาะตอนขึ้นระบบจริง
- การใช้ฟังก์ชัน with() ช่วยลดจำนวนการสอยข้อมูลลงเหลือเพียงไม่กี่คำสั่ง query เท่านั้น
- สามารถตั้งค่าป้องกันใน AppServiceProvider เพื่อให้ Laravel ช่วยเตือนเมื่อเกิด N+1 ได้
เมื่อลูกค้าส่งข้อความมาบอกว่าหน้าจอระบบกำลังติดขัดและหมุนวนเป็นเวลานาน คุณอาจจะเผลอคิดไปเองว่าเซิร์ฟเวอร์มีประสิทธิภาพไม่พอและเตรียมทำเรื่องขอเพิ่มทรัพยากร VPS ทันที แต่ในความเป็นจริงแล้ว ต้นตอของปัญหาไม่ได้มาจากฮาร์ดแวร์เลยแม้แต่น้อย แต่มันคือบั๊ก N+1 Query ซึ่งถือเป็นปัญหาเงียบที่พบบ่อยที่สุดใน Eloquent ของเฟรมเวิร์ก Laravel
บั๊กประเภทนี้มีความพิเศษตรงที่มันไม่ทำให้ระบบพัง ไม่แจ้งเตือน Error และไม่ทิ้งร่องรอยใดๆ ไว้ในล็อกไฟล์ แต่มันจะค่อยๆ สูบพลังความเร็วของระบบให้ช้าลงแล้วปล่อยให้คุณเข้าใจผิดว่าปัญหาเกิดจากจุดอื่น แทนที่จะเป็นโค้ดของคุณเอง ยกตัวอย่างเช่นการแสดงผลรายการคำสั่งซื้อจำนวน 50 แถวบนหน้าจอ
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ทุกครั้งที่ลูปทำงานแล้วเรียกใช้งานข้อมูลลูกค้าผ่านคำสั่ง $pedido->cliente ระบบ Eloquent จะทำการยิงคำสั่งค้นหาฐานข้อมูลใหม่เพิ่มขึ้นทันที 1 ครั้ง หมายความว่าหากมีคำสั่งซื้อ 50 รายการ ระบบจะต้องยิงคำสั่งเรียกข้อมูลลูกค้าอีก 50 ครั้ง รวมเป็น 51 คำสั่งสำหรับการโหลดหน้าจอเดียว และหากเพิ่มจำนวนเป็น 500 รายการพร้อมข้อมูลความสัมพันธ์อื่นๆ ปริมาณคำสั่งจะพุ่งทะยานจนเครื่องมือ Debugbar เคยบันทึกสถิติการยิงคำสั่งสูงถึงกว่า 3,000 ครั้งต่อการโหลดหน้าเว็บหนึ่งครั้ง
ปัญหาลักษณะนี้ถูกเรียกว่า N+1 ยิ่งข้อมูลมีปริมาณมากเท่าไหร่ สถานการณ์ก็ยิ่งเลวร้ายลงเท่านั้น และที่น่าเจ็บใจคือนักพัฒนาจะไม่สามารถสังเกตเห็นสิ่งผิดปกตินี้ได้ในขั้นตอนการพัฒนาที่มีข้อมูลทดสอบเพียงไม่กี่รายการ แต่มันจะรอเวลาตื่นขึ้นมาสร้างความปวดหัวในระบบจริงที่มีข้อมูลใช้งานจริงจำนวนมากเสมอ
อย่างไรก็ตาม การแก้ไขปัญหาดังกล่าวสามารถทำได้ง่ายอย่างเหลือเชื่อโดยอาศัยการเพิ่มคำสั่ง Eager Loading เพียงบรรทัดเดียว ซึ่งจะช่วยปรับลดจำนวนการเรียกฐานข้อมูลลงเหลือเพียง 2 คำสั่งเท่านั้น ไม่ว่ารายการคำสั่งซื้อจะมี 50 หรือ 5,000 รายการ ส่งผลให้หน้าจอที่เคยใช้เวลาโหลดถึง 8 วินาที หดสั้นเหลือเพียง 200 มิลลิวินาทีโดยไม่ต้องแตะต้องเซิร์ฟเวอร์หรือติดตั้งเครื่องมือเสริมใดๆ เพิ่มเติม
"ก่อนจะใส่ with() ทุก query ระวังเรื่องอีกขั้วหนึ่งด้วย ถ้าดึงความสัมพันธ์ที่ไม่ใช้มา จะเปลืองหน่วยความจำและแบนด์วิดท์โดยเปล่าประโยชน์"
Denis Gusto
ในเชิงสถาปัตยกรรมซอฟต์แวร์ ปัญหา N+1 Query ถือเป็นหนึ่งในคอขวดที่พบบ่อยที่สุดเมื่อระบบเริ่มเติบโตและมีปริมาณผู้ใช้งานมากขึ้น การทำความเข้าใจความแตกต่างระหว่างเครื่องมืออย่าง with() สำหรับการดึงข้อมูลล่วงหน้า และ whereHas() สำหรับการกรองข้อมูลเงื่อนไข จึงเป็นทักษะสำคัญที่ช่วยป้องกันไม่ให้แอปพลิเคชันแบกรับภาระการประมวลผลฐานข้อมูลเกินความจำเป็น
วิธีที่ดีที่สุดในการป้องกันไม่ให้บั๊ก N+1 เล็ดลอดเข้าสู่ระบบผลิต คือการเปิดใช้งานฟังก์ชันตรวจจับอัตโนมัติภายใน AppServiceProvider เพื่อให้ระบบคอยแจ้งเตือนทันทีเมื่อพบพฤติกรรมการสอยข้อมูลที่ผิดปกติ นักพัฒนาสามารถตรวจสอบจำนวนคำสั่ง query ผ่าน Laravel Debugbar หรือ Telescope บนหน้าจอที่ทำงานช้า เพื่อแก้ไขปัญหาได้อย่างตรงจุดและรวดเร็ว
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น