การหลีกเลี่ยงภัยพิบัติ CMS: วิธีป้องกันการหยุดทำงานของเว็บไซต์

แท้จริงแล้วการที่ไซต์ ถูก พิจารณาว่าไม่มีประโยชน์หมายความว่าอย่างไร

บ่อยครั้งขึ้นอยู่กับว่าคุณถามใคร

การพิจารณาเว็บไซต์อาจหมายถึงสิ่งต่าง ๆ หลายประการ:

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

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

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

ประการแรก บทบาทการตรวจสอบอย่างต่อเนื่องเล่น

เราตรวจสอบแง่มุมต่างๆ ของเว็บไซต์ ดังนั้นเราจึงสามารถบอกได้ว่ามีบางอย่างทำงานไม่ถูกต้องในเลเยอร์ต่างๆ ที่ประกอบกันเป็นแพลตฟอร์ม WordPress VIP ที่มีการจัดการเต็มรูปแบบของเรา ชั้นเหล่านั้นรวมถึง:

• การเชื่อมต่อเครือข่าย
• โหลดบาลานเซอร์
• เว็บเซิร์ฟเวอร์
• การแคชวัตถุ (Memcached)
• ฐานข้อมูล
• Elasticsearch
• บริการไฟล์ (CDN)

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

ในกรณีส่วนใหญ่ ความไม่เสถียรของเว็บไซต์เป็นผลมาจากโค้ดแอปพลิเคชัน เช่น ธีม WordPress แบบกำหนดเองหรือของบุคคลที่สามและโค้ดปลั๊กอิน ต่อไปนี้คือสิ่งที่เรามองหาเมื่อตรวจสอบไซต์ที่ไม่เสถียร และวิธีบรรเทาแต่ละไซต์

แคชไม่เพียงพอ

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

คำตอบของ WordPress VIP:

แพลตฟอร์มวีไอพีของ WordPress นำเสนอการแคชหน้าที่มีประสิทธิภาพผ่านเครือข่ายทั่วโลกของเซิร์ฟเวอร์แคชขอบ ซึ่งแต่ละอันใช้เพื่อจัดเก็บและให้บริการเนื้อหาที่ใกล้เคียงที่สุดกับผู้ใช้ปลายทาง เวลาตอบสนองจากเซิร์ฟเวอร์ Edge Cache มักจะเร็วกว่าสิ่งใด ๆ ที่เลี่ยงการแคชหน้าและกระทบกับเซิร์ฟเวอร์ต้นทาง

ความท้าทายในการแคช

เนื่องจากพวกเขาต้องการประสบการณ์แบบอินเทอร์แอกทีฟที่เป็นส่วนตัวและเป็นส่วนตัว บางไซต์ โดยเฉพาะไซต์อีคอมเมิร์ซ ไม่สามารถแคชที่ระดับแคชของหน้าได้

มักจะพบการประนีประนอมโดยที่หน้าสแตติกให้บริการโดย edge cache ด้วยคุณสมบัติไดนามิก (เช่น สถานะการเข้าสู่ระบบ ตะกร้าสินค้า) ที่เพิ่มผ่าน JavaScript คำขอแบบอะซิงโครนัสจาก JavaScript สามารถใช้เพื่อสื่อสารกับปลายทาง WordPress REST API ที่ออกแบบโดยมีค่าใช้จ่ายต่ำกว่าการโหลดแบบเต็มหน้ามาก

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

คำตอบของ WordPress VIP:

สภาพแวดล้อมแอปพลิเคชัน WordPress VIP แต่ละรายการมีคลัสเตอร์ Memcached เฉพาะของตัวเอง ซึ่งเก็บข้อมูลแคชของวัตถุในหน่วยความจำเพื่อการดึงข้อมูลที่รวดเร็วและมีประสิทธิภาพ

การปรับใช้โค้ดที่ยังไม่ได้ทดสอบ

นี่เป็นอีกสาเหตุหนึ่งที่ทำให้เว็บไซต์หยุดทำงานและวินิจฉัยได้ง่าย โดยอิงจากสาเหตุและผลกระทบล้วนๆ

หากเว็บไซต์ของคุณเพิ่งปรับใช้โค้ดที่ยังไม่ได้ทดสอบ ซึ่งนำไปสู่ปัญหาเว็บไซต์ในทันที นั่นอาจเป็นสาเหตุของคุณ หากทำได้ ให้เปลี่ยนรหัสผู้ต้องสงสัยเป็นเวอร์ชันก่อนหน้าโดยเร็วที่สุด

สิ่งที่ดีที่สุดที่จะทำเพื่อหลีกเลี่ยงสถานการณ์นี้? ทดสอบโค้ดทุกชิ้นอย่างละเอียดบนสภาพแวดล้อมการพัฒนาหรือการจัดเตรียมที่แยกต่างหากก่อนเผยแพร่สู่การใช้งานจริง

คำตอบของ WordPress VIP:

เนื่องจากการปรับใช้ไซต์ทั้งหมดของเราดำเนินการผ่าน GitHub ลูกค้า WordPress VIP จึงสามารถเปลี่ยนรหัสด้วยตนเองได้อย่างง่ายดาย โดยไม่สูญเสียการเปลี่ยนแปลงรหัสใหม่ ซึ่งยังคงเก็บไว้อย่างปลอดภัยในประวัติการแก้ไข GitHub ในสถานการณ์ฉุกเฉิน เราสามารถย้อนกลับเว็บไซต์ของลูกค้าเป็นการปรับใช้ก่อนหน้าในนามของพวกเขา โดยไม่ขึ้นกับ GitHub

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

ข้อผิดพลาด PHP

WordPress ใช้โค้ด PHP บนเซิร์ฟเวอร์ ข้อผิดพลาด PHP อาจเป็น "ร้ายแรง" ซึ่งหมายความว่าเมื่อเกิดข้อผิดพลาด หน้าเว็บ สคริปต์ หรือคำสั่งจะหยุดทำงาน สิ่งเหล่านี้มักจะปรากฏเป็นข้อผิดพลาดที่มองเห็นได้ และจะถูกบันทึกไว้ในบันทึก PHP

หมายเหตุ: คำเตือน PHP บางอย่างใน PHP 7 กลายเป็นข้อผิดพลาดร้ายแรงใน PHP 8 ดังนั้นจึงเป็นเรื่องสำคัญที่จะต้องจัดการกับข้อผิดพลาดเหล่านี้อย่างจริงจัง

คำตอบ WordPress VIP (พร้อมคำแนะนำที่เป็นประโยชน์):

แพลตฟอร์มของเราจะบันทึกข้อผิดพลาด PHP ทั้งหมดโดยอัตโนมัติ ทำให้ลูกค้า WordPress VIP ใช้งานได้ในแดชบอร์ดและวิศวกรของเรา

เคล็ดลับสำหรับมือโปร : แก้ไขและแก้ไขข้อผิดพลาด PHP ทั้งหมด แม้ว่าไซต์จะดูทำงานได้ดี ตามปกติ เราเห็นบันทึกที่เต็มไปด้วยข้อผิดพลาด PHP แม้กระทั่งข้อผิดพลาดร้ายแรง บนเว็บไซต์ที่มีเสถียรภาพ อย่างไรก็ตาม ไม่ได้หมายความว่าไซต์ทำงาน อย่างถูกต้อง เสมอไป การรักษาบันทึก PHP ให้ชัดเจนโดยการแก้ไขข้อผิดพลาดเล็กน้อยและคำเตือนทำให้ง่ายต่อการค้นหาข้อผิดพลาดที่ร้ายแรงมากขึ้นในระหว่างการดีบัก

แบบสอบถามฐานข้อมูล MySQL ช้า

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

การสืบค้นที่ช้าจะเชื่อมโยงทรัพยากรฐานข้อมูล ซึ่งอาจส่งผลกระทบต่อความเสถียรของไซต์—ไม่ใช่แค่สำหรับหน้า สคริปต์ หรือคำสั่งที่เรียกใช้ SQL แต่ทั่วทั้งแอปพลิเคชัน ไซต์มักมีปัญหาเนื่องจากการสืบค้นฐานข้อมูลเดียวหรือหลายรายการช้า เช่น การสืบค้นใดๆ ที่ใช้เวลานานกว่า 0.75 วินาทีในการดำเนินการ

คำตอบของ WordPress VIP:

WordPress VIP ช่วยลดปัญหาคอขวดของฐานข้อมูลโดยให้แต่ละแอปพลิเคชันมีคลัสเตอร์ฐานข้อมูลเฉพาะที่มีฐานข้อมูลหลัก ซึ่งจะมีข้อความค้นหาการเขียนฐานข้อมูลทั้งหมด และฐานข้อมูลจำลองแบบอ่านอย่างเดียวอย่างน้อยหนึ่งฐานข้อมูล สิ่งนี้จะเพิ่มจำนวนการสืบค้นฐานข้อมูลพร้อมกันที่อาจเกิดขึ้น กระจายโหลดทรัพยากรเมื่อไซต์อยู่ภายใต้แรงกดดัน ที่กล่าวว่าการสืบค้นฐานข้อมูลที่ช้าไม่สามารถแก้ไขได้โดยการเพิ่มทรัพยากรฐานข้อมูลเพิ่มเติมเสมอไป นั่นเป็นเหตุผลที่เราแนะนำให้ลูกค้าตรวจสอบการสืบค้นฐานข้อมูลที่ช้าโดยใช้ Query Monitor และ New Relic (จัดทำโดยแพลตฟอร์มของเรา) สิ่งเหล่านี้เน้นที่การสืบค้นข้อมูลเกิดขึ้นในฐานข้อมูล ดังนั้นทีมพัฒนาของคุณสามารถจัดองค์ประกอบใหม่เพื่อเพิ่มประสิทธิภาพการทำงาน

สุดท้ายนี้ ฝ่ายสนับสนุนแอปพลิเคชันและวิศวกรระดับพรีเมียร์ของเรายังสามารถช่วยทีมของคุณค้นหาและวิเคราะห์คำถามเหล่านี้ และแนะนำวิธีปรับปรุงเพื่อความเร็วและประสิทธิภาพ

การเขียนฐานข้อมูลมากเกินไป

ในบางครั้ง คุณลักษณะ เช่น การบันทึกแบบกำหนดเองหรือโค้ดติดตาม จะอัปเดตฐานข้อมูลในทุกคำขอ สิ่งนี้สามารถนำไปสู่ความไม่เสถียรด้วยเหตุผลสองประการ:

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

คำตอบของ WordPress VIP:

ในกรณีเหล่านี้ เราแนะนำให้ปรับโครงสร้างคุณลักษณะใหม่ ตัวอย่างเช่น การวิเคราะห์เนื้อหามักจะมอบหมายให้ดีที่สุดกับบริการภายนอกที่ใช้ข้อมูลโค้ด JavaScript ในหน้าแทนที่จะเป็นโค้ดฝั่งเซิร์ฟเวอร์ ซึ่งใช้งานไม่ได้กับการแคชและอาจส่งผลให้มีการเขียนฐานข้อมูลมากเกินไป

สาเหตุอื่นๆ ของการหยุดทำงานและวิธีหลีกเลี่ยง

ปลั๊กอิน

มีปลั๊กอินของบุคคลที่สามที่เป็นที่นิยมและมีประโยชน์มากมายในระบบนิเวศของ WordPress ซึ่งมีคุณสมบัติและฟังก์ชันการทำงานที่ยอดเยี่ยม แม้ว่าจะมีความท้าทายในการปรับขนาด ซึ่งอาจนำไปสู่ปัญหาการหยุดทำงานเมื่อเพิ่มลงในเว็บไซต์ที่มีเนื้อหาและปริมาณการใช้งานจำนวนมาก

คำตอบของ WordPress VIP:

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

การบันทึกแบบกำหนดเอง

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

คำตอบของ WordPress VIP:

สำหรับลูกค้า เราให้สิทธิ์เข้าถึงบันทึก PHP มาตรฐานในแผงสุขภาพของแดชบอร์ดแอปพลิเคชัน VIP ของ WordPress ที่นั่นพวกเขาสามารถบันทึกข้อผิดพลาดที่กำหนดเอง (และไปยัง New Relic) ซึ่งจะไม่ส่งผลเสียต่อฐานข้อมูล

การเรียก API ระยะไกล

บางเว็บไซต์ใช้ประโยชน์จากการเรียก REST API ฝั่งเซิร์ฟเวอร์ไปยังแอปพลิเคชันหรือบริการอื่นๆ สิ่งเหล่านี้ค่อนข้างเร็วภายใต้สถานการณ์ปกติ แต่บางครั้งรหัสแอปพลิเคชันพื้นฐานทำให้ตอบสนองช้า หมดเวลา หรือเกิดข้อผิดพลาด

คำตอบของ WordPress VIP:

เพื่อลดปัญหาเหล่านี้ เราขอแนะนำ "การเข้ารหัสเชิงป้องกัน" ขึ้นอยู่กับวัตถุประสงค์ของการโทรทางไกล แต่บ่อยครั้งเมื่อคำขอระยะไกลล้มเหลว เป็นไปได้ที่จะถอยกลับในการตอบสนองที่แคชไว้จากคำขอก่อนหน้า—หรืออย่างน้อย “จัดการข้อผิดพลาดอย่างงดงาม” เพื่อให้ส่วนที่เหลือของหน้าสามารถ ยังคงโหลด เรามีฟังก์ชันตัวช่วยจำนวนหนึ่งเพื่อจัดการกับสถานการณ์เหล่านี้ การรักษาระยะหมดเวลาให้ต่ำยังหมายความว่าทรัพยากร PHP จะว่างเร็วขึ้นหาก API ระยะไกลไม่ตอบสนอง

อ่านเพิ่มเติมในซีรี่ส์การหลีกเลี่ยง CMS Disaster

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

วันที่มีการจราจรหนาแน่นควรเป็นสาเหตุแห่งการเฉลิมฉลอง ไม่ใช่ฝันร้ายสำหรับวิศวกรที่พยายามจะรักษาไซต์และแอปพลิเคชันไว้ และส่งเสียงฮัมเพื่อจัดการกับโหลด—และชื่อเสียงของคุณไม่เสียหาย ใน Scaling WordPress for High Traffic เราสำรวจสี่วิธีในการทำให้เว็บไซต์ WordPress สามารถจัดการกับคลื่นน้ำขึ้นน้ำลงของทราฟฟิกเหล่านั้น