เมื่อเว็บไซต์หรือระบบที่มีผู้ใช้จำนวนมากเริ่มตอบสนองช้า ทางออกที่มักถูกเลือกก่อนคือเพิ่ม CPU หรือ RAM ให้ server (Vertical Scaling) วิธีนี้อาจช่วยได้ในบางกรณี แต่ก็อาจไม่ได้แก้ที่ต้นเหตุ ทำให้ค่าใช้จ่ายเพิ่มขึ้นโดยที่อาการอาจยังไม่หายไป
บทความนี้สรุปแนวทางตรวจหาสาเหตุของระบบช้าแบบไล่ทีละชั้น ตั้งแต่ application code ไปจนถึง network และการ monitor ต่อเนื่อง พร้อมวิธีเปลี่ยนค่าระบบอย่างมีการควบคุม เพื่อให้การตัดสินใจปรับปรุงตั้งอยู่บนหลักฐาน ไม่ใช่การเดา
เว็บไซต์ช้า ควรเพิ่มขนาด server เลยหรือไม่?
ยังไม่ควรตัดสินใจทันที การเพิ่ม CPU หรือหน่วยความจำอาจช่วยระบบที่ทรัพยากรไม่พอจริง แต่ถ้าคอขวดอยู่ที่ query ที่ไม่มี index หรือการเรียกระบบภายนอกที่บล็อกการทำงาน การขยาย server อาจช่วยได้น้อยหรือไม่ตรงจุด ส่วนกรณีที่คอขวดอยู่ที่ disk I/O การเพิ่ม RAM อาจช่วยลดการอ่าน disk ผ่าน cache ได้บ้าง แต่การเพิ่ม CPU มักไม่ช่วย ขั้นแรกจึงควรระบุให้ได้ว่า request ใดช้า เกิดขึ้นเมื่อใด และทรัพยากรใดอิ่มตัว (saturated)
ข้อมูลที่ควรรวบรวมตั้งแต่ต้น ได้แก่ หน้าหรือ API ที่ผู้ใช้รู้สึกว่าช้า ช่วงเวลาที่เกิดอาการ ปริมาณผู้ใช้ในช่วงนั้น และการเปลี่ยนแปลงล่าสุดของระบบ เช่น การ deploy เวอร์ชันใหม่ การย้ายข้อมูล หรือการเพิ่มฟีเจอร์
ต้องตรวจระบบในชั้นใดบ้าง?
ความช้าของระบบอาจเกิดได้จากหลายชั้นและหลายชั้นอาจส่งผลต่อกัน การไล่ตรวจอย่างเป็นระบบช่วยไม่ให้มองข้ามสาเหตุสำคัญ หรือแก้ชั้นหนึ่งแล้วไปสร้างปัญหาในอีกชั้นหนึ่ง โดยทั่วไปควรพิจารณาเจ็ดชั้นต่อไปนี้
- Application code: ทำ profiling กับ request ที่สำคัญ มองหา query ที่ถูกเรียกซ้ำในลูป (N+1 query) งานที่ไม่จำเป็น การใช้หน่วยความจำ และการเรียกแบบ synchronous ที่บล็อกการทำงานส่วนอื่น
- Web server และ application server: ทบทวนจำนวน worker การจัดการ connection และ keep-alive การบีบอัดข้อมูล และ caching ของ Nginx, Apache หรือ Gunicorn ให้สอดคล้องกับลักษณะ workload จริง
- Database: ตรวจ query ที่ช้าจาก slow query log ดู execution plan, index และการใช้หน่วยความจำ เช่น InnoDB buffer pool ใน MySQL ทดสอบผลของการเปลี่ยนแปลงทุกครั้ง แทนการเพิ่ม index โดยไม่มีหลักฐาน
- Operating system: ตรวจ process limit เช่น จำนวน file descriptor การจัดลำดับการทำงาน (scheduling) และพฤติกรรมด้าน network ของ kernel ปรับ kernel parameter ผ่าน sysctl เฉพาะเมื่อมีข้อมูลยืนยันว่าค่าปัจจุบันเป็นข้อจำกัดจริง
- Storage: ดู latency, throughput และ I/O wait รวมถึงพฤติกรรมของ filesystem และ mount option เช่น noatime โดยพิจารณาร่วมกับ workload ก่อนตัดสินใจเปลี่ยนอุปกรณ์จัดเก็บข้อมูล
- Network และการส่งเนื้อหา: ตรวจ caching ขนาดข้อมูลที่ส่ง (payload) ขั้นตอนการเปิด connection รวมถึง TLS handshake และพิจารณาว่า CDN เหมาะกับลักษณะเนื้อหาหรือไม่
- Monitoring ต่อเนื่อง: เก็บ metric และ log ที่มีประโยชน์ เช่น ผ่าน Zabbix หรือ Graylog เพื่อให้ทีมเปรียบเทียบพฤติกรรมของระบบก่อนและหลังการเปลี่ยนแปลง และช่วยให้สังเกตความผิดปกติได้
สำหรับเครื่องมือวัดผลบน Linux ในแต่ละด้าน อ่านเพิ่มเติมได้ที่ เครื่องมือวัด performance บน Linux และหากระบบใช้ proxy กระจาย traffic ไปยัง database ดู HAProxy กับ traffic ของ database
จะเปลี่ยนค่าระบบอย่างไรให้วัดผลได้และย้อนกลับได้?
บันทึก baseline ภายใต้ load ที่ใกล้เคียงการใช้งานจริงก่อน แล้วเปลี่ยนทีละปัจจัยที่มีนัยสำคัญ ตรวจผลที่เกิดขึ้น และเตรียมวิธีย้อนกลับไปใช้ค่าเดิมไว้เสมอ หากเปลี่ยนหลายอย่างพร้อมกันจะไม่สามารถบอกได้ว่าการเปลี่ยนแปลงใดให้ผล หรือการเปลี่ยนแปลงใดทำให้แย่ลง
ผลจาก synthetic benchmark เป็นหลักฐานที่มีประโยชน์ แต่ไม่ได้แทนการสังเกตเส้นทางการใช้งานของผู้ใช้จริง ควรตรวจทั้งสองอย่างประกอบกัน และบันทึกช่วงเวลา workload และค่าที่ใช้ทดสอบไว้ เพื่อให้การเปรียบเทียบครั้งถัดไปมีความหมาย
ควรใช้ตัวชี้วัดใดตัดสินว่าระบบดีขึ้นจริง?
ควรตกลงตัวชี้วัดร่วมกันก่อนเริ่มงาน โดยทั่วไปได้แก่ การกระจายตัวของ response time, throughput, error rate และการใช้ทรัพยากร ค่าเฉลี่ย response time ที่ลดลงอาจยังซ่อนประสบการณ์ที่แย่ของ request กลุ่มที่ช้าที่สุดไว้ จึงควรดูค่า percentile เช่น p95 หรือ p99 ประกอบด้วย
| ตัวชี้วัด | ช่วยตอบคำถาม |
|---|---|
| การกระจายตัวของ response time | ผู้ใช้ส่วนใหญ่และผู้ใช้กลุ่มที่ช้าที่สุดได้รับประสบการณ์อย่างไร |
| Throughput | ระบบรองรับงานได้กี่ request ต่อหน่วยเวลาโดยไม่เสื่อมลง |
| Error rate | การปรับแต่งทำให้เกิดข้อผิดพลาดหรือ timeout เพิ่มขึ้นหรือไม่ |
| การใช้ทรัพยากร | CPU, memory, disk และ network ชนิดใดใกล้อิ่มตัว |
เช็กลิสต์ก่อนเริ่มปรับ performance
- ระบุ request หรือหน้าเว็บที่ช้า และช่วงเวลาที่เกิดอาการ
- บันทึก baseline ภายใต้ load ที่ใกล้เคียงการใช้งานจริง
- ตกลงตัวชี้วัด เช่น response time percentile, throughput และ error rate
- ไล่ตรวจทั้งเจ็ดชั้นก่อนสรุปว่าต้องเพิ่มทรัพยากร
- เปลี่ยนทีละปัจจัยและเตรียมวิธีย้อนกลับ
- เก็บ metric และ log ต่อเนื่องเพื่อเปรียบเทียบก่อนและหลัง
UNIXDEV ช่วยในงานนี้ได้อย่างไร?
UNIXDEV ช่วยประเมินทั้งฝั่ง application และ infrastructure ผ่านบริการ DevOps และดูแลระบบองค์กร และ ดูแลและพัฒนาต่อยอดระบบเดิม ขอบเขตงานและผลที่คาดหวังจะกำหนดจากสิ่งที่พบในการตรวจสอบ จึงไม่สามารถรับปากผลลัพธ์ล่วงหน้าได้ก่อนเห็นข้อมูลของระบบ
บทความโดย UNIXDEV Team · ปรับปรุง 23 ตุลาคม 2026
คำถามที่พบบ่อย
เว็บไซต์ช้า ควรเพิ่ม CPU หรือ RAM ให้ server ทันทีหรือไม่?
ยังไม่ควรตัดสินใจทันที การเพิ่มทรัพยากรอาจช่วยได้เมื่อทรัพยากรไม่พอจริง แต่ถ้าคอขวดอยู่ที่ query ที่ไม่มี index หรือการเรียกที่บล็อกการทำงาน การขยาย server อาจไม่ช่วยหรือช่วยได้ไม่ตรงจุด ส่วนปัญหา disk I/O การเพิ่ม RAM อาจช่วยผ่าน cache ได้บ้าง แต่การเพิ่ม CPU มักไม่ช่วย ควรระบุก่อนว่า request ใดช้า ช้าเมื่อใด และทรัพยากรใดอิ่มตัว
การตรวจหาสาเหตุระบบช้าควรดูชั้นใดบ้าง?
โดยทั่วไปควรดูเจ็ดชั้น ได้แก่ application code, web server และ application server, database, operating system, storage, network และการส่งเนื้อหา รวมถึง monitoring ต่อเนื่องเพื่อเปรียบเทียบพฤติกรรมก่อนและหลังการเปลี่ยนแปลง
ควรปรับ kernel parameter หรือเพิ่ม index ใน database เมื่อใด?
สำหรับ index ให้ตรวจ query ที่ช้าจาก slow query log และ execution plan ก่อน แล้วทดสอบผลของการเปลี่ยนแปลงทุกครั้ง แทนการเพิ่ม index โดยไม่มีหลักฐาน ส่วน kernel parameter ควรปรับผ่าน sysctl เฉพาะเมื่อมีข้อมูลยืนยันว่าค่าปัจจุบันเป็นข้อจำกัดจริง
จะเปลี่ยนค่าระบบอย่างไรให้วัดผลได้?
บันทึก baseline ภายใต้ load ที่ใกล้เคียงการใช้งานจริง เปลี่ยนทีละปัจจัย ตรวจผล และเตรียมวิธีย้อนกลับไปใช้ค่าเดิมไว้เสมอ synthetic benchmark มีประโยชน์ แต่ไม่แทนการสังเกตการใช้งานของผู้ใช้จริง
ควรใช้ตัวชี้วัดใดตัดสินว่าระบบเร็วขึ้นจริง?
ดูการกระจายตัวของ response time, throughput, error rate และการใช้ทรัพยากร ค่าเฉลี่ยที่ลดลงอาจซ่อน request กลุ่มที่ช้าที่สุดไว้ จึงควรดูค่า percentile เช่น p95 หรือ p99 ประกอบด้วย
