แก้ปัญหาเซิร์ฟเวอร์ทำงานหนักเกินไป

วิธีระบุจุดคอขวดของเซิร์ฟเวอร์ แก้ไขจุดคอขวดอย่างรวดเร็ว ปรับปรุงประสิทธิภาพของเซิร์ฟเวอร์ และป้องกันการเกิดปัญหาซ้ำ

ภาพรวม

คู่มือนี้แสดงวิธีแก้ไขเซิร์ฟเวอร์ทำงานหนักเกินไปใน 4 ขั้นตอน

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

ประเมิน

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

• CPU: ควรตรวจสอบและแก้ไขการใช้งาน CPU ที่มากกว่า 80% อย่างต่อเนื่อง ประสิทธิภาพของเซิร์ฟเวอร์มักจะลดลงเมื่อมีการใช้ CPU ถึงประมาณ 80-90% และจะเห็นได้ชัดมากขึ้นเมื่อการใช้งานเข้าใกล้ 100% การใช้งาน CPU ของการให้บริการคำขอเดียวมีเพียงเล็กน้อย แต่การดำเนินการนี้ในระดับที่ต้องพบในช่วงที่ปริมาณการใช้งานพุ่งสูงขึ้นอาจทำให้เซิร์ฟเวอร์ทำงานหนักเกินไปได้ การลดภาระงานให้กับโครงสร้างพื้นฐานอื่นๆ การลดการดำเนินการที่มีค่าใช้จ่ายสูง และการจำกัดจำนวนคำขอจะลดการใช้งาน CPU
• เครือข่าย: ในช่วงที่มีการรับส่งข้อมูลสูง อัตราการส่งข้อมูลของเครือข่ายที่จำเป็นต่อการดำเนินการตามคำขอของผู้ใช้อาจมีความจุเกินขีดจำกัด บางเว็บไซต์อาจมีการจำกัดจำนวนการโอนข้อมูลสะสม ทั้งนี้ขึ้นอยู่กับผู้ให้บริการโฮสติ้ง การลดขนาดและปริมาณข้อมูลที่โอนเข้าและจากเซิร์ฟเวอร์จะนำจุดคอขวดนี้ออก
• หน่วยความจำ: เมื่อระบบมีหน่วยความจำไม่เพียงพอ จะต้องโหลดข้อมูลลงดิสก์เพื่อจัดเก็บข้อมูล การเข้าถึงดิสก์ช้ากว่าหน่วยความจำมากและอาจทำให้แอปพลิเคชันทั้งหมดช้าลง หากหน่วยความจำเต็ม อาจทำให้เกิดข้อผิดพลาดหน่วยความจำเต็ม (OOM) การปรับการจัดสรรหน่วยความจำ การแก้ไขการรั่วไหลของหน่วยความจำ และการอัปเกรดหน่วยความจำจะนำคอขวดนี้ออกได้
• I/O ของดิสก์: ตัวดิสก์เองจะจำกัดอัตราการอ่านหรือเขียนข้อมูลจากดิสก์ หาก I/O ของดิสก์เป็นจุดคอขวด การเพิ่มจำนวนข้อมูลที่แคชไว้ในหน่วยความจำจะช่วยลดปัญหานี้ได้ (เนื่องจากมีต้นทุนจากการใช้หน่วยความจำที่เพิ่มขึ้น) หากไม่ได้ผล คุณอาจต้องอัปเกรดดิสก์

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

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

แก้ภาพสั่น

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

การจำกัดอัตรา

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

แก้ไข

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

วิธีการ

• NGINX
• HAProxy
• Microsoft IIS

อ่านเพิ่มเติม:

• กลยุทธ์และเทคนิคเกี่ยวกับการจำกัดอัตรา

การแคช HTTP

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

ส่วนหัว HTTP เช่น Cache-Control, Expires และ ETag จะระบุวิธีที่แคช HTTP ควรแคชทรัพยากร การตรวจสอบและแก้ไขส่วนหัวเหล่านี้จะช่วยปรับปรุงการแคช

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

วินิจฉัย

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

• ควรแคชทรัพยากรแบบคงที่ด้วย TTL ยาว (1 ปี)
• คุณควรแคชทรัพยากรแบบไดนามิกโดยใช้ TTL สั้นๆ (3 ชั่วโมง)

แก้ไข

ตั้งค่าคำสั่ง max-age ของส่วนหัว Cache-Control เป็นจำนวนวินาทีที่เหมาะสม

วิธีการ

• NGINX
• Apache
• Microsoft

การเสื่อมสภาพอย่างนุ่มนวล

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

ปรับปรุง

ใช้เครือข่ายนำส่งข้อมูล (CDN)

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

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

ตั้งค่า CDN

CDN จะได้ประโยชน์จากขนาดต่างๆ ดังนั้นการใช้งาน CDN ของคุณเองจึงไม่ค่อยสมเหตุสมผล การกำหนดค่า CDN พื้นฐานนั้นตั้งค่าได้ค่อนข้างเร็ว (ประมาณ 30 นาที) และประกอบด้วยการอัปเดตระเบียน DNS ให้ชี้ไปยัง CDN

เพิ่มประสิทธิภาพการใช้งาน CDN

วินิจฉัย

ระบุทรัพยากรที่ไม่ได้ให้บริการจาก CDN (แต่ควรจะเป็น) โดยเรียกใช้ WebPageTest ในหน้าผลการค้นหา ให้คลิกที่สี่เหลี่ยมจัตุรัสเหนือ "การใช้ CDN อย่างมีประสิทธิภาพ" เพื่อดูรายการทรัพยากรที่ควรได้รับจาก CDN

แก้ไข

หาก CDN ไม่ได้แคชทรัพยากร ให้ตรวจสอบว่าตรงกับเงื่อนไขต่อไปนี้

• มีส่วนหัว Cache-Control: public
• ซึ่งมีส่วนหัว Cache-Control: s-maxage, Cache-Control: max-age หรือ Expires
• มี Content-Length, Content-Range หรือ Transfer-Encoding header

ปรับขนาดทรัพยากรการประมวลผล

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

วินิจฉัย

Time To First Byte (TTFB) ที่มีค่าสูงอาจเป็นสัญญาณว่าเซิร์ฟเวอร์กำลังจะเปิดให้บริการใกล้ถึงขีดจำกัดแล้ว โดยคุณจะดูข้อมูลนี้ได้ในการตรวจสอบลดเวลาในการตอบกลับของเซิร์ฟเวอร์ (TTFB) ของ Lighthouse

หากต้องการตรวจสอบเพิ่มเติม ให้ใช้เครื่องมือตรวจสอบเพื่อประเมินการใช้งาน CPU หากการใช้ CPU ในปัจจุบันหรือที่คาดการณ์ไว้เกิน 80% คุณควรพิจารณาเพิ่มเซิร์ฟเวอร์ของคุณ

แก้ไข

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

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

เปิดใช้การบีบอัด

ทรัพยากรแบบข้อความควรบีบอัดโดยใช้ gzip หรือ Brotli Gzip สามารถลดขนาดการโอนทรัพยากรเหล่านี้ได้ประมาณ 70%

วินิจฉัย

ใช้การตรวจสอบเปิดใช้การบีบอัดข้อความของ Lighthouse เพื่อระบุทรัพยากรที่ควรบีบอัด

แก้ไข

เปิดใช้การบีบอัดโดยการอัปเดตการกำหนดค่าเซิร์ฟเวอร์ของคุณ วิธีการ

• NGINX
• Apache
• Microsoft

เพิ่มประสิทธิภาพรูปภาพและสื่อ

รูปภาพเป็นขนาดไฟล์ส่วนใหญ่ของเว็บไซต์ส่วนใหญ่ การเพิ่มประสิทธิภาพรูปภาพจะช่วยลดขนาดของเว็บไซต์ได้อย่างรวดเร็วและอย่างเห็นได้ชัด

วินิจฉัย

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

การตรวจสอบ Lighthouse ที่เกี่ยวข้อง

• ปรับขนาดรูปภาพให้เหมาะสม
• เลื่อนรูปภาพนอกหน้าจอ
• เข้ารหัสรูปภาพอย่างมีประสิทธิภาพ
• แสดงรูปภาพในรูปแบบสมัยใหม่
• ใช้รูปแบบวิดีโอสำหรับเนื้อหาภาพเคลื่อนไหว

เวิร์กโฟลว์เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome

• บันทึกกิจกรรมในเครือข่าย
• คลิก Img เพื่อกรองแหล่งข้อมูลที่ไม่ใช่รูปภาพออก
• คลิกคอลัมน์ขนาดเพื่อจัดเรียงไฟล์ภาพตามขนาด

แก้ไข

หากคุณมีเวลาจำกัด...

ใช้เวลากับการระบุรูปภาพขนาดใหญ่และโหลดบ่อย จากนั้นเพิ่มประสิทธิภาพรูปภาพด้วยตนเองโดยใช้เครื่องมืออย่าง Squoosh รูปภาพหลักมักเป็นตัวเลือกที่ดีในการเพิ่มประสิทธิภาพ

ข้อควรจำ

• ขนาด: รูปภาพไม่ควรมีขนาดเกินจำเป็น
• การบีบอัด: โดยทั่วไป ระดับคุณภาพ 80-85 จะมีผลเพียงเล็กน้อยต่อคุณภาพของรูป ในขณะที่ให้ขนาดไฟล์ลดลง 30-40%
• รูปแบบ: ใช้ JPEG สำหรับรูปภาพแทน PNG แต่ใช้ MP4 สำหรับเนื้อหาภาพเคลื่อนไหวแทน GIF

หากคุณมีเวลาเพิ่มเติม...

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

อ่านเพิ่มเติม:

• ใช้ CDN รูปภาพเพื่อเพิ่มประสิทธิภาพรูปภาพ
• images.guide

ลดขนาด JS และ CSS

การลดขนาดจะนำอักขระที่ไม่จำเป็นออกจาก JavaScript และ CSS

วินิจฉัย

ใช้การตรวจสอบ Minify CSS และ Minify JavaScript Lighthouse เพื่อระบุทรัพยากรที่จำเป็นต้องลดขนาด

แก้ไข

หากคุณมีเวลาจำกัด ให้เน้นที่การลด JavaScript เว็บไซต์ส่วนใหญ่มี JavaScript มากกว่า CSS ดังนั้นจึงมีประสิทธิภาพมากกว่า

• ลดขนาด JavaScript
• ลดขนาด CSS

ตรวจสอบ

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

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

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

แก้ไข

ผู้ให้บริการระบบคลาวด์รายใหญ่ทุกรายจะมีเครื่องมือตรวจสอบของตนเอง (GCP, AWS, Azure) นอกจากนี้ Netdata ยังเป็นทางเลือกโอเพนซอร์สที่ยอดเยี่ยม ไม่ว่าจะเลือกเครื่องมือใด คุณจะต้องติดตั้ง Agent การตรวจสอบของเครื่องมือในแต่ละเซิร์ฟเวอร์ที่ต้องการตรวจสอบ เมื่อเสร็จแล้ว ก็อย่าลืมตั้งค่าการแจ้งเตือนด้วย

วิธีการ

• GCP
• AWS
• Azure
• ข้อมูลอินเทอร์เน็ต