วิธีระบุจุดคอขวดของเซิร์ฟเวอร์ แก้ไขจุดคอขวดอย่างรวดเร็ว ปรับปรุงประสิทธิภาพของเซิร์ฟเวอร์ และป้องกันการเกิดปัญหาซ้ำ
ภาพรวม
คู่มือนี้จะแสดงวิธีแก้ไขเซิร์ฟเวอร์ที่ทำงานหนักเกินไปใน 4 ขั้นตอน ดังนี้
- ประเมิน: ระบุจุดคอขวดของเซิร์ฟเวอร์
- สร้างความเสถียร: ใช้การแก้ไขด่วนเพื่อลดผลกระทบ
- ปรับปรุง: เพิ่มและเพิ่มประสิทธิภาพความสามารถของเซิร์ฟเวอร์
- ตรวจสอบ: ใช้เครื่องมืออัตโนมัติเพื่อช่วยป้องกันปัญหาในอนาคต
ประเมิน
เมื่อการเข้าชมทำให้เซิร์ฟเวอร์ทำงานหนักเกินไป สิ่งต่อไปนี้อย่างน้อย 1 อย่างอาจกลายเป็นจุดคอขวด ได้แก่ CPU, เครือข่าย, หน่วยความจำ หรือ I/O ของดิสก์ การระบุว่าปัญหาใดเป็นคอขวดจะช่วยให้คุณมุ่งเน้นไปที่การบรรเทาปัญหาที่ส่งผลกระทบมากที่สุดได้
- CPU: ควรตรวจสอบและแก้ไขการใช้งาน CPU ที่สูงกว่า 80% อย่างต่อเนื่อง ประสิทธิภาพของเซิร์ฟเวอร์มักจะลดลงเมื่อการใช้งาน CPU ถึงประมาณ 80-90% และจะเห็นได้ชัดเจนยิ่งขึ้นเมื่อการใช้งานเข้าใกล้ 100% การใช้ CPU ในการแสดงผลคำขอเดียวเป็นเรื่องเล็กน้อย แต่การดำเนินการนี้ในระดับที่พบในช่วงที่มีการเข้าชมพุ่งสูงขึ้นอาจทำให้เซิร์ฟเวอร์ทำงานหนักเกินไปในบางครั้ง การลดภาระการแสดงผลไปยังโครงสร้างพื้นฐานอื่นๆ การลดการดำเนินการที่มีค่าใช้จ่ายสูง และการจำกัดจำนวนคำขอจะช่วยลดการใช้งาน CPU ได้
- เครือข่าย: ในช่วงที่มีการเข้าชมสูง ปริมาณการรับส่งข้อมูลในเครือข่ายที่จำเป็นต่อการตอบสนองคำขอของผู้ใช้อาจเกินความจุ บางเว็บไซต์อาจมีขีดจำกัดเกี่ยวกับการโอนข้อมูลสะสม ทั้งนี้ขึ้นอยู่กับผู้ให้บริการโฮสติ้ง การลดขนาดและปริมาณข้อมูลที่โอนไปยังและจากเซิร์ฟเวอร์จะช่วยแก้ปัญหาคอขวดนี้ได้
- หน่วยความจำ: เมื่อระบบมีหน่วยความจำไม่เพียงพอ ระบบจะต้องถ่ายโอนข้อมูลไปยังดิสก์เพื่อจัดเก็บ ดิสก์เข้าถึงได้ช้ากว่าหน่วยความจำอย่างมาก และอาจทำให้ทั้งแอปพลิเคชันทำงานช้าลง หากหน่วยความจำหมดลงโดยสิ้นเชิง อาจส่งผลให้เกิดข้อผิดพลาดหน่วยความจำไม่เพียงพอ (OOM) การปรับการจัดสรรหน่วยความจำ การแก้ไขหน่วยความจำรั่วไหล และการอัปเกรดหน่วยความจำจะช่วยแก้ปัญหาคอขวดนี้ได้
- I/O ของดิสก์: อัตราที่สามารถอ่านหรือเขียนข้อมูลจากดิสก์ได้จะถูกจำกัดโดยตัวดิสก์เอง หาก I/O ของดิสก์เป็นจุดคอขวด การเพิ่มปริมาณข้อมูลที่แคชไว้ในหน่วยความจำจะช่วยบรรเทาปัญหานี้ได้ (โดยแลกกับการใช้หน่วยความจำเพิ่มขึ้น) หากไม่ได้ผล คุณอาจต้องอัปเกรดดิสก์
เทคนิคในคู่มือนี้มุ่งเน้นที่การแก้ปัญหาคอขวดของ CPU และเครือข่าย สำหรับเว็บไซต์ส่วนใหญ่ CPU และเครือข่ายจะเป็นคอขวดที่เกี่ยวข้องมากที่สุดในช่วงที่มีการเข้าชมเพิ่มขึ้นอย่างรวดเร็ว
การเรียกใช้ top บนเซิร์ฟเวอร์ที่ได้รับผลกระทบเป็นจุดเริ่มต้นที่ดีในการตรวจสอบคอขวด หากเป็นไปได้ ให้เสริมข้อมูลนี้ด้วยข้อมูลย้อนหลังจากผู้ให้บริการโฮสติ้งหรือเครื่องมือตรวจสอบ
แก้ภาพสั่น
เซิร์ฟเวอร์ที่ทำงานหนักเกินไปอาจทำให้เกิดความล้มเหลวแบบต่อเนื่องในส่วนอื่นๆ ของระบบได้อย่างรวดเร็ว ดังนั้น คุณจึงควรทำให้เซิร์ฟเวอร์เสถียรก่อนที่จะพยายามทำการเปลี่ยนแปลงที่สำคัญเพิ่มเติม
การจำกัดอัตราคำขอ
การจำกัดอัตราคำขอจะช่วยปกป้องโครงสร้างพื้นฐานโดยการจำกัดจำนวนคำขอขาเข้า ปัญหานี้จะยิ่งสำคัญมากขึ้นเมื่อประสิทธิภาพของเซิร์ฟเวอร์ลดลง เนื่องจากเมื่อเวลาในการตอบสนองเพิ่มขึ้น ผู้ใช้มักจะรีเฟรชหน้าเว็บอย่างต่อเนื่อง ซึ่งจะยิ่งเพิ่มภาระงานของเซิร์ฟเวอร์มากขึ้นไปอีก
แก้ไข
แม้ว่าการปฏิเสธคำขอจะมีค่าใช้จ่ายค่อนข้างต่ำ แต่วิธีที่ดีที่สุดในการปกป้องเซิร์ฟเวอร์คือการจัดการการจำกัดอัตราคำขอที่จุดใดจุดหนึ่งซึ่งอยู่ต้นทางจากเซิร์ฟเวอร์ เช่น ผ่านตัวจัดสรรภาระงาน พร็อกซีแบบย้อนกลับ หรือ CDN
วิธีการ
อ่านเพิ่มเติม:
การแคช HTTP
มองหาวิธีแคชเนื้อหาอย่างมีประสิทธิภาพมากขึ้น หากแสดงทรัพยากรจากแคช HTTP ได้ (ไม่ว่าจะเป็นแคชของเบราว์เซอร์หรือ CDN) ก็ไม่จำเป็นต้องขอทรัพยากรจากเซิร์ฟเวอร์ต้นทาง ซึ่งจะช่วยลดภาระของเซิร์ฟเวอร์
ส่วนหัว HTTP เช่น Cache-Control, Expires และ ETag จะระบุวิธีที่แคช HTTP ควรแคชทรัพยากร การตรวจสอบและแก้ไขส่วนหัวเหล่านี้จะช่วยปรับปรุงการแคช
แม้ว่าService Worker จะใช้สำหรับการแคชได้ด้วย แต่จะใช้แคชแยกต่างหากและเป็นส่วนเสริม ไม่ใช่การแทนที่สำหรับการแคช HTTP ที่เหมาะสม ด้วยเหตุนี้ เมื่อจัดการกับเซิร์ฟเวอร์ที่ทำงานหนักเกินไป คุณควรมุ่งเน้นที่การเพิ่มประสิทธิภาพการแคช HTTP
วินิจฉัย
เรียกใช้ Lighthouse และดูการตรวจสอบแสดงเนื้อหาแบบคงที่ด้วยนโยบายแคชที่มีประสิทธิภาพเพื่อดูรายการทรัพยากรที่มีระยะเวลาคงอยู่ (TTL) สั้นถึงปานกลาง สำหรับทรัพยากรแต่ละรายการที่แสดง ให้พิจารณาว่าควรเพิ่ม TTL หรือไม่ หลักเกณฑ์คร่าวๆ มีดังนี้
- ทรัพยากรแบบคงที่ควรได้รับการแคชด้วย TTL แบบยาว (1 ปี)
- ควรแคชทรัพยากรแบบไดนามิกด้วย TTL แบบสั้น (3 ชั่วโมง)
แก้ไข
ตั้งค่าคำสั่ง max-age ของส่วนหัว Cache-Control เป็นจำนวนวินาทีที่เหมาะสม
วิธีการ
การลดลงอย่างค่อยเป็นค่อยไป
การลดลงอย่างค่อยเป็นค่อยไปคือกลยุทธ์ในการลดฟังก์ชันการทำงานชั่วคราวเพื่อลดภาระงานส่วนเกินออกจากระบบ แนวคิดนี้สามารถนำไปใช้ได้หลายวิธี เช่น การแสดงหน้าข้อความแบบคงที่แทนแอปพลิเคชันที่มีฟีเจอร์ครบถ้วน การปิดใช้การค้นหาหรือแสดงผลการค้นหาน้อยลง หรือการปิดใช้ฟีเจอร์บางอย่างที่มีค่าใช้จ่ายสูงหรือไม่จำเป็น คุณควรเน้นที่การนำฟังก์ชันการทำงานที่สามารถนำออกได้อย่างปลอดภัยและง่ายดายออกโดยส่งผลกระทบต่อธุรกิจน้อยที่สุด
ปรับปรุง
ใช้เครือข่ายนำส่งข้อมูล (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
ปรับขนาดทรัพยากรการประมวลผล
การตัดสินใจปรับขนาดทรัพยากรการประมวลผลควรทำอย่างรอบคอบ แม้ว่าการปรับขนาดทรัพยากรการประมวลผลมักเป็นสิ่งที่จำเป็น แต่การดำเนินการดังกล่าวเร็วเกินไปอาจทำให้สถาปัตยกรรมมีความซับซ้อนและมีค่าใช้จ่ายทางการเงินโดยไม่จำเป็น
วินิจฉัย
เวลาที่ได้รับข้อมูลไบต์แรก (TTFB) ที่สูงอาจเป็นสัญญาณว่าเซิร์ฟเวอร์ใกล้จะเต็มความจุแล้ว คุณดูข้อมูลนี้ได้ในการตรวจสอบลดเวลาในการตอบสนองของเซิร์ฟเวอร์ (TTFB) ของ Lighthouse
หากต้องการตรวจสอบเพิ่มเติม ให้ใช้เครื่องมือตรวจสอบเพื่อประเมินการใช้งาน CPU หากการใช้งาน CPU ปัจจุบันหรือที่คาดการณ์ไว้เกิน 80% คุณควรพิจารณาเพิ่มเซิร์ฟเวอร์
แก้ไข
การเพิ่มตัวจัดสรรภาระงานจะช่วยให้กระจายการรับส่งข้อมูลไปยังเซิร์ฟเวอร์หลายเครื่องได้ ตัวจัดสรรภาระงานจะอยู่หน้ากลุ่มเซิร์ฟเวอร์และกำหนดเส้นทางการรับส่งข้อมูลไปยังเซิร์ฟเวอร์ที่เหมาะสม ผู้ให้บริการคลาวด์มีตัวจัดสรรภาระงานของตนเอง (GCP, AWS, Azure) หรือคุณจะตั้งค่าตัวจัดสรรภาระงานของคุณเองโดยใช้ HAProxy หรือ NGINX ก็ได้ เมื่อมีตัวจัดสรรภาระงานแล้ว คุณจะเพิ่มเซิร์ฟเวอร์ได้
นอกจากการจัดสรรภาระงานแล้ว ผู้ให้บริการคลาวด์ส่วนใหญ่ยังมีการปรับขนาดอัตโนมัติ (GCP, AWS, Azure) การปรับขนาดอัตโนมัติทำงานร่วมกับการจัดสรรภาระงาน โดยการปรับขนาดอัตโนมัติจะปรับขนาดทรัพยากรการประมวลผลขึ้นและลงโดยอัตโนมัติตามความต้องการ ณ เวลาหนึ่งๆ อย่างไรก็ตาม การปรับขนาดอัตโนมัติไม่ใช่เรื่องมหัศจรรย์ เนื่องจากต้องใช้เวลาในการทำให้อินสแตนซ์ใหม่พร้อมใช้งานออนไลน์และต้องมีการกำหนดค่าที่สำคัญ เนื่องจากความซับซ้อนเพิ่มเติมที่การปรับขนาดอัตโนมัติก่อให้เกิด คุณจึงควรพิจารณาการตั้งค่าที่อิงตามตัวจัดสรรภาระงานที่ง่ายกว่าก่อน
เปิดใช้งานการบีบอัด
ทรัพยากรแบบข้อความควรบีบอัดโดยใช้ gzip หรือ brotli Gzip สามารถลดขนาดการโอนทรัพยากรเหล่านี้ได้ประมาณ 70%
วินิจฉัย
ใช้การตรวจสอบเปิดใช้การบีบอัดข้อความของ Lighthouse เพื่อระบุทรัพยากรที่ควรบีบอัด
แก้ไข
เปิดใช้การบีบอัดโดยอัปเดตการกำหนดค่าเซิร์ฟเวอร์ วิธีการ
เพิ่มประสิทธิภาพรูปภาพและสื่อ
รูปภาพเป็นองค์ประกอบหลักของขนาดไฟล์ในเว็บไซต์ส่วนใหญ่ การเพิ่มประสิทธิภาพรูปภาพจะช่วยลดขนาดของเว็บไซต์ได้อย่างรวดเร็วและมีนัยสำคัญ
วินิจฉัย
Lighthouse มีการตรวจสอบที่หลากหลายซึ่งจะแจ้งว่ารูปภาพใดบ้างที่อาจเพิ่มประสิทธิภาพได้ หรืออีกกลยุทธ์หนึ่งคือการใช้ DevTools เพื่อระบุไฟล์ภาพที่ใหญ่ที่สุด ซึ่งรูปภาพเหล่านี้อาจเป็นตัวเลือกที่ดีสำหรับการเพิ่มประสิทธิภาพ
การตรวจสอบ Lighthouse ที่เกี่ยวข้อง
- ปรับขนาดรูปภาพให้เหมาะสม
- เลื่อนเวลาโหลดรูปภาพนอกจอภาพ
- เข้ารหัสรูปภาพอย่างมีประสิทธิภาพ
- แสดงรูปภาพในรูปแบบรุ่นถัดไป
- ใช้รูปแบบวิดีโอสำหรับเนื้อหาภาพเคลื่อนไหว
เวิร์กโฟลว์ของเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome
- บันทึกกิจกรรมเครือข่าย
- คลิก Img เพื่อกรองทรัพยากรที่ไม่ใช่รูปภาพออก
- คลิกคอลัมน์ขนาดเพื่อจัดเรียงไฟล์ภาพตามขนาด
แก้ไข
หากมีเวลาจำกัด…
ใช้เวลาไปกับการระบุรูปภาพขนาดใหญ่และรูปภาพที่โหลดบ่อย แล้วเพิ่มประสิทธิภาพรูปภาพเหล่านั้นด้วยตนเองโดยใช้เครื่องมืออย่าง Squoosh รูปภาพหลักมักเป็นตัวเลือกที่ดีสำหรับการเพิ่มประสิทธิภาพ
ข้อมูลที่ควรทราบมีดังนี้
- ขนาด: รูปภาพควรมีขนาดไม่ใหญ่เกินความจำเป็น
- การบีบอัด: โดยทั่วไปแล้ว ระดับคุณภาพที่ 80-85 จะส่งผลต่อคุณภาพของรูปภาพน้อยที่สุด ขณะเดียวกันก็ลดขนาดไฟล์ได้ 30-40%
- รูปแบบ: ใช้ JPEG สำหรับรูปภาพแทน PNG และใช้ MP4 สำหรับเนื้อหาแบบเคลื่อนไหวแทน GIF
หากมีเวลาเพิ่มเติม…
ลองตั้งค่า CDN รูปภาพหากรูปภาพเป็นส่วนสำคัญของเว็บไซต์ CDN รูปภาพออกแบบมาเพื่อแสดงและเพิ่มประสิทธิภาพรูปภาพ และจะลดภาระการแสดงรูปภาพจากเซิร์ฟเวอร์ต้นทาง การตั้งค่า CDN รูปภาพนั้นทำได้ง่ายๆ แต่ต้องอัปเดต URL รูปภาพที่มีอยู่ให้ชี้ไปยัง CDN รูปภาพ
อ่านเพิ่มเติม:
ลดขนาด JS และ CSS
การลดขนาดจะนำอักขระที่ไม่จำเป็นออกจาก JavaScript และ CSS
วินิจฉัย
ใช้การตรวจสอบ Minify CSS และ Minify JavaScript ของ Lighthouse เพื่อระบุทรัพยากรที่ต้องลดขนาด
แก้ไข
หากมีเวลาจำกัด ให้มุ่งเน้นที่การลดขนาด JavaScript เว็บไซต์ส่วนใหญ่มี JavaScript มากกว่า CSS ดังนั้นวิธีนี้จึงมีประสิทธิภาพมากกว่า
ตรวจสอบ
เครื่องมือตรวจสอบเซิร์ฟเวอร์จะให้การเก็บรวบรวมข้อมูล แดชบอร์ด และการแจ้งเตือนเกี่ยวกับประสิทธิภาพของเซิร์ฟเวอร์ การใช้เครื่องมือเหล่านี้จะช่วยป้องกันและลดปัญหาด้านประสิทธิภาพของเซิร์ฟเวอร์ในอนาคตได้
การตั้งค่าการตรวจสอบควรเรียบง่ายที่สุดเท่าที่จะเป็นไปได้ การเก็บรวบรวมข้อมูลและการแจ้งเตือนที่มากเกินไปมีค่าใช้จ่าย ยิ่งขอบเขตหรือความถี่ในการเก็บรวบรวมข้อมูลมากเท่าใด ค่าใช้จ่ายในการเก็บรวบรวมและจัดเก็บก็จะยิ่งสูงขึ้นเท่านั้น การแจ้งเตือนที่มากเกินไปจะทำให้เกิดการเพิกเฉยต่อหน้าเว็บอย่างหลีกเลี่ยงไม่ได้
การแจ้งเตือนควรใช้เมตริกที่ตรวจพบปัญหาได้อย่างสม่ำเสมอและแม่นยำ เวลาในการตอบสนองของเซิร์ฟเวอร์ (เวลาในการตอบสนอง) เป็นเมตริกที่ทำงานได้ดีเป็นพิเศษสำหรับกรณีนี้ เนื่องจากจะตรวจจับปัญหาได้หลากหลายและสัมพันธ์กับประสบการณ์ของผู้ใช้โดยตรง การแจ้งเตือนตามเมตริกระดับต่ำกว่า เช่น การใช้งาน CPU อาจเป็นส่วนเสริมที่มีประโยชน์ แต่จะตรวจจับปัญหาได้เพียงบางส่วนเท่านั้น นอกจากนี้ การแจ้งเตือนควรขึ้นอยู่กับประสิทธิภาพที่สังเกตได้ที่ส่วนท้าย (กล่าวคือ เปอร์เซ็นไทล์ที่ 95 หรือ 99) แทนที่จะเป็นค่าเฉลี่ย ไม่เช่นนั้น ค่าเฉลี่ยอาจบดบังปัญหาที่ไม่ได้ส่งผลกระทบต่อผู้ใช้ทั้งหมดได้อย่างง่ายดาย
แก้ไข
ผู้ให้บริการคลาวด์รายใหญ่ทั้งหมดมีเครื่องมือตรวจสอบของตนเอง (GCP, AWS, Azure) นอกจากนี้ Netdata ยังเป็นทางเลือกโอเพนซอร์สที่ยอดเยี่ยมและใช้งานได้ฟรี ไม่ว่าจะเลือกเครื่องมือใด คุณจะต้องติดตั้งเอเจนต์การตรวจสอบของเครื่องมือในแต่ละเซิร์ฟเวอร์ที่ต้องการตรวจสอบ เมื่อเสร็จแล้ว อย่าลืมตั้งค่าการแจ้งเตือน
วิธีการ