ทำไมร้าน Magento 2 ในไทยถึงช้าลง และวิธีแก้ที่ได้ผลจริง

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

Indexer คือจุดแรกที่ควรดู

Magento 2 คำนวณข้อมูลแคตตาล็อก ราคา และการค้นหาล่วงหน้าผ่าน indexer แทนที่จะคำนวณสดในทุกคำขอหน้าเว็บ นั่นคือแก่นของสถาปัตยกรรมนี้ ปัญหาเกิดขึ้นเมื่อ indexer ถูกปล่อยไว้ที่ "Update on Save" แทนที่จะเป็น "Update by Schedule" ในแคตตาล็อกขนาดจริง ทุกการเปลี่ยนสินค้าหรือราคาจะกระตุ้นการรีอินเด็กซ์ แบบซิงโครนัสระหว่างการบันทึกเอง ซึ่งทำให้แอดมินช้าและในการตั้งค่าที่แย่ที่สุดอาจกระทบการตอบสนอง ของหน้าร้านระหว่างช่วงรีอินเด็กซ์นั้น การเปลี่ยนไปใช้ scheduled indexing แล้วให้ cron จัดการเบื้องหลัง มักเป็นการแก้ไขที่ให้ผลตอบแทนสูงสุดตัวเดียวที่มี และมักถูกปล่อยไว้ที่ค่าเริ่มต้น

Full page cache ต้องการ Varnish เพื่อทำงานเต็มศักยภาพ

Magento 2 มาพร้อม full page cache ในตัว แต่การรันบน cache backend แบบไฟล์เริ่มต้นแทนที่จะเป็น Varnish ทิ้งประสิทธิภาพจำนวนมากไว้บนโต๊ะ — Varnish อยู่หน้าแอปพลิเคชันทั้งหมดและส่งหน้าที่แคชไว้ โดยไม่แตะ PHP หรือฐานข้อมูลเลย ซึ่งเป็นความเร็วคนละระดับกับแม้แต่ cache ในตัวที่ตั้งค่าดี สำหรับร้านที่ยังอยู่บนการตั้งค่า cache เริ่มต้น นี่มักเป็นการแก้ไขที่ให้ผลตอบแทนสูงสุดอันดับสอง รองจาก indexing

Redis แทนไฟล์ สำหรับ cache และ session

การเก็บ cache และ session แบบไฟล์เริ่มต้นทำงานได้ แต่ไม่สเกลดีภายใต้ทราฟฟิกพร้อมกัน — file locking กลายเป็นคอขวดจริงเมื่อหลายคำขอเข้าถึงไฟล์ session หรือ cache เดียวกันพร้อมกัน การย้าย cache และ session storage ไป Redis ขจัดปัญหานี้และเป็นแนวปฏิบัติมาตรฐานสำหรับร้าน Magento 2 ใด ๆ ที่คาดว่าจะมีทราฟฟิกจริง ไม่ใช่การปรับแต่งขั้นสูงที่สงวนไว้เฉพาะการติดตั้งระดับองค์กร

Extension ที่เยอะเกินไปคือตัวฆ่าเงียบ

extension จากบุคคลที่สามทุกตัวที่เกี่ยวเข้ากับระบบ event/observer ของ Magento หรือเพิ่ม plugin รอบ core class จะทำงานในทุกหน้าที่เกี่ยวข้อง ไม่ว่าหน้านั้นจะใช้ฟีเจอร์ของ extension นั้นจริงหรือไม่ ร้านที่รัน extension สิบห้าถึงยี่สิบตัว — เกตเวย์ชำระเงิน เครื่องคำนวณค่าจัดส่ง เครื่องมือการตลาด ความสะดวกในแอดมิน — กำลังจ่ายต้นทุนสะสมนั้นในทุกคำขอ การแก้ไม่จำเป็นต้องเป็นการลบ extension ทั้งหมด — คือการตรวจสอบว่าอะไรติดตั้งอยู่จริง ตรวจว่าตัวไหนยังใช้งานจริง และ profile ตัวที่สงสัยว่าหนัก แทนที่จะเดา

การปรับแต่งฐานข้อมูลเป็นสิ่งที่ลืมง่ายที่สุด

การตั้งค่า MySQL เองมักถูกปล่อยไว้ที่ค่าเริ่มต้นที่ไม่เคยถูกปรับขนาดให้เหมาะกับฐานข้อมูลที่แคตตาล็อก Magento จริงสร้างขึ้น InnoDB buffer pool — หน่วยความจำที่ MySQL ใช้แคชข้อมูลและ index แทนที่จะอ่าน จากดิสก์ — เป็นการตั้งค่าที่ส่งผลกระทบสูงที่สุดตัวหนึ่งที่ควรปรับให้ถูกต้อง และค่าเริ่มต้นที่ปรับขนาดสำหรับ การติดตั้งทั่วไปแทนที่จะเป็นขนาดฐานข้อมูลจริงบนดิสก์ บังคับให้เกิด disk I/O มากกว่าที่จำเป็นอย่างเงียบ ๆ ในทุกคำสั่ง query การเปิด slow-query logging ชั่วคราวระหว่างการตรวจสอบประสิทธิภาพ มักเป็นวิธีที่เร็วที่สุด ในการหาว่า query ตัวไหนจริง ๆ กำลังกินเวลามากที่สุด — บ่อยครั้งมาจาก extension ที่เขียนไม่ดี ไม่ใช่ Magento core

ความขัดแย้งของ extension แสดงออกมากกว่าแค่น้ำหนัก

นอกเหนือจากต้นทุนสะสมของ extension ที่ทำงานในทุกหน้า extension สองตัวที่แก้ไขพื้นที่เดียวกัน ของหน้าชำระเงินหรือ logic แคตตาล็อกสามารถสร้างความขัดแย้งที่แสดงออกมาเป็นพฤติกรรมที่ไม่สม่ำเสมอ แทนที่จะเป็นข้อผิดพลาดที่ชัดเจน — ส่วนลดที่บางครั้งไม่ใช้ วิธีจัดส่งที่หายไปเป็นครั้งคราว สิ่งเหล่านี้ วินิจฉัยได้ยากจริง ๆ โดยไม่ปิด extension อย่างเป็นระบบเพื่อแยกความสัมพันธ์นั้น และเป็นข้อโต้แย้งที่หนักแน่น สำหรับการรักษารายการ extension ให้กระชับเท่าที่ธุรกิจต้องการจริง ๆ แทนที่จะสะสมทีละตัวสำหรับทุก คำขอฟีเจอร์ที่เข้ามา

การเฝ้าติดตามจับปัญหาก่อนที่ลูกค้าจะรายงาน

ร้านที่ผ่านการตรวจสอบประสิทธิภาพวันนี้อาจถดถอยภายในไม่กี่เดือนเมื่อมี extension ใหม่ถูกเพิ่มเข้ามา แคตตาล็อกโตขึ้น หรือแคมเปญการตลาดนำ JavaScript ที่ไม่มีใคร profile เข้ามา Application performance monitoring — แม้แต่การตั้งค่าเบา ๆ ที่ติดตามเวลาตอบสนองและตั้งค่าสถานะ query ฐานข้อมูลที่ช้า — จับความเสื่อมนี้ได้ตั้งแต่ยังเล็ก แทนที่จะรอให้คำร้องเรียนเรื่องความเร็วหน้าเว็บมาเปิดเผยหลังจากที่มัน กินค่า conversion ที่เสื่อมลงไปแล้วหลายสัปดาห์

รูปภาพและชั้นธีม

ระบบปรับขนาดรูปภาพในตัวของ Magento สามารถสร้างเวอร์ชันรูปภาพที่แคชไว้จำนวนมากเกินสมควรได้ หากธีมไม่ได้ตั้งค่าอย่างระมัดระวัง และรูปภาพต้นฉบับที่ไม่ได้ปรับให้เหมาะสมยิ่งทวีปัญหานั้น ธีมกำหนดเอง ที่ไม่ได้สร้างโดยคำนึงถึงประสิทธิภาพ — DOM ที่ซับซ้อนเกินไป asset ที่ไม่ได้ minify สคริปต์ที่บล็อกการเรนเดอร์ ใน head — ยิ่งทับถมบน backend ที่ปรับแต่งมาดีแล้ว ดังนั้นการปรับแต่ง backend อย่างเดียวจะไม่แก้ front-end ที่ไม่เคยถูกสร้างมาให้เบาตั้งแต่แรก

CDN ไม่ใช่ตัวเลือกเสริมอีกต่อไปในจุดนี้

การส่ง static asset — รูปภาพ CSS JavaScript — ตรงจากเซิร์ฟเวอร์ต้นทางแทนที่จะผ่าน CDN เพิ่ม latency สำหรับผู้เข้าชมทุกคนนอกกรุงเทพฯ และสำหรับร้านไทยที่มีทราฟฟิกระดับภูมิภาคหรือนานาชาติ latency นั้นยิ่งทบต้นกับทุกอย่างที่กล่าวมาแล้ว CDN ที่ตั้งค่าอย่างถูกต้องคือการเพิ่มที่ค่อนข้างง่ายและความเสี่ยงต่ำ เทียบกับความพยายามในการปรับแต่ง backend ข้างต้น และควรยืนยันว่ามันติดตั้งอยู่จริงและกำลังแคช สิ่งที่ควรแคชจริง ๆ — CDN ที่ตั้งค่าผิดจนถูกข้ามในทุกคำขอไม่ให้ประโยชน์อะไรเลย ในขณะที่สร้างความรู้สึก ผิด ๆ ว่าปัญหาถูกจัดการแล้ว

ลำดับที่ได้ผลจริง

การแก้ทั้งหมดนี้พร้อมกันไม่จำเป็นหรือสมจริงเสมอไป ลำดับที่ให้ผลลัพธ์เร็วที่สุด จากสิ่งที่เราเห็นบ่อยที่สุด:

1. เปลี่ยน indexer เป็น Update by Schedule หากยังไม่ได้ทำ — ฟรี ทันที และเป็นการตั้งค่าผิดที่พบบ่อยที่สุด
2. ย้าย session และ cache ไป Redis หากยังอยู่บนไฟล์
3. ตั้งค่า Varnish ให้ถูกต้อง สำหรับ full page cache รวมถึง cache header ที่แอปพลิเคชันตั้งค่าถูกต้อง เพื่อให้ Varnish แคชสิ่งที่ควรแคชจริง
4. ตรวจสอบรายการ extension และ profile ตัวที่ต้องสงสัย แทนที่จะลบแบบสุ่ม
5. จากนั้นค่อยดูระดับธีมและการปรับรูปภาพ — สำคัญ แต่แย่งส่วนแบ่งของปัญหาทั้งหมดน้อยกว่า การตั้งค่า backend ข้างต้นมาก

จุดที่สิ่งนี้เชื่อมกับโฮสติ้ง

ไม่มีอะไรในนี้ทำงานได้บนโฮสติ้งที่รันไม่ได้จริง — ทั้ง Varnish และ Redis ต้องถูกจัดเตรียมและตั้งค่า อย่างถูกต้องในระดับโครงสร้างพื้นฐาน ไม่ใช่ติดเพิ่มทีหลัง นี่คือส่วนหนึ่งที่การตัดสินใจเรื่อง cloud hosting และประสิทธิภาพ Magento เป็นบทสนทนาเดียวกันจริง ๆ ไม่ใช่สองเรื่องแยกกัน: แอปพลิเคชันที่ปรับแต่งดีบนโฮสติ้งที่จัดสรรทรัพยากรไม่พอยังคงทำงานได้แย่ และโฮสติ้งที่จัดสรรดีที่รัน แอปพลิเคชันที่ตั้งค่าผิดก็เสียการลงทุนไปในทิศทางตรงข้าม

ข้อสรุป

ร้าน Magento ที่ช้าไม่ค่อยเป็นเหตุผลให้ตั้งคำถามกับการเลือกแพลตฟอร์มเอง — มักเป็นช่องว่างการตั้งค่า ที่วินิจฉัยได้เฉพาะเจาะจง: indexer ที่ถูกปล่อยไว้ในโหมดผิด cache backend ที่ไม่เคยถูกอัปเกรดจากค่าเริ่มต้น หรือรายการ extension ที่ไม่มีใครตรวจสอบตั้งแต่เปิดตัว การแก้ไขตามลำดับที่ถูกต้องพาร้านส่วนใหญ่กลับไปสู่ ความเร็วที่แพลตฟอร์มมีศักยภาพอยู่แล้วเสมอ โดยไม่ต้องสร้างใหม่